On 24/10/14 16:53 , "Stéphane Desneux" <stephane.desn...@open.eurogiciel.org> wrote:
>On 24/10/2014 15:25, Kanevskiy, Alexander wrote: >> On 24/10/14 15:58 , "Stéphane Desneux" >> <stephane.desn...@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 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. >>>- 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). 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. > >>> 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) ? benefit of such “double maintenance” is that as developer, person has ability to work with upstream git in best possible way and at the same time, once package is exported to release system, then result would be matching upstream tarball. So, if someone would like to verify bash-4.3.tar.gz in our distributed package (src.rpm) is authentic to upstream http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz, he/she would be able to use http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz.sig to verify integrity of this tarball. >What are the guidelines here ? Because Tizen has a lot of legacy from earlier stages, it was never enforced rules for pristine-tar or upstream. However, it was strong request to try putting appropriate upstream branches/tags/pristine-tars into tizen repositories once packages are upgraded to new versions. > >>> 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. At the moment, we rarely have times when absolutely all workers are busy with rebuilding something (well, we need to fix crosswalk builds, but that is separate story). Also, in Tizen OBS there are specific settings on priorities for builds, so something that is not official builds (Tizen:*:$profile hierarchy) has lower priority. if we see that those temporary sandboxes causing issues, those priorities can be adjusted even more. So, don’t worry about that at the moment. or ping me if you notice something wrong happening :) -- 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. _______________________________________________ Dev mailing list Dev@lists.tizen.org https://lists.tizen.org/listinfo/dev
