[Dev] Enhancing development workflow

Stéphane Desneux stephane.desneux at open.eurogiciel.org
Fri Oct 24 12:58:24 GMT 2014

Hi all,


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

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,

More information about the Dev mailing list