Hi Bjorn,
On 2011-05-30 at 19:13 +0200, Bjoern Michaelsen wrote:
> > So - as long as you don't force people to do this [ie. don't force
> > this as a rule, but instead let them decide if they are willing to
> > wait for the merge of the branch into the master (working mostly on
> > the branch before the release), or whether they prefer to cherry-pick
> > whatever direction], I am fine.
>
> I cant force anybody whom I dont hand the paycheck (an even then that
> would have limits). ;)
Oh - of course you / we can :-) If the TSC agrees that something is
worth forcing, then a git hook [even on the server] can be created that
disallows / forces this or that.
> It is more about having a general recommendation on how to work. You are
> always free to do it different, but you should not blame anyone if
> things go wrong then. If there is no clear recommendation, you will
> just end up with people missing some commits on either branch and doing
> emergency cherrypicks, not helping clarity either.
Great - so I am sure we agree here :-)
> The more people are
> working on the release branch directly, even for critical fixes, the
> more people will be tempted to do the same for noncritical stuff,
> creating additional review work.
As long as the noncritical stuff are still fixes, not feature work, I am
fine. I haven't heard complaints that there was an unbearable amount of
stuff to review - but if there was, reviewers, please tell me.
> Also: 3.3.3 codefreezed today with another ~35 most likely rather
> important commits. Are those merged back to master (or manually
> checked)? Are we sure all of them are obsolete for both master and 3-4?
> With patches and commits flying all directions between the currently
> open branches master, 3-4, 3-4-0 and 3-3 things are not exactly lucid.
That's actually a very good question. Before the libreoffice-3-4 branch
was frozen (one review per commit), we have been merging libreoffice-3-3
into libreoffice-3-4. Not to miss anything, we can either merge
libreoffice-3-3 just to master, or again to libreoffice-3-4 first, and
then the result to master.
I'd go for the former (libreoffice-3-3 directly to master), and let
anyone who needs something from libreoffice-3-3 in libreoffice-3-4
cherry-pick it there (with the usual 1 review). When I see the other
comments, it seems to me that others are inclined to something close to
this too :-) To sum up my proposal:
- master
- no review, anything can be committed / merged into it
- as long as the author did her / his best to make sure it
builds / does not break the tests)
- libreoffice-A-X
- branch created with the first beta
- only fixes go in, no features
- exception for the late features: 2 additional reviews, from people
with different affiliation than the original author
- no review until the last beta, libreoffice-A-(X-1) can be merged
into it when in the "no review" mode
- such a merge depends on TSC recommendation
- 1 review after the last beta, no merging into the branch any more
- any source of the patch goes - be it a patch sent to the mailing
list, pasted via pastebin, a cherry-pick from master, or
cherry-pick from any other branch
- the reviewer pushes to the branch [unless the reviewer and author
agree on something else ;-)] with the appropriate Signed-off-by:
tag [use the "-s" option of git commit or git cherry-pick ;-)]
- regularly [Q: once a week? or when a tag appears?], all
libreoffice-A-* merged into master
- of course a no-op when there are no changes in a particular
release branch
- libreoffice-A-X-Y
- branch created with the "semifinal" RC (see the release plan)
- 2 additional reviews [Q: wouldn't actually just 1 additional be
enough?]
- only cherry-picking from libreoffice-3-X, the 2nd reviewer pushes
- no merges back to anything
I believe this fits most of the needs - people can work either on
master, and let others cherry-pick, or work on the release branch, being
sure that the fix will appear in master in up to one week / when a tag
appears, so that the timeframe for duplication is minimal.
How does that sound?
Regards,
Kendy
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
