On 24/10/2014 15:25, Kanevskiy, Alexander wrote: > On 24/10/14 15:58 , "Stéphane Desneux" > <[email protected]> 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 _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
