[Squeakfoundation]re: release process (was "Shrinking alpha image")
craig.latta at netjam.org
Sat Mar 22 00:05:01 CET 2003
> If you have an operational model of how we get to where you propose
> we should be, go ahead.
> A few questions it should answer -
> * How do we know what the community will come up with beforehand?
We don't need to read minds. We can just decide that features get
*scheduled* before they get included. E.g., if you come up with some
whizzy new feature during the 3.6 cycle, you can suggest it for a future
feature schedule (3.7 or later).
Of course there will be some deviation from the ideal. For example,
critical fixes often get special dispensation (inclusion into the
current schedule instead of waiting for a future schedule). In general,
though, I think it's good to encourage planning the next several
releases. In particular, at any given time there are usually large
features (e.g., changing the format of compiled methods) that one can
imagine happening in the next major release as opposed to the next minor
I don't see a contradiction here.
> * How do we get everyone to actually test and document everything?
If it's not tested and documented, it gets rejected.
> * How do we avoid being such pests that nobody actually wants to submit
By making releases that are useful, and by gently pointing to release
standards around which there is community consensus.
> ...the second and third are reasonably addressed by QA tags -if we
> stick to them and accept nothing that doesn't have them-.
Yeah, I think that could work.
craig at netjam.org
More information about the Squeakfoundation