Everything has a component now, and I did a whole bunch of versions
while I was at it.
The components really need to be adjusted (review/approve the
taxonomy and migrate towards that), since I found I had a hard time
picking the right one, especially in relation to the project builder,
apis and artifacts vs dependencies. I was probably horribly
inconsistent. Anyway, even as is that should help to identify dupes/
groupings (eg, line up all the requests in the artifacts/repositories
component against the upcoming artifact spec).
General approach I've been taking for versions:
- if it may work but needs testing, 2.0.x
- if it looks fixable without architectural changes, 2.0.x
- if it is a feature/bug related to existing architectural goals for
2.1.x, then it goes with that
- otherwise, 2.2.x
This doesn't meant 2.*.x are actually "scheduled" - I'd expect the
next step is to go through 2.0.x and pull things into 2.0.8 that make
sense, clean out things that work, etc. Then repeat for 2.0.9 after
the 2.0.8 release is done. Same process would apply for 2.1.x, etc.
This is going to be a bit more brutal this time around due to the
volume, but I think that's an appropriate flow for the future as we
just bring in new issues.
I expect if we do that for all the review, 2.1.x is going to be too
big. We'll need cut that right back to what the core goals are there
(the arch. goals page looks to me like "everything we want to fix in
Maven", not what the next minor release should be too). That's fine -
we can get the big picture together and then start to carve it up.
Hope this is suitable to everyone. I'll write it up early next week.
Please do spend 30 minutes with it, as Jason has suggested -
especially if you haven't looked at your own reported/assigned bugs.
It'll make this task a whole lot easier.
Cheers,
Brett
On 16/06/2007, at 12:02 AM, Brett Porter wrote:
Quick note - I've added a 'shared components' version for assigning
the stuff that isn't in core's versioning scheme (we need to ship
them out of the project later on - have added that to my notes).
I'm assigning components where they are missing so that it might be
easier to identify dupes.
- Brett
On 15/06/2007, at 3:28 PM, Brett Porter wrote:
Heh, my mail was trying to tell me something as it rejected a
message asking about these at the same time this arrived :)
MPA-90 and 91 came up to the top of my iGTD box today and I was
going to work on them this afternoon - but noticed things had been
changed.
This sounds good to me, and I'll get started on the 'reviewed'
bucket. If I understand you correctly, these aren't actually
reviewed yet, and this bucket should go away over time (with
things going straight into an expected roadmap, right?) So no new
issues go in there, and we try and break it down, but get more
vigilant on the unscheduled bucket.
I strongly disagree with the Documentation 'version'. I've found
it to be problematic, and the components should be sufficient.
Just exclude those from the filter to get the technical issues. I
understand we don't currently distribute and version the
documentation, but I think we are all of the opinion now that we
should, right? I've no problem keeping it for clean up purposes,
as long as (again) no new things are going in there.
So I'll continue by reviewing some jiras and documenting this.
Thanks,
Brett
On 15/06/2007, at 3:18 PM, Jason van Zyl wrote:
Hi,
The 2.0.7 release will go out tomorrow, and in order to get some
decent vote feedback it would be good to clean up JIRA so that we
have an accurate 2.0.x list people can vote on for issues they
would like fixed in 2.0.8. I created a "Documentation" version so
that technical issues wouldn't be polluted by documentation
issues. I also created a "Reviewed Pending Version Assignment"
where I put everything that's probably been looked at (probably
not entirely true) so that anything coming in from now on in the
unscheduled we can process. I think between all of us we can
probably keep that empty most weeks by assigning a version,
closing if duplicated, or closing due to being incomplete.
Some simple things you can do if you have a few minutes to spare:
- look in the reviewed pending version assignment and try to put
the issue in 2.0.x or 2.1.x
- pick your favorite component and look for duplicates
- issues describing a remotely complicated problem without a
sample project get close as incomplete
- look at issues you've reported and check and see if they have
been resolved
- linking issues up that look similiar so we can close issues
together if they are resolved.
Even if we get rid of the complete cruft like already resolved,
dupes, and incomplete issues that will greatly help.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
--------------------------------------------------------------------
-
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]
---------------------------------------------------------------------
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]
