You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@maven.org> on 2007/06/15 07:18:16 UTC
JIRA Smackdown
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: JIRA Smackdown
Posted by Jason van Zyl <ja...@maven.org>.
On 15 Jun 07, at 4:27 AM 15 Jun 07, Kenney Westerhof wrote:
> Hi,
>
> I'd like to ask that issues reported by PMC members and core
> developers
> get less strict reviews.
Well, you would most likely assign them to a version/component and
possibly assign them to yourself so they wouldn't end up in the
review pile. That category is really for incoming issues.
> When I find an issue that's rather complex I usually describe
> how to reproduce it, but I lack the time to write sample projects, at
> least when reporting. When i get around to it I reproduce the issue
> and fix
> it in svn - I normally don't attach tests since I can commit in
> core, and i think
> that goes for more developers.
If you're keeping track that's fine but if you want anyone else to
work on it you need to be able to reproduce it. And you need to take
the sample project and turn it into tests or and IT.
>
> Anyway, the incomplete resolution is fine, but closing them will
> make them rather hard to find back. Maybe we could just assign
> these issues to the
> reporters instead, status to 'feedback' or 'incomplete', 'on hold'
> or whatever.
The reporters will get email when it's closed and see the message.
>
> In the future I'll try to attach the tests as I create the issue,
> though that'll
> take me 30 mins more and when I'm in time pressure I feel it's
> better to report
> the issue so it doesn't slip my mind, than to not do it at all
> because of the high
> overhead.
It makes you think about it. If you don't report with a project then
it's going to take someone else an hour to guess at the exact project
structure that caused the failure. I think what they do in Mylar
where creating a context is mandatory, and providing some form of
test so that the whole environment is setup to deal with the issue.
We're not quite there but trying to look at complete issues I now
feel is a waste of my time, and waste of anyone else's time trying to
fix an issue. The users who get attention will be those that make the
effort to provide us with tests. It's that simple. We don't have
infinite free time and at least will help those who make the effort
right now because we need the information.
Could we make this easier in the future? Absolutely, taking a
standard stack trace or specially formatted "core dump" that we can
read with a utility we could do at some point which might help us
pinpoint a problem very quickly but ultimately we need a project as a
basis for a test. Are we going to be more productive taking 10 issue
in a month with good samples and use cases, or a 100 crap issues that
provide almost nothing except a stack trace and a one liner. If
someone can't take the time to write a couple sentences and provide a
project I'm not looking at it.
>
> wdyt?
>
> -- Kenney
>
> 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: 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 and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: JIRA Smackdown
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I agree with that. Normally if I intend to fix it later, I just assign it to myself right away.
-----Original Message-----
From: Kenney Westerhof [mailto:kenney@apache.org]
Sent: Friday, June 15, 2007 7:27 AM
To: Maven Developers List
Subject: Re: JIRA Smackdown
Hi,
I'd like to ask that issues reported by PMC members and core developers
get less strict reviews.
When I find an issue that's rather complex I usually describe
how to reproduce it, but I lack the time to write sample projects, at
least when reporting. When i get around to it I reproduce the issue and fix
it in svn - I normally don't attach tests since I can commit in core, and i think
that goes for more developers.
Anyway, the incomplete resolution is fine, but closing them will make them
rather hard to find back. Maybe we could just assign these issues to the
reporters instead, status to 'feedback' or 'incomplete', 'on hold' or whatever.
In the future I'll try to attach the tests as I create the issue, though that'll
take me 30 mins more and when I'm in time pressure I feel it's better to report
the issue so it doesn't slip my mind, than to not do it at all because of the high
overhead.
wdyt?
-- Kenney
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: 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
Re: JIRA Smackdown
Posted by Brett Porter <br...@apache.org>.
On 15/06/2007, at 9:27 PM, Kenney Westerhof wrote:
> When I find an issue that's rather complex I usually describe
> how to reproduce it, but I lack the time to write sample projects, at
> least when reporting. When i get around to it I reproduce the issue
> and fix
> it in svn - I normally don't attach tests since I can commit in
> core, and i think
> that goes for more developers.
If we're fixing it immediately - sure, because the sample goes into
the tests. But if not, I think we need to hold ourselves to the same
standards since sometimes they sit there for a year or two and you
have no idea what they meant :)
>
> Anyway, the incomplete resolution is fine, but closing them will
> make them rather hard to find back. Maybe we could just assign
> these issues to the
> reporters instead, status to 'feedback' or 'incomplete', 'on hold'
> or whatever.
Absolutely agree. We can't assign to user under the current set up
(though maybe allowing assign to anyone is a good idea), but I think
an addition of "need info" to the workflow is a good idea.
>
> In the future I'll try to attach the tests as I create the issue,
> though that'll
> take me 30 mins more and when I'm in time pressure I feel it's
> better to report
> the issue so it doesn't slip my mind, than to not do it at all
> because of the high
> overhead.
Maybe assign it to yourself to either finish reporting or finish fixing?
>
> wdyt?
Seems to make sense.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: JIRA Smackdown
Posted by Kenney Westerhof <ke...@apache.org>.
Hi,
I'd like to ask that issues reported by PMC members and core developers
get less strict reviews.
When I find an issue that's rather complex I usually describe
how to reproduce it, but I lack the time to write sample projects, at
least when reporting. When i get around to it I reproduce the issue and fix
it in svn - I normally don't attach tests since I can commit in core, and i think
that goes for more developers.
Anyway, the incomplete resolution is fine, but closing them will make them
rather hard to find back. Maybe we could just assign these issues to the
reporters instead, status to 'feedback' or 'incomplete', 'on hold' or whatever.
In the future I'll try to attach the tests as I create the issue, though that'll
take me 30 mins more and when I'm in time pressure I feel it's better to report
the issue so it doesn't slip my mind, than to not do it at all because of the high
overhead.
wdyt?
-- Kenney
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: 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
Re: JIRA Smackdown
Posted by Jason van Zyl <ja...@maven.org>.
On 14 Jun 07, at 10:28 PM 14 Jun 07, 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.
>
Yup. Just to keep an eye on incoming while we clean up.
> 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.
>
I think the vast majority of those issue span versions, and the most
commonly looked at view is the dashboard with versions. This is
really just a deficiency with the dashboard but I want to see the
technical issues. Maybe we can get filters to show as the default
view but given the complexity in trying to change the way anything is
viewed in JIRA I picked the version for documentation.
> 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: 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 and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: JIRA Smackdown
Posted by Jason van Zyl <ja...@maven.org>.
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: 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
>
> ---------------------------------------------------------------------
> 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 and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: JIRA Smackdown
Posted by Brett Porter <br...@apache.org>.
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: 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: JIRA Smackdown
Posted by Brett Porter <br...@apache.org>.
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: 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
Re: JIRA Smackdown
Posted by Brett Porter <br...@apache.org>.
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: 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
Re: JIRA Smackdown
Posted by Jason van Zyl <ja...@maven.org>.
On 15 Jun 07, at 9:58 AM 15 Jun 07, Henri Yandell wrote:
> On 6/14/07, Wendy Smoak <ws...@gmail.com> wrote:
>> On 6/14/07, Jason van Zyl <ja...@maven.org> wrote:
>>
>> > I created a "Documentation" version so that
>> > technical issues wouldn't be polluted by documentation issues.
>>
>> Documentation is neither a version nor pollution. :)
>
> Given the general 'the docs suck' view; this seems like an important
> point that doesn't seem to have had an answer.
>
I didn't at all mean that. The docs are equally important. The
default view of issues skews and obscures the technical issues when
I'm trying to focus on them.
> Hen
>
> ---------------------------------------------------------------------
> 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 and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: JIRA Smackdown
Posted by Henri Yandell <fl...@gmail.com>.
On 6/14/07, Wendy Smoak <ws...@gmail.com> wrote:
> On 6/14/07, Jason van Zyl <ja...@maven.org> wrote:
>
> > I created a "Documentation" version so that
> > technical issues wouldn't be polluted by documentation issues.
>
> Documentation is neither a version nor pollution. :)
Given the general 'the docs suck' view; this seems like an important
point that doesn't seem to have had an answer.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: JIRA Smackdown
Posted by Wendy Smoak <ws...@gmail.com>.
On 6/14/07, Jason van Zyl <ja...@maven.org> wrote:
> I created a "Documentation" version so that
> technical issues wouldn't be polluted by documentation issues.
Documentation is neither a version nor pollution. :)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org