Sent from my [rhymes with tryPod] ;-)
On 29 Dec 2009, at 05:49, Jason van Zyl <ja...@sonatype.com> wrote:
There are 511 issues left if you exclude the documentation fix
version. Call it 30 minutes an issue on average and that's ~250 man
hours. If we could get 10 people in January to do 25 hours (which is
a lot for most people) and try and make it easier for users to
validate fixes we might be able to pull it off in January.
between my son and his sleep deprevation torture that he is
delivering ( I connfess, son, it was I who conspired with your mother
to bring you into this world! ) and work commitments, I do not think I
will have availability before feb
- Stephen
http://jira.codehaus.org/secure/IssueNavigator.jspa?fixfor=13143&fixfor=14504&fixfor=16088&fixfor=16089&fixfor=14118&fixfor=16090&fixfor=16087&fixfor=15103&fixfor=16094&fixfor=16093&fixfor=15565&fixfor=15472&fixfor=15554&fixfor=13145&fixfor=13142&fixfor=13141&fixfor=15996&fixfor=14593&pid=10500&status=1&status=3&status=4&reset=true&show=View+%26gt%3B%26gt%3B
On 2009-12-29, at 12:12 AM, Jason van Zyl wrote:
On 2009-12-28, at 10:34 PM, Brett Porter wrote:
On 29/12/2009, at 1:39 PM, Brian Fox wrote:
Is there anything pressing that calls for a 2.2.2? The 3.0's are
moving along and are quite usable.
I was just thinking of shipping the existing fixes and anything
obvious or regressed in 2.2.1.
On 29/12/2009, at 1:44 PM, Jason van Zyl wrote:
I think that the 3.x code is far enough along that if anyone is
going to do any work I think that enough work has been done in
3.x to stop working on 2.x.
So much has been fixed, tested and tuned that at this point after
using 3.x for a long time and with the tests that are in place
that I'd really like to flatten all the 2.x versions in JIRA and
toss them into the 3.x bucket. Then scour the issues and just
throw out anything that remotely looks like garbage, close things
out and get people to test against 3.x and try and get the issue
count down to the nuggets that are really going to be new
features or are really bugs.
Might as well, that's realistically the situation anyway. Nobody
is going to do major work on 2.x faced with uncertain prospects in
porting it over to 3.x. Keep anything purely specific to 2.x in
the 2.2.x bucket and move bigger stuff out.
There's not really much to port really at this point. The ITs can
always be improved but there is a pretty rock solid set of tests
there.
But we have to be 100% focused on shipping 3.0 if that's the case.
You can't put an end to 2.2.x when there's no end in sight to 3.0.
I am not interested in 2.x, but that's why I asked if anyone else
was interested in working on it. I'm not putting an end to 2.x, I'm
just not going to work on it anymore.
JIRA needs to reflect exactly what needs to be done for 3.0-
alphas, betas and final so we can start counting down. It's fair
enough to not specify a date, but at least the target needs to be
in sight to get anyone inclined to help with polishing work.
It's primarily testing work that needs to be done. The site plugin
is probably the only hole that needs to be filled as that one will
affect a lot of users.
For example, where are the issues that reflect switching to Guice
and OSGi that we keep hearing about?
Neither of those are going to happen in the 3.0 time line. We've
got Nexus running on Guice (with a Plexus shim) now and we need to
run that through the grinder for a while. When that works we can
take a look at Maven. Nexus uses almost everything in Plexus that
Maven does and we've not had to change any of code. The Plexus shim
adapts everything necessary. But we'll have to add to the shim to
account for some Maven particulars because all the old code has to
work. This is not a small job, but we've got to get Maven off
Plexus pronto. We are not attempting to do the Guice + OSGi in one
shot in Nexus and we shouldn't attempt this with Maven in one shot
either. Stuart could probably get Maven working with Guice for 3.0
but I think that would be pushing it. So I think it best to take
Guice out of the 3.0 deliverable.
The OSGi runtime will likely follow what we're doing in Nexus.
After getting Guice working as a replacement for Plexus we will
attempt to get Nexus running on Guice + Peaberry for OSGi and then
we'll run that through the grinder as well. We don't know how long
that will take, the Guice stuff is working now but the OSGi is a
whole other story. A repository of bundles doesn't really exist
(we're trying to fix that with osgi.sonatype.org) and all the
dependencies would need to be bundle-ized. So we're trying to add a
feature to Nexus to turn any JAR into a bundle on the fly. This is
fraught with problems. So I can say pretty definitively no Guice or
OSGi for 3.0, but can easily happen in a 3.1. Ultimately to users
they shouldn't notice anything, and that's just a lot of testing.
There is plenty to do with 3.0 without Guice and OSGi.
I just added one for slf4j that you mentioned. What other things
are planned that are not in there so we can drive towards a goal?
I think we're done to be honest. If JIRA could be trimmed down, by
clearing out the silliness, and starting to validate that issues
marks as bugs have been fixed in 3.x then that will get us most of
the way there. For what remains trying to bug fix and write ITs is
really the only thing left I really want to tackle. If crap pops up
that we need to fix for m2eclipse I would probably sneak in but
otherwise testing and validation is largely what remains.
Using SLF4J as the API will really amount to working over time at
injecting a logger with the SLF4J API instead of the Plexus API
one. At very least maybe we can cleanup the Plexus SLF4J stuff so
that if we do provide a way to configure the logging using standard
SLF4J stuff it won't change when we change the API internally. We
are doing a lot of logging and tracing work in Nexus and M2Eclipse
right now so some of this might fall out of that and go back into
Maven but if someone else wants to tackle that it would be cool.
I'd also avoid planning 3.1 alphas at this stage. Focus on getting
3.0 out, and everything else that is after 3.0 can be up for grabs.
There I'm only trying to collect things that we cannot change in
3.0. If I've seen things like POM changes I've just been pushing it
into 3.0.alpha1.
There are ~650 issues and I think in four weeks with a little
teamwork we can probably drive that down to the 50 things we care
about.
I'm happy to help clean up issues, sure. I make a small dent in it
occasionally, but it tends to sap any energy before starting to do
any actual work.
I'll make another pass. I'm sure there are a ton of duplicates, and
stuff that's actually been fixed in 3.x. It really is just a lot of
validation work and writing ITs. Any works that needs to be done
will really only be for fixing compatibility issues at this point.
- Brett
---
------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
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
