[Libreoffice] Workflow proposal

[Jan Holesovsky]

Hi Bjoern,

On 2011-05-31 at 14:37 +0200, Bjoern Michaelsen wrote:

> > 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?
> 
> looks good, deserves a wiki page!

Now there :-)  Please feel free to edit.

http://wiki.documentfoundation.org/Development/Branches

>  Regardless of:
>  http://nabble.documentfoundation.org/merge-issues-td3005672.html
> having a rough documentation of how we do stuff is a great thing.

Answered that one in the thread.

Thank you,
Kendy