[m2e-dev] Release Planning

[Christoph Läubrich <laeubi@xxxxxxxxxxxxxx>]

As the recent discussions and rumor I'd like to propose some kind of 
'rules' (maybe there are already some and I haven't found them?) to get 
this release stuff more smooth in the future (and even faster releases).

1) We should create an issue for every action (excluding documentation 
changes) and either:
 - assign the current milestone if we plan to work on this in the 
current release cycle
 - not assign a milestone if we will do it "sometimes"

2) If we ask for a release, also ask for ultimately marking issues to be 
included within a given time frame (I would suggest one week and thus 
name it "planning week" from now on) and

3) Then we should discuss in this "planning week" on the marked issues 
if they go into the release or should be postponed if there any 
concerns. If postponed, we should assign the next milestone or remove it 
if we do not want to get this in for the next release.

4) After this "planning week" we assign a release date (github allows to 
set a due-date on a release) that should be at most two weeks maybe we 
choose then to postpone some things because there is no time to actually 
develop this feature ...

5) From now on we only add bugs to the current release, if something is 
a bug might be discussed on the ticket.

6) All features should be finished one week before the release so we 
have a time where we only work on regressions (if any).

That way we always have a clear understanding what is "open" for the 
current release and if there is a risk we miss the date due to the 
current status of the milestone.

Given that, we should be able to release once a month if desired and I 
think that's acceptable as a lower bound.