Two things I definitely want to highlight here:
1. This is not my process. I'm obviously interested in getting Maven
releases out the door, and having them be of the highest quality we can
achieve. This means there is no way I can be the gatekeeper on every
release; I simply don't have that kind of time, particularly since there
are plugins that need attention and like others, I have other
responsibilities at a day job that don't always leave me time to head up
these efforts. I appreciate the sentiment, of course, but this has to be
a group effort with everyone dedicated to timely, stable releases.
2. To me, the goal of high quality releases starts and ends with test
coverage. We are all capable of putting together very deliberate,
targeted tests for the things we're working on, if we take the time to
do it. What I'm getting at is it's not enough to apply a patch or fix a
bug; the developer that introduces this sort of code also has a
responsibility to contribute tests for the new code and any old code
that it modifies. The idea is to prevent regressions, and validate our
assertions, so we don't all look like horses' asses by saying something
works when it doesn't...which is a sensation I think we've all felt in
the past.
Whatever else we include in a particular Maven release, we should make
it top priority to keep making net progress in terms of functional test
coverage (not just the graphs produced by cobertura or emma). I think we
hit a milestone with 2.1.0-M1 in terms of this, but we really need to
continue improvement here. Benjamin's work in this department IMO is
some of the most important work being done in Maven anywhere, and I
applaud him for it.
This is how I think about new code changes: If it doesn't have a test,
it shouldn't be included in a release. If the code it changes doesn't
have tests, then it still shouldn't be included in a release.
My two cents...
-john
Jason van Zyl wrote:
On 18-Dec-08, at 3:42 AM, Brett Porter wrote:
Hi,
I did what seems like my bi-annual review of all the unscheduled
issues today, reviewing and scheduling where appropriate. There's 10
left with open questions, and I'm making an early new years resolution
to keep on top of new reports :)
Jason, Shane - as instructed I put all the reported regressions with
trunk into 3.0-alpha-3. I expect some of these are already fixed so it
would be worth a run through them before releasing alpha-1 to see if
some can be closed out.
If they have an IT and they work close them. But I don't think we can
close the issues without an IT which is why I've honestly not gone after
them even though I know some of them work from observation. Benjamin
might have some hiding out somewhere.
However, the main purpose was to identify reported regressions in
2.1.0-M1, of which we have a couple. So 2.1.0-M2 is down to about 11
issues including some patches to review. I updated the roadmap, moving
Doxia to M3 as they round out the 1.1 release. I also moved the
MNG-624 out to 2.2 (or beyond) while Ralph reviews his implementation.
Given enough time to wrap these up, I'd like to shoot for an M2
release by the end of the year. M3 and M4 could follow quickly since
the work is already done on branches.
I think here again you need to defer to the massive amount of work John
did for the release. As far as I'm concerned that's his call as he's the
defacto release manager. If he wants to hand it off that's fine.
Cheers,
Brett
--
Brett Porter
br...@apache.org
http://blogs.exist.com/bporter/
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.
-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
