[Dev] Enhancing development workflow

Stéphane Desneux stephane.desneux at open.eurogiciel.org
Mon Oct 27 14:28:32 GMT 2014


On 27/10/2014 08:42, Lehtonen, Markus wrote:
> Hi,
> 
> On Fri, 2014-10-24 at 15:53 +0200, Stéphane Desneux wrote:
>> On 24/10/2014 15:25, Kanevskiy, Alexander wrote:
>>> On 24/10/14 15:58 , "Stéphane Desneux"
>>> <stephane.desneux at open.eurogiciel.org> wrote:
>>>
>> [...SNIP...]
> 
> 
>> dn't be rebuilt).
>>
>>>> Finally a question: do we still need pristine-tar branches ? Using
>>>> upstream gits is far better IMO (even in case where the upstream branch
>>>> is maintained only on tizen.org)
>>>
>>>
>>> pristine-tar branches allows us to recreate byte-to-byte exactly same
>>> tarball for components like it was published on upstream download server.
>>> e.g. http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
>>>
>>
>> Yes, I know. But if I take your example, bash is also distributed in a
>> git. So is it necessary to have a double maintainance mechanism
>> (upstream branch + pristine-tar) ? What are the guidelines here ?
> 
> What do you mean by double maintenance? The pristine-tar branch is
> automatically updated by gbs import and it always needs an accompanying
> upstream branch (because pristine-tar only stores delta).
> 
> As I mentioned in some of my earlier emails, you can combine the
> tracking of "real" upstream Git history and "real" upstream release
> tarballs (including pristine-tar) by using the '--upstream-vcs-tag'
> option of 'gbs import'.
> 
> 
>>
>>>> FYI, we'll have to upgrade ~100 packages soon to align with Yocto
>>>> versions. This makes Maciej's proposal even more interesting !
>>>
>>> I would suggest for such upgrade make a devel:xxxx:{common,ivi} projects,
>>> and make sure that both common and ivi would be buildable/testable after
>>> such changes.
>>> and once it’s confirmed, merge changes to tizen (or tizen_ivi) branch.
>>>
>>>
>>
>> Makes sense. We also have our private OBS to prepare things.
>>
>>> PS. beside of devel: project, there is always possibility of agreeing with
>>> release engineers that certain submission ID is used to accumulate changes
>>> that includes multiple packages at same time. so, using pre-release
>>> project as temporary “upgrade” sandbox.
>>
>> Yes. That's also an option, but it shouldn't last too long (say less
>> than a week) because the prerelease builds incur some extra load on the
>> infrastructure.
> 
> Why do you think a long-lasting pre-release project would be a problem?
> From what I can tell, the builder load has been pretty decent on average
> and there should be reserves to carry few extra projects. 
> 

Well, a few weeks ago, there was 40 crosswalk instances building
simultaneously on the 25 hosts. This is not very efficient and keeping
prerelease projects longer simply incurs more builds. I just think that
we should limit the prerelease usage to what it's good for: continuous
integration with low number of breakages.

For big integration tasks, having a separate project (linked or not the
main project) without prereleases is probably better: finally there will
be a prerelease to push the work into the main project.


-- 
Stéphane Desneux
Intel OTC - Vannes/FR
gpg:1CA35726/DFA9B0232EF80493AF2891FA24E3A2841CA35726


More information about the Dev mailing list