[Dev] Maintaining upstream project with tizen/upstream branches?

Tomasz Olszak olszak.tomasz at gmail.com
Tue Dec 17 00:12:27 GMT 2013

2013/12/17 Thiago Macieira <thiago.macieira at intel.com>

> On terça-feira, 17 de dezembro de 2013 00:31:35, Tomasz Olszak wrote:
> > Hi,
> >
> > I have following case:
> > Qt Tizen integration is developed and reviewed in Qt project. It is done
> in
> > wip/tizen branches (wip = work in progress). These branches are upstream
> > branches from Tizen perspective. Therefore I've made following
> assumptions:
> >
> > 1. It is allowed to rebase tizen branch with upstream from time to time
> for
> > clarity
> Should be ok. The maintainer (you) decides when it's time to rebase against
> upstream, but you must have good reasons to. Upgrades for the sake of
> upgrades
> are not accepted.
> It should be easy to justify, though, like bringing in new required
> features,
> better Tizen support, important bugfixes, etc. Also, "being close to
> upstream"
> is a valid reason: you shouldn't let our copy drift too far.

Yes in this special case the main reason will be "being close to upstream"
where the development takes place. So the workflow before releasing Tizen
will be:

1. Bug spotted in Tizen
2. Fix in Qt project
3. Update upstream and tizen branch

After Tizen 3.0 release and merge the Tizen integration code (wip/tizen)
into the Qt (dev) it will
look like:

1. Bug spotted in Tizen
2. Fix in tizen branch
3. Fix in qt-project
4. Update upstream branch after next Qt (bugfix) release
5. Remove bugfix from tizen branch
6. Merge/rebase tizen branch with upstream

> > 3. It is allowed to merge tizen branch with upstream without codereview.
> You probably want to rebase (which implies a force push), not merge. If
> there
> have been any changes in Tizen's infra that got upstreamed, we probably
> want
> them removed from our tree.

Rebase is easier - it removes the 1 assumption :) All packaging related
changes are always
on top.

> Indeed.
> As the maintainer, you have the responsibility to ensure that all
> contributions are reviewed and that your package is in a good, working
> state.
> That might mean you have to fix things if no one else is doing it and,
> thus,
> review your own contributions if no one else does. For those reasons,
> maintainers are given the right to self-review, but please leave that as
> last
> resort and try and get at least one more pair of eyes.
> It's clear

Tomasz Olszak
Qt for Tizen | http://qt-project.org/wiki/Tizen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131217/06527aff/attachment.html>

More information about the Dev mailing list