[WG: Sakai QA] [Management] Release Process Proposal

[Clay Fenlason]

Some comments in-line:

On Thu, Jul 30, 2009 at 11:21 AM, David Haines<dlhaines at umich.edu> wrote:
> As pointed out in the release proposal there are a couple of different kinds
> of changes that can end up in a release.  Some are incremental changes and /
> or fixes that aren't controversial should be in a release soon as general
> improvements.  There are also bigger changes that require more design and
> thought.
>
> It seems that the 2.7 release will have the first kind of changes.  It also
> seems like over-planning to work at try to find out what ought be in 2.7 and
> then plan dates from there.

I don't think that's what the proposal lays out.  It's rather to:

1) Identify the bigger changes, and route them to the PC, then go back
and survey the smaller changes
2) Document the smaller changes, including a rough risk assessment
that gives QA planning some clues about how to organize its
activities.  This will undoubtedly involve at some point some
controversy about what really is a bigger change, and that will need
to be dealt with in discussion - another reason this shouldn't just be
left until a freeze date (and potential surprises during QA).
3) With all this information in hand, come up with a credible plan
that includes realistic dates

> It would be more realistic to establish
> specific dates based on the practicalities of doing a release and make it
> clear to the community when changes need to be ready to get into the release
> cycle.

Right, so I don't think we're disagreeing here. I'm just emphasizing
the part where I don't think the "practicalities of doing a release"
can be assessed without a close survey of the proposed set of changes.
I'd also emphasize (I don't think you're leaving this out, I just want
to be clear) that it's not simply a case of having code changes ready
before code freeze, it's also making sure there is enough
documentation and test cases prepared that QA can play its role, and
contributing institutions can plan accordingly.

> That allows for groups to plan on their own without an explicit or
> implicit expectation that the Sakai foundation will be orchestrating the
> work.  If a group want's to have their changes in the release they know the
> deadlines, if one group wants to help out another with QA or such they will
> be able to know when their efforts are likely to be needed.  This doesn't
> mean there isn't release management, just that it is incumbent on community
> members to take the lead on getting a specific change into a release.
>
> For a release with bigger plans it makes a lot of sense to make the release
> date dependent on the necessary set of features being available.
>
> - Dave

~Clay