[dmd-internals] Planning software?

[Don Clugston]

On 19 January 2012 21:22, Oleg Kuporosov <oleg.kuporosov at gmail.com> wrote:
>
>
> 2012/1/19 Jacob Carlborg <doob at me.com>
>>
>>
>>
>>
>> You seems to focus too much on the products. We first have to decide:
>>
>> * What goal we want to achieve
>> * How we should a achieve that goal
>> * How we want to organize the community
>>
>> Then we can get into more detail of what we want from a tool. Examples:
>>
>> * Milestones
>> * Roadmaps
>> * Goals
>> * Tasks
>
>
> Please also think about new community members, they need:
>
> * Rules
> * Procedures
>
> Thanks,
> Oleg.

Here's some concrete suggestions:
....
An obvious easy improvement would be to add more structure to the
release cycle. I think this is our biggest management problem.
I don't think we need tools so much as decisions. The change from a
one month release cycle to two months wasn't a decision, it just
happened somehow...

We always have three phases:
1. unrestricted activity
2. preparing for a release (dealing with regressions, etc)
3. beta testing period
Currently we move from stage 1 to 2 randomly, when somebody suggests
it's time for a release,
and achieves consensus. Normally it's proposed a few times before it
actually happens.
That's really crazy.
And stage 3 is a bit random. We apparently have a few projects which
must be tested (dsimcha's, for example)
but I think most things that are tested are open source, and could
therefore be automated.
The docs could also be tested for dead links (a common problem).

Proposal #1:

We move from phase 1 to phase 2 exactly n days after the previous release.
ALL pull requests originating prior to that date are either merged, or
given a comment as to why that cannot be merged.
Then, all regressions since the previous release are fixed. Issues
deemed crucial to the release may be merged even
if they originate after the n days, but we should try to minimize that.
When these are fixed, we enter stage 3. The 'Beta Test Program'
projects are tested for regressions.
A beta is released. We wait for m days for regression reports.
Any regressions result in another beta. After p days without further
reports, a release is made.
This final step may be done multiple times, with a beta release + p
days each time.

n >> m > p.
Probably something like n = 45 (?), m = 4 and p = 1 day to achieve a
60 day release cycle.
It'd actually be possible to look through the newsgroup and find what
these numbers have historically been...

Proposal #2:

During the stabilisation phase (phases 2 and 3), discuss goals for the
following release.
In the lull while waiting for beta reports to come it, it's a great
opportunity for strategy.
If major contributors have particular plans, they can say what they
plan to work on.
Quite good if there is a theme -- major features to be added in
Phobos, or particular
focus areas of the compiler, eg "attributes", "type inference",
"performance", "debugging",
"executable size", "concurrent gc", "SIMD", "inout", "64 bit", "shared
libraries".
Specific important bugs or pull requests.

Put the goals in the changelog under the "Under Construction" section, which
has just been "1. Shared libraries for Linux" for quite a long time.
It should change in every release.
Everybody reads that page -- it's a great place to put a quick
overview of the plans for the benefit of
the entire community. Add a link at the bottom, "to contribute to
future releases, click here".