I should have read your email before I replied. I pretty much agree with
all of what you are proposing. FWIW, the bug I am working on is MNG-624
and yes, it has a ton of votes. It also addresses MNG-3057, MNG-2446,
MNG-2412 and probably several others that are related. My change is
pretty much working but I want to test more and unfortunately it is on
the current 2.1.x branch which runs terribly slow. I am sure I am going
to have conflicts when I try to merge it in with 2.0.10-RC so I am not
in too much of a hurry to commit it anywhere until we figure out which
branch is the "real" 2.1.x.
Ralph
Brett Porter wrote:
On 26/08/2008, at 6:44 AM, John Casey wrote:
To start, I'd personally prefer to see the code we current have in
the release process designated as 2.1.0. It's seen a lot of change to
the internal implementations, and while we've gone to great lengths
to ensure it's functionally compatible with 2.0.x, it contains a
fairly risky level of change for a revision release. This means that
the 2.0.x branch would be rolled back to the 2.0.9 release, and we'd
proceed toward a 2.0.10 that fixes the worst of the regressions with
a minimal of code change. At that point, I'd prefer to see 2.0.x go
into end-of-life mode soon, with 2.1 and later replacing it.
+1
From there, I'd propose that we make a plan. I think we have a long
list of features we'd like to implement and other features we'd
really like to reimplement. No doubt each of us has his/her
favorites, but what I'd like to suggest is using the survey tool we
used for the plugin priorities to come up with a ordered set of
priorities for the features we want to include. Then, we can chop
that list up (maybe every fourth feature), and call them 2.2, 2.3,
2.4, etc. At this point, 2.1 would be a baseline that is as near as
possible to perfect compatibility with 2.0.x, and 2.1.1 might fix
regressions in that code until we have the agreed-upon features for
2.2 done.
+1 to the approach. I like the idea of having a clear objective for
when it is "done". I think we could do milestone/beta releases along
the way to get some feedback on the new features.
I would lean towards still doing that for 2.1: make the current 2.0.10
code a milestone/beta release to see how it goes in the wild as is (I
believe these will still get reasonable exposure), and pick off 3 or 4
important features to include for the final release. However, if
consensus is to just go as is for 2.1 and immediately move to 2.2
that's fine with me too.
I say this because we basically already have implementations for
reactor changes, pgp security, and parallel downloads, for example.
I'm watching the secure passwords thing with keen interest as well,
and I know Ralph has something in mind I think for MNG-612 which is
the most voted for feature - so these could be done in a managable
fashion in a short amount of time to have a fairly compelling upgrade
release. About the only other thing I'd add to that is a review of
what behaviour we want to deprecate so we can start getting it out in
subsequent versions, and move all other features to 2.2+.
In case you're concerned about who's going to drive the items on this
list, my own feeling is that it needs to capture the sense of the
development community. To that end, the survey should be conducted
among developers, without direct input from users. However, each
developer should be acting in the interests of the user community at
least part of the time, so we need to focus on balancing the cool
with the useful to make sure our releases are relevant to users.
+1, I'm happy with starting to encourage JIRA voting as the way to
guide features that are in demand by users.
Of course, it also means that all of us will sometimes have to be
patient for the feature near and dear to our hearts to come up in the
release plan, and help get the other things out of the way first.
However, I think this could help us unify a lot of the different
directions we all seem to be heading WRT Maven's core, and maybe keep
things moving forward at a steady pace.
Need to be careful with this - I would say we choose the features that
people are willing to work on. As long as someone is upfront about
what they are going to do, it is done properly and we agree that it's
good for Maven, we should have room to add things to the release. It's
a balance - we don't want to get in the way of good work, but we don't
want to lose focus either.
I think it would be a non-issue if we have some clear objectives set
out up front since the willing contributors are involved in both parts
of the process. Common sense will dictate whether something is a good
addition or a disruptive change at the time.
To get things started, we have a long list of proposals out here:
http://docs.codehaus.org/display/MAVEN/All+Proposals
Also, from users, we have these:
http://docs.codehaus.org/display/MAVENUSER/User+Proposals
But I'm sure this is at most 10% of what people have in mind for
Maven. Maybe we can have a short discussion of things we need to be
doing in the relatively near term for the health of Maven, then cap
that discussion and turn it into a survey to help us consolidate
priorities. Then, we can chop them up into a release plan and get
started.
Sounds good. How about we open the permissions on the MAVEN space to
everyone and move all the proposals into one place?
Cheers,
Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
