On 15 Jun 07, at 9:06 AM 15 Jun 07, Brett Porter wrote:
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).
Yah, no worries this will only get better making more and more
passes. That's why I don't care if I close a few by mistake, reassign
them wrong. The volume in there just has to drop or it's a completely
ineffective way of trying to track anything.
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
Maybe we should just pool those generally as "Future" as who knows
where along the road they will come. As long as it's additive it
could go anywhere in the future until we actually have a plan for
2.2.x and can schedule things. But 2.2.x is good enough for "Future"
for now. Can always move things back.
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.
Right, that's why the cleanup is necessary so that we can ask for
users to vote, then ask on the dev list for favorites and go from there.
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.
I think we really could eliminate 10-15% of the issues just getting
rid of dupes and incomplete and things that have already been fixed.
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]
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]
