maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Benedict <pbened...@apache.org>
Subject Re: 3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x
Date Fri, 06 Aug 2010 15:02:57 GMT
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 <jason@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 <jason@sonatype.com> wrote:
> >>>
> >>>>
> >>>> On Aug 6, 2010, at 10:01 AM, Brian Fox wrote:
> >>>>
> >>>>> 2010/8/5 Arnaud Héritier <aheritier@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-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@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
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message