24.10.2014 at 17:02 Kanevskiy, Alexander <[email protected]>
wrote:
On 24/10/14 16:53 , "Stéphane Desneux"
<[email protected]> 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
other.
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?
regards,
--
Maciej Wereski
Samsung R&D Institute Poland
Samsung Electronics
[email protected]
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
