[Dev] Enhancing development workflow

Maciej Wereski m.wereski at partner.samsung.com
Mon Oct 27 12:08:02 GMT 2014

24.10.2014 at 17:02 Kanevskiy, Alexander <alexander.kanevskiy at intel.com>

> On 24/10/14 16:53 , "Stéphane Desneux"
> <stephane.desneux at open.eurogiciel.org> wrote:
>> On 24/10/2014 15:25, Kanevskiy, Alexander wrote:
>>> 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.

IMHO that's mainly bureaucracy. Developer would have to request (by JIRA,
e-mail?) new project, then release engineer would create OBS project,
update git-obs-mapping (lots of "added"/"removed" commits). Then developer
would inform, that project was merged and can be removed. If developer
takes part in few updates, then (s)he might submit changes to wrong
branch/project by mistake.

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

I'd even go for one devel branch in git repo (as it is should be future
tizen branch) submitted to per profile devel:xxx projects.

> I’d prefer to have devel/* topical hierarchy instead of per profile
> devel_$profile.
> if we plan some big upgrades, it shouldn’t be targeted to specific
> profile, but more about functionality and we must make sure that it
> doesn’t break any other profile.
> in other words: if we plan to upgrade let’s say “systemd” we must make
> sure that same upgrade would be working solution for
> ivi/mobile/wearable/etc.

Well, e.g. devel:systemd:Common is still per profile. It also means, that
2 big updates (done by 2 teams in parallel) aren't tested against each

>> 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).
> well, latest version of git-buildpackage (underlying component used by
> gbs) is able to export packages correctly even if maintainer somehow
> screw-up upstream branch/tags.
> It wouldn’t generate nice patches, but would still be able to export
> sources in buildable format based on some revision.

I think that having mandatory "previous" branch, where tizen is backed up
during update is good idea. When problem occurs, then it can be easily
reverted. It allows to maintain old version (bug fixes, security
backports) and for others to clone and build package locally. New version
would go to devel branch and after fixing it would be pushed to tizen
(again: backing up current tizen to previous).

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

So you suggest we should have 100*${num_of_profiles} new projects? And
that every package should be tested with current state of system instead
of future state?

Maciej Wereski
Samsung R&D Institute Poland
Samsung Electronics
m.wereski at partner.samsung.com

More information about the Dev mailing list