github release procedure

[Rob T]

On Saturday, 5 January 2013 at 01:00:28 UTC, H. S. Teoh wrote:
>
> The problem is, what constitutes "stable" is a judgment call, 
> because
> which bugs are critical (or, in this case, release-critical) 
> are also a
> judgment call.
>
> So we would need a delegated Release Manager who decides when a
> particular release branch is ready to be released, and who 
> holds high
> standards of what constitutes "release-ready".
>
> [...]

Good points.

As it stands right now, someone *has* to make a decision when to 
release, so we in effect have a "Release Manager" already, 
although who is making the decision and how the decision is being 
made is not clear at all. Personally, I would not want to be in 
that position because I would have nothing to guide me when 
deciding to make a release (or not), and if I made a mistake and 
released too soon or too late, then all the abuse for the mistake 
will be directed at me personally. I'd much rather have angry 
people place blame on a less than adequate process instead.

Processes are much easier to improve on and no one but the 
process itself is too blame when a process fails to deliver.

The point is, any definitions we come up with will be better than 
absolutely no definitions at all. For example the process as it 
is being defined, is making a positive impact even in its 
embryonic state. It allows us to look back at past 
less-than-perfect results, and move ahead with further 
incremental improvements. No one is to blame for the results, so 
we focus on the process improvements instead of pointing fingers 
at people.

--rt