[Dev] Enhancing development workflow

Kanevskiy, Alexander alexander.kanevskiy at intel.com
Fri Oct 24 13:25:04 GMT 2014


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.



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


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

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


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


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.

>
>Best regards.
>-- 
>Stéphane Desneux
>Intel OTC - Vannes/FR
>gpg:1CA35726/DFA9B0232EF80493AF2891FA24E3A2841CA35726
>
>On 22/10/2014 17:10, Maciej Wereski wrote:
>> Dear fellow Tizenians,
>> 
>> I'd like to propose little enhancement for current workflow, which
>>should
>> make updating packages a little bit easier and less error-prone.
>> 
>> Lately I've been working on 2 upgrades. First was quite big (systemd
>>from
>> 208 to 212). Few people were working on this case and we had to make
>> changes to a few other repositories. We were using sandbox branches and
>> devel:Tizen:Common OBS project. Changes to OBS were pushed by hand from
>> sandboxes (thanks Stéphane).
>> 
>> Today I've prepared util-linux update (v2.25 will be required by systemd
>> v217). This is much simpler case and it'd be inconvenient to disturb
>>other
>> to push this to OBS. I think that pushing rebased tree directly to
>> repository and sending commit with spec update on review is also not an
>> option, as the tree is rebased on new sources, so old version won't
>>build
>> (or will build new version).
>> 
>> I've seen that also others are struggling with updates (dbus, openssl).
>> 
>> I think it would be great if another branch could be defined
>>(for-next?).
>> After pushing upstream (and pristine-tar if required), developer would
>> push changes to review on for-next. The development could go as on tizen
>> branch, i.e. patches from many developers, review and merges.
>> 
>> Secondly this branch should have it's own OBS project. I think only one
>> project for Common profile should be sufficient (at least for now). So
>> after merging some changes in for-next we can get updated packages and
>> images.
>> 
>> After testing, fixing and ensuring that update is safe, for-next is
>> renamed to tizen.
>> 
>> Currently updates are expensive (developers build and test images on
>>their
>> own) so updates are done rarely, which makes them even harder to
>>perform.
>> I think that as a result of workflow change, Tizen will have newer
>> codebase and will receive updates on more regular basis.
>> 
>> Is this change possible? Or are there any other ideas how to improve
>> process of package upgrades?
>> 
>> cheers,
>_______________________________________________
>Dev mailing list
>Dev at lists.tizen.org
>https://lists.tizen.org/listinfo/dev
>


-- 
Best regards, Alexander Kanevskiy.



---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


More information about the Dev mailing list