Hi,
Alec is bringing up the Alpha release process.
Alec Flett wrote:
This is what is I think most interesting to me personally, and what I
think could could mean the difference between regular old milestones
(like we do now) and real "releases" My personal take on two months
milestone/alpha releases:
1) We, as a team, anticipate an upcoming milestone/alpha release
within 2-3 weeks of the actual release. This means we delay risky
fixes until the beginning of the next milestone. I would hope that
this "buckle down" period is identified as a part of the milestone
schedule from the get-go.
2) In the last week (?) of the release, the product release team
identifies the critical bugs necessary for the milestone and stops
accepting most "easy" fixes.
3) The development team doesn't try to accomplish too much in one
milestone. For instance, if we finish the bulk of the dashboard phase
1 work in the first 3 weeks of milestone 1, then we stop working on
dashboard in milestone 1 and focus on bringing other key tenets up to
milestone 1 level - or we make more robust tests, or we do
architectural planning for milestone 2, etc etc..
I agree with all of this on a general level: we need to find a process
to stabilize the release in the end of cycle.
There are 2 ways of doing this:
- policing the commits: that's basically Alec's proposal here above
- branching: used in other Open Source projects (see Fogel's)
I think we can go away with policing right now because we do not have a
lot of outside contributors with commit privileges. We can therefore
hold on patches during the end of cycle phase. Note that this process
may stall some developers (working on feature straddling 2 releases for
instance). Those can always create their own working branch (as Andi did
at the end of 0.6 for instance) but that's a burden on them to merge
everything back once the release is declared.
Branching is less constraining from a development standpoint but there's
the added burden of committing to 2 branches for a substantial amount of
time, something we may want to avoid right now. Eventually (when we have
a big enough community of committers), branching might be the only way
to go though.
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
