db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew McIntyre <mcintyr...@gmail.com>
Subject Re: Bugs and 10.1.2 release
Date Fri, 02 Sep 2005 20:05:49 GMT
On 9/2/05, Rick Hillegas <Richard.Hillegas@sun.com> wrote:
> However, methinks it's worth hammering out "rules of
> engagement" whenever we have to scratch a collective itch. A release,
> for instance, is a collective itch.

True, but eventually it is up to one person, the release manager, to
provide the distributions to the community for testing, ensure their
quality, gain community approval, sign the binaries, and publish them
to the world.

> I think it would be reasonable for the Release Coordinator to publish their "rules of
> engagement" soon after accepting the job.

The only rules that apply are the Apache rules for releases. See:

http://www.apache.org/dev/release.html
http://httpd.apache.org/dev/release.html
http://jakarta.apache.org/commons/releases/release.html - very
specific to Jakarta Commons but gives a good idea of the mechanics
involved.

(fyi, I'm putting together a Derby-specific page like that last one.)

Note that while there are a lot of mechanics to putting together a
release, there aren't really a whole lot of rules. All you really need
to do is announce to the list you plan on having a release. Marking
whatever bugs/features in JIRA you plan on including in the release is
a good idea, for tracking purposes (both for the release manager and
everyone else). Setting a rough date is also a good idea because at
some point you have to draw a line in the sand for getting
fixes/features into the release.

As for testing, there can never be enough testing, and any test
results that the community can provide are a good thing.  :-)

People interested in contributing test results should work out what
sort of tests they think provide significant value amongst themselves
and just do the testing. A wiki for coordinating testing would be a
*very* good thing, to prevent unnecessary duplication of testing. We
can revisit that once we have a wiki set up.

In fact, I've noticed that a lot of people use their project's wiki to
track release-related issues. It's a great idea, since it's web
accessible and all, but it's a necessity to track release progress in
STATUS, because that's the officially accepted location for such
information.

> The community can debate and amend these rules
> and, if the Release Coordinator doesn't like the conclusion, they can
> resign the post. In fact, the Release Coordinator can resign at any
> point if they feel they aren't getting the community support they need.

Yes. It's important to note that the release manager can abandon the
release at any time for any reason, and also that any other member of
the community can put together a competing release if they don't like
the way things are being handled by the other release manager.

> It looks like Andrew is being volunteered as the 10.1.2 Release
> Coordinator. If he's willing to perform this task, he can tell us what
> kind of support he expects from the rest of us. We can discuss it.

Ok, here's my plan: let's say we'll do the 10.1.2 release around
October 28th. So, I'd like for everyone to find the bugs that they
think should be fixed in a 10.1.2 release, and mark them as such.
Then, peruse the bugs marked for 10.1.2 and assign yourself to the
bugs that make you feel itchy. Start work on those bugs. When we get
closer to the release date, we can tighten up the list of issues
assigned to the 10.1.2 release, moving items that are unlikely to make
it in to 10.1.2 out to future releases. A week or so before the 28th,
i'll put binaries together and we'll take a vote. Oh, and if anybody
can contribute testing resources, please let it be known.

Please let me know if you think there needs to be any modifications to
that plan.

(I think this is a good place to stop before I ramble any further. :-)  )

andrew

Mime
View raw message