You could also cut beta-2 today and just not release it. Move on to beta-3 immediately to merge. If the merge turns out to be a disaster, at least you have a branch and an artifact to deploy as a backup plan. Regardless, I don't expect anything to go tragically wrong.
>From my perspective of a Release Manager, milestones should have defined boundaries. Throwing in Guice/Aether at the end of the beta smells to me. There is always risk involved when importing a huge chunk of code no matter how much testing it has. I believe this discussion is merely about risk assessment. It looks like the committers prefer a more conservative approach. Paul On Fri, Aug 6, 2010 at 9:53 AM, Jason van Zyl <ja...@sonatype.com> wrote: > > On Aug 6, 2010, at 10:44 AM, Arnaud Héritier wrote: > > > The advantage is to do what I did this morning in few minutes. > > I found a OOME on Aether/Guice branch (reported to benjamin but not in > MNG because it's not yet integrated) and then I validated it wasn't here in > current trunk. > > The problem is that I had to rebuild both of them hat users won't do. > > Without the beta2 release, each time you'll have to check if the problem > reported comes from Guice/Aether or from changes done for now in beta2. > > It is more for you who'll work on it to easily ask a comparison. > > > > I honestly don't want to run, look at, or debug the current trunk. If it's > decided that we're going with the Guice/Aether code then we fix it properly > and release it. If we're not going to make an announcement for beta then > just pull a version from the grid now and we'll merge. This will also give > time to people who want to learn more about the Aether code to help add > tests and help fix the performance problems. Conservatively speaking with > Benjamin and Igor working on fixing the lead/performance in Aether we're > looking at a week starting next Tuesday. If people start helping us with the > Aether code 1) you'll see that it's just as easy to work on the Aether code > in Github as here, and 2) It will significantly speed up the release if we > have more people looking at it. > > > As I said we are also not required to do a big announcement for beta 2. > We can do it at the same time we do the beta 3 to let users know it is here > in case of issue. > > > > Now it's you're choice. It's you who are doing. > > > > Cheers > > > > Arnaud > > > > > > > > > > On Aug 6, 2010, at 4:31 PM, Jason van Zyl wrote: > > > >> Then we wait until we fix it. What difference does a week make at this > point. Honestly? > >> > >> On Aug 6, 2010, at 10:27 AM, Stephen Connolly wrote: > >> > >>> Given that Arnaud found a bad memory leak in the Aether/Guice version I > >>> think it would be good to get beta-2 out now without Aether/Guice > >>> > >>> Then fix the leak and roll beta-3 as soon as the leak is fixed > >>> > >>> -Stephen > >>> > >>> On 6 August 2010 15:10, Jason van Zyl <ja...@sonatype.com> wrote: > >>> > >>>> > >>>> On Aug 6, 2010, at 10:01 AM, Brian Fox wrote: > >>>> > >>>>> 2010/8/5 Arnaud Héritier <aherit...@gmail.com>: > >>>>>> Ok, > >>>>>> > >>>>>> Thus talking is good but doing is better ( I know I'm talking more > than > >>>> I'm doing :-) ) > >>>>>> > >>>>>> Could we have a consensus if we : > >>>>>> - release now the trunk as a beta 2 without Guice and Aether. With > that > >>>> we'll have a solid base to compare future changes with. We know it is > stable > >>>> and it is better than beta 1 (it solves some issues like for the site > plugin > >>>> and also in // builds). If the vote is called now we can deliver it to > users > >>>> for Monday. > >>>>>> - just after the beta2 release we merge changes required for Aether > and > >>>> Guice and we start the release process for a beta 3 we'll deliver at > the end > >>>> of next week. > >>>>> > >>>>> mvn:release prepare release:perform takes at most 30 minutes so I > >>>>> don't see any harm in firing them both out there. > >>>>> > >>>> > >>>> Other then it being highly confusing to the general user base. We have > >>>> beta-2 and then three days later trying to message making two drastic > >>>> changes and releasing it again. Also what this entails is that if > someone > >>>> does report a problem with the container or artifact resolution it > will have > >>>> to be addressed in beta-3 anyway. If we're going to release a beta-2 > that is > >>>> effectively not going to be support I don't see much value in that. > Also > >>>> between Stuart, Benjamin, Igor, and myself anything in the container > and > >>>> resolution level will get fixed quickly. > >>>> > >>>> Why don't you just try the site plugin with the branch with Aether and > >>>> Guice and make sure it works? I think taking the time to make sure > those > >>>> changes work is better then dealing with the WTF responses from users > when > >>>> we drop two betas out in the course of three days. The vast majority > of > >>>> users are not using 3.0-beta-1 and so I don't think the average user > cares > >>>> that a the site plugin doesn't work. I would prefer we delay a single > decent > >>>> beta of what we are ultimately going to ship. > >>>> > >>>> It's not hard to spin out two releases, but it's just harder to manage > >>>> because when issues come flying in we're dealing with two completely > >>>> different animals. People are unlikely to specify the right version > and > >>>> we're just going to have a lot more busy work then necessary. > >>>> > >>>> Let's make one good release wait a week and push out what we actually > plan > >>>> to support. > >>>> > >>>> I personally think dropping out two betas that are completely > different in > >>>> the span of 3 days is just totally confusing for users and not the > tone we > >>>> want to set building up to the release of 3.0. > >>>> > >>>>>> > >>>>>> With that we'll try to receive feedback from users and we'll easily > >>>> validate if problems are related to Guice or Aether by comparing > results > >>>> with both versions. > >>>>>> At the end of the month we can push out a new beta with all fixes > we'll > >>>> have. It will be always possible to decide to remove Aether if some of > you > >>>> have a better solution or aren't satisfied by the change (I would > prefer to > >>>> have done that in an alpha releases cycle but now we are in beta we > cannot > >>>> come back in rear). > >>>>>> > >>>>>> WDYT ? I think it is important to push out new releases to show to > our > >>>> community that we are always active and we are going in the good > direction. > >>>>>> > >>>>>> Arnaud > >>>>>> > >>>>>> > >>>>>> On Aug 5, 2010, at 11:06 PM, Dennis Lundberg wrote: > >>>>>> > >>>>>>> Hi all > >>>>>>> > >>>>>>> Some very important questions have been asked regarding Jason's > >>>>>>> proposal. I usually let my first impressions sink in a bit before I > >>>>>>> reply. That often help to make my comments more about the facts and > >>>> less > >>>>>>> about the feelings, and we've seen a lot of feelings in this > thread. > >>>>>>> > >>>>>>> The first thing I would like to happen is that we release > 3.0-beta-2 > >>>>>>> *without* merging the proposed code. There are two reasons for > this. > >>>>>>> > >>>>>>> 1. The Site Plugin, which most of you know is something that I've > >>>> worked > >>>>>>> quite a lot on, is currently in limbo. On one hand we have the > stable > >>>>>>> 2.x trunk of the plugin which works with Maven 2, but not with > Maven 3. > >>>>>>> We also have a 3.0-SNAPSHOT branch of the plugin, thanks to Olivier > and > >>>>>>> Hervé. But that currently don't work with any released version of > Maven > >>>>>>> because of a bug in Maven 3.0-beta-1. In order to gain momentum and > >>>>>>> field testing for Maven Site Plugin 3.0 it needs a stable version > of > >>>>>>> Maven to work with. There are too few people working on the Site > >>>> Plugin, > >>>>>>> and if it needs to be rewritten yet again there is a risk that it > will > >>>>>>> never be ready. > >>>>>>> > >>>>>>> 2. Release early, release often. Give the users a choice here. They > can > >>>>>>> choose to use Maven 3.0-beta-2 which will work much like beta-1 > did, > >>>> but > >>>>>>> with lots of bugs fixed. Or a few weeks later they can use > 3.0-beta-3 > >>>>>>> the proposed code changes merged in. If the new stuff doesn't work, > for > >>>>>>> whatever reason, they can switch back to beta-2 while they wait for > a > >>>>>>> bug fixed beta-4. > >>>>>>> > >>>>>>> As for they proposed code bases I am not qualified to make detailed > >>>>>>> comments, so my comments will be very high level. > >>>>>>> > >>>>>>> > >>>>>>> Guice > >>>>>>> > >>>>>>> IIUC this means that we would replace one (external) IOC container > with > >>>>>>> another (external) IOC container. If the bar for being allowed to > >>>>>>> participate in the development of Guice is at the same level as it > has > >>>>>>> been for Plexus, then I have no problem with this switch. > >>>>>>> > >>>>>>> I am +1 on integrating the Guice code after beta-2 has been > released. > >>>>>>> > >>>>>>> > >>>>>>> Aether > >>>>>>> > >>>>>>> One thing that I really think has been successful here at Maven has > >>>> been > >>>>>>> when we have set up proper APIs that abstracts the implementation > and > >>>>>>> let the users pick a suitable implementation for their needs. Two > >>>>>>> subprojects come to mind: SCM and Wagon. > >>>>>>> > >>>>>>> If the API part of Aether is anything like that, then that's a good > >>>>>>> thing in my book. I haven't looked at the code, only the high level > >>>>>>> presentation, but I have high confidence in those who have worked > on > >>>> it. > >>>>>>> Having the API hosted outside of Apache is fine by me if it means > that > >>>>>>> more projects will use it. The more the merrier. > >>>>>>> > >>>>>>> When it comes to the implementation I'm undecided. It does mean > that we > >>>>>>> will make an integral part of Maven external, which can lead to > >>>> problems > >>>>>>> with issue tracking etc, as pointed out by others. On the other > hand it > >>>>>>> makes sense to use the collective knowledge of the people who is > >>>>>>> responsible for the API, to also work together on implementations. > >>>>>>> Perhaps the Maven repository implementation can be moved back to > the > >>>>>>> Maven project, when things have settled down. > >>>>>>> > >>>>>>> I am +0 on integrating Aether after beta-2 has been released. I'll > let > >>>>>>> others with more insights decide. > >>>>>>> > >>>>>>> > >>>>>>> On 2010-08-03 20:21, Jason van Zyl wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> We have two major pieces that we, Sonatype, would like to merge > into > >>>> Maven 3.x trunk. > >>>>>>>> > >>>>>>>> The first are the Guice changes that we've been talking about for > a > >>>> while, and the second is the introduction of Aether which is our > second > >>>> attempt at a stand-alone repository API. The PMC is aware of Aether as > Brian > >>>> reported it in our quarterly report to the Apache Board, but other > >>>> developers who are not on the PMC and the community in general might > not > >>>> know much about it. > >>>>>>>> > >>>>>>>> I just posted an entry giving a very high level description: > >>>>>>>> > >>>>>>>> http://www.sonatype.com/people/2010/08/introducing-aether/ > >>>>>>>> > >>>>>>>> There is a resources section at the bottom of the post for those > >>>> interested in the sources, issue tracking, wiki and mailing lists. As > part > >>>> of some of the research we are about to embark on with Daniel Le > Berre, > >>>> Aether will likely look more like p2 as time passes and as a final > resting > >>>> place the Eclipse Foundation is more likely then Apache. I know people > will > >>>> ask so I'm answering that now. Sonatype is just about to fully move > Tycho > >>>> over the Eclipse Foundation and we want to see how that goes. If that > works, > >>>> then M2Eclipse is next, and then Aether will follow. > >>>>>>>> > >>>>>>>> At any rate we would like to merge these changes in and make plans > to > >>>> release 3.0-beta-2. > >>>>>>>> > >>>>>>>> So please let us know if you have any objections. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> > >>>>>>>> Jason > >>>>>>>> > >>>>>>>> ---------------------------------------------------------- > >>>>>>>> Jason van Zyl > >>>>>>>> Founder, Apache Maven > >>>>>>>> http://twitter.com/jvanzyl > >>>>>>>> --------------------------------------------------------- > >>>>>>>> > >>>>>>>> First, the taking in of scattered particulars under one Idea, > >>>>>>>> so that everyone understands what is being talked about ... > Second, > >>>>>>>> the separation of the Idea into parts, by dividing it at the > joints, > >>>>>>>> as nature directs, not breaking any limb in half as a bad carver > >>>> might. > >>>>>>>> > >>>>>>>> -- Plato, Phaedrus (Notes on the Synthesis of Form by C. > Alexander) > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Dennis Lundberg > >>>>>>> > >>>>>>> > --------------------------------------------------------------------- > >>>>>>> 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 > >>>>>> > >>>>>> > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> 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 > >>>> --------------------------------------------------------- > >>>> > >>>> We all have problems. How we deal with them is a measure of our worth. > >>>> > >>>> -- Unknown > >>>> > >>>> > >>>> > >>>> > >> > >> Thanks, > >> > >> Jason > >> > >> ---------------------------------------------------------- > >> Jason van Zyl > >> Founder, Apache Maven > >> http://twitter.com/jvanzyl > >> --------------------------------------------------------- > >> > >> In short, man creates for himself a new religion of a rational > >> and technical order to justify his work and to be justified in it. > >> > >> -- Jacques Ellul, The Technological Society > >> > >> > >> > > > > > > --------------------------------------------------------------------- > > 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 > --------------------------------------------------------- > > In short, man creates for himself a new religion of a rational > and technical order to justify his work and to be justified in it. > > -- Jacques Ellul, The Technological Society > > > >
