On 19 January 2012 21:22, Oleg Kuporosov <[email protected]> wrote: > > > 2012/1/19 Jacob Carlborg <[email protected]> >> >> >> >> >> 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". _______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
