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.
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
