github release procedure

[H. S. Teoh]

On Sat, Jan 05, 2013 at 11:42:23AM +0100, Johannes Pfau wrote:
> Am Fri, 04 Jan 2013 21:01:41 +0100
> schrieb "Rob T" <rob at ucora.com>:
> 
> > On Friday, 4 January 2013 at 17:11:54 UTC, Johannes Pfau wrote:
> > > The more I think about it, staging really seems to be useful to
> > > avoid some corner cases.
> > 
> > I haven't had time to study the newly proposed process in enough 
> > detail to properly comment, but it always seemed to me that you 
> > cannot get away without a staging branch. You can try very hard 
> > to do without, but it means something else will suffer for the 
> > lack of it, so it seems you are coming to the same conclusion 
> > which is good (unless I'm wrong).
> 
> Yep. As we have lost most attention in this thread(most people have
> probably set "ignore this thread") we should check if we all agree on
> the process as outlined on the updated wiki page (I've updated the
> original page now) and improve it, if necessary, do some proof reading
> / spell checking and then open a new thread, asking for comments from
> the main devs.

I like the new page!!

One question, though: in the git workflow section, it says that a
non-regression bugfix should go directly into staging, but there's no
mention of merging it back to master. Is this deliberate? It seems to me
to be kinda important that we merge all fixes back to master so that
bugs don't get "unfixed". Or am I missing something here?


T

-- 
Why waste time learning, when ignorance is instantaneous? -- Hobbes, from Calvin & Hobbes