[Dev] Enhancing development workflow

Stéphane Desneux stephane.desneux at open.eurogiciel.org
Fri Oct 24 13:53:57 GMT 2014


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:
> 
>> Hi all,
>>
>> +1
>>
>> Let me summarize (and make small adjustments on Maciej's proposal):
>> - for "big" updates (ex: systemd), we could harmonize the naming and
>> have a "devel_common" branch (in place of Maciej's for-next branch),
>> submitted and built in the devel:Tizen:Common project, with images
>> published in snapshots/devel/common. If it's a profile-specific package,
>> the branch could be named devel_<profile>
> 
> for targeted upgrades of big components or something that require extended
> period of development we have for already quite long time devel: hierarchy
> of build projects and devel/* branch hierarchy in packages.
> E.g. devel:x11:common
> https://build.tizen.org/project/show?project=devel%3Ax11%3Acommon  ->
> devel/x11 branches.
> 
> Maintainers who are planning to do such big upgrades can request devel:
> projects based on their neeeds and then ask to kill it once this big pile
> of changed merged into normal releases.
> 

So devel_<profile> would be the right name for the git branch ? We can
also tune the git-obs-mapping to send the submissions to the appropriate
devel:* project

>> - when the devel_common branch is ok, we rename the current tizen branch
>> to tizen_x.y.z (x.y.z.= the version of the package, as indicated in the
>> spec file). This way, we don't lose the possibility to build old
>> versions. Then we create a new tizen branch from devel_common (or rename
>> 'devel_common' to 'tizen')
> 
> 
> please, don’t use “tizen*”. namespace of branches for anything else than
> release branches. 
> 
> for old versions of packages, there are always submit/accept tags that are
> existing in repo. 
> you don’t need to create branch for every package version.

ACK

>> - correct me if I'm wrong: the above rules would work only if the
>> upstream branch always goes forward (push --force should be forbidden on
>> the upstream branch). Otherwise, some inconsistencies can be introduced
>> for old tizen_x.y.z branches.
> 
> for upstream code generation it’s important that upstream tags are not
> overwritten.
> 
> e.g. if package version 1.1-22 ($sha_1) is needed to be built, upstream
> tag 1.1 ($sha_2) should be (grand-…)parent of $sha_1.
> 
> I hope Markus would be able to add more details here. But in short,
> upstream tags are the most important things.
> 

Yes: the old accepted commits must still have ancestors on the upstream
branch. Otherwise, gbs export won't run correctly (and old versions
couldn'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 ?

>> 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.

BR
Stéphane


More information about the Dev mailing list