[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
3.0
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


Thanks.
-- 
regards,
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