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> - 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') - 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. 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) FYI, we'll have to upgrade ~100 packages soon to align with Yocto versions. This makes Maciej's proposal even more interesting ! 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 [email protected] https://lists.tizen.org/listinfo/dev
