2.0 release triage

[Bruce Brouwer <br...@gmail.com>]

One of the things that I find difficult right now is knowing what needs the
most attention for the purpose of releasing 2.0. There are actually very
few issues in JIRA that are assigned to 2.0 or 2.0-rc2. There are a
daunting number of issues that are not assigned a fix version.

>From what I can see, much of the discussion on this mailing list is for
issues that are not assigned a fix version. I'm guessing that many of the
messages I am seeing could be delayed until after 2.0. How much of our
attention is being spent on addressing issues that aren't contributing to
releasing 2.0?

I am willing to help. One of my roles is a JIRA admin in my day job. If I
were given edit permission, I could take a stab at assigning unscheduled
issues to a proper release. If you gave me the appropriate project admin
permission, I could even create new versions (e.g. 2.1, ...). I could
always comment my reasoning if I pushed something off to 2.1.

What is the distinction between 2.0 and 2.0-rc2? Should 2.0 be the bucket
for everything that needs to be fixed before GA and we pull those issues
into -rcX as we have time?

I just would like the project to keep focused on release 2.0 and not being
distracted by stuff that should really wait for 2.1.

Is there any interest in having me (or someone else) do this?

-- 

Bruce Brouwer

Re: 2.0 release triage

[Ralph Goers <ra...@dslextreme.com>]

OK.  I am going through the issues and assigning those I intend to look at to me.  That doesn’t mean they are actively being worked on so if someone else wants to take ownership that is fine.   Marking the issue as “In Progress” makes sense once I actually start working on something.

Ralph

On Mar 1, 2014, at 10:21 AM, Matt Sicker <bo...@gmail.com> wrote:

> I'd like it if the committers would assign or mark as "in progress" anything they're working on or intend to work on in the short term. That way us contributors don't duplicate any efforts!
> 
> 
> On 28 February 2014 17:48, Ralph Goers <ra...@dslextreme.com> wrote:
> All I can tell you is what I do, although I suspect it is similar to what others do.
> 
> As I have time I go through the list of Jira issues and look for those that a) look interesting or b) fit with the parts of Log4j I typically work on.  I don’t usually bother assigning the issue to me because I will either have a solution in a few hours or determine that I don’t think what is being asked for is workable, at which point I will put a comment in the issue.  What is unfortunate is that I don’t want to change the status to “Won’t Fix” until the reporter has a chance to provide feedback and there really isn’t another status (at least that I am aware) to set the issue to.
> 
> That said, I probably should change my habits and go through the issues and assign the ones I am interested in to me.  In the end that would save me time as I wouldn’t have to search all the open issues for whatever I want to work on next.
> 
> If you want to work on an issue go ahead and add a comment that you are working on it.  Of course, that doesn’t mean much if it isn’t followed by a patch or requests for more info, etc.
> 
> FWIW, I fixed the one remaining issue I considered a blocker to 2.0 GA yesterday.  However, I do need to go through the JMX code as the last time I looked at it I saw several methods doing stuff I know won’t work.
> 
> Ralph
> 
> 
> On Feb 28, 2014, at 1:58 PM, Bruce Brouwer <br...@gmail.com> wrote:
> 
>> So, because I can't assign any JIRA to myself (I don't have permission), should I just add a comment that says I'm working on it? 
>> 
>> Should I add comments to issues that I think should wait until after 2.0? Or is that going too far in my newbie status?
>> 
>> I just find it hard to know where my effort will be best spent. There are currently only 12 issues that have a 2.0-like version assigned. That leaves a huge bucket of 107 issues and I'm left with very little idea on which of these to start with. Of this 107 issues with no fix version, 96 are unassigned. Where do I start such that I'm not wasting my time. I think it would be nice if someone closer to the project helped me out by identifying which issues they believed belonged in version 2.0 and which should wait until after 2.0, leaving them unassigned. 
>> 
>> Or would doing this cause problems because reporters might feel their issue isn't important enough to be worked on immediately?
>> 
>> I am just trying to find an easier way to know how to help with 2.0 and I'm hoping others on the project might benefit as well by delaying discussions and debate for issues that don't belong in 2.0. Or is my desire to focus on 2.0 slightly misguided and I'm just not thinking of this in the open source way? Please educate me (but briefly so you have more time to work on 2.0 ;)
>> 
>> 
>> 
>> On Thu, Feb 27, 2014 at 9:46 PM, Remko Popma <re...@gmail.com> wrote:
>> I like the idea of having a 2.1 version in Jira for items I intend to address after the 2.0 release. Items without version would (to me) mean either long-term items or items that I don't have the expertise for (or interest in, grin).
>> 
>> One thing I find different in an open source project from working on a company project is assigning and scheduling issues. In an OS project you can pretty much only assign to yourself and schedule the items that you are planning to address yourself. (But as it's voluntary work, and other things come up, I find that even planning my own time to spend on log4j is not reliable...)
>> 
>> So the Jira is all best effort IMHO.
>> 
>> What seems to work ok for me is just picking items I'm interested in from the list of open Jiras, and assign them to myself (basically letting the rest of the team know that I'm currently working on this to avoid double work that would waste other people's time). Then provide the fix (with unit tests to prove the fix works) within some reasonable time.
>> 
>> Remko
>> 
>> Sent from my iPhone
>> 
>> > On 2014/02/28, at 8:34, Bruce Brouwer <br...@gmail.com> wrote:
>> >
>> > One of the things that I find difficult right now is knowing what needs the most attention for the purpose of releasing 2.0. There are actually very few issues in JIRA that are assigned to 2.0 or 2.0-rc2. There are a daunting number of issues that are not assigned a fix version.
>> >
>> > From what I can see, much of the discussion on this mailing list is for issues that are not assigned a fix version. I'm guessing that many of the messages I am seeing could be delayed until after 2.0. How much of our attention is being spent on addressing issues that aren't contributing to releasing 2.0?
>> >
>> > I am willing to help. One of my roles is a JIRA admin in my day job. If I were given edit permission, I could take a stab at assigning unscheduled issues to a proper release. If you gave me the appropriate project admin permission, I could even create new versions (e.g. 2.1, ...). I could always comment my reasoning if I pushed something off to 2.1.
>> >
>> > What is the distinction between 2.0 and 2.0-rc2? Should 2.0 be the bucket for everything that needs to be fixed before GA and we pull those issues into -rcX as we have time?
>> >
>> > I just would like the project to keep focused on release 2.0 and not being distracted by stuff that should really wait for 2.1.
>> >
>> > Is there any interest in having me (or someone else) do this?
>> >
>> > --
>> >
>> > Bruce Brouwer
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> 
>> 
>> 
>> 
>> -- 
>> 
>> Bruce Brouwer
> 
> 
> 
> 
> -- 
> Matt Sicker <bo...@gmail.com>

Re: 2.0 release triage

[Matt Sicker <bo...@gmail.com>]

I'd like it if the committers would assign or mark as "in progress"
anything they're working on or intend to work on in the short term. That
way us contributors don't duplicate any efforts!


On 28 February 2014 17:48, Ralph Goers <ra...@dslextreme.com> wrote:

> All I can tell you is what I do, although I suspect it is similar to what
> others do.
>
> As I have time I go through the list of Jira issues and look for those
> that a) look interesting or b) fit with the parts of Log4j I typically work
> on.  I don’t usually bother assigning the issue to me because I will either
> have a solution in a few hours or determine that I don’t think what is
> being asked for is workable, at which point I will put a comment in the
> issue.  What is unfortunate is that I don’t want to change the status to
> “Won’t Fix” until the reporter has a chance to provide feedback and there
> really isn’t another status (at least that I am aware) to set the issue to.
>
> That said, I probably should change my habits and go through the issues
> and assign the ones I am interested in to me.  In the end that would save
> me time as I wouldn’t have to search all the open issues for whatever I
> want to work on next.
>
> If you want to work on an issue go ahead and add a comment that you are
> working on it.  Of course, that doesn’t mean much if it isn’t followed by a
> patch or requests for more info, etc.
>
> FWIW, I fixed the one remaining issue I considered a blocker to 2.0 GA
> yesterday.  However, I do need to go through the JMX code as the last time
> I looked at it I saw several methods doing stuff I know won’t work.
>
> Ralph
>
>
> On Feb 28, 2014, at 1:58 PM, Bruce Brouwer <br...@gmail.com>
> wrote:
>
> So, because I can't assign any JIRA to myself (I don't have permission),
> should I just add a comment that says I'm working on it?
>
> Should I add comments to issues that I think should wait until after 2.0?
> Or is that going too far in my newbie status?
>
> I just find it hard to know where my effort will be best spent. There are
> currently only 12 issues that have a 2.0-like version assigned. That leaves
> a huge bucket of 107 issues and I'm left with very little idea on which of
> these to start with. Of this 107 issues with no fix version, 96 are
> unassigned. Where do I start such that I'm not wasting my time. I think it
> would be nice if someone closer to the project helped me out by identifying
> which issues they believed belonged in version 2.0 and which should wait
> until after 2.0, leaving them unassigned.
>
> Or would doing this cause problems because reporters might feel their
> issue isn't important enough to be worked on immediately?
>
> I am just trying to find an easier way to know how to help with 2.0 and
> I'm hoping others on the project might benefit as well by delaying
> discussions and debate for issues that don't belong in 2.0. Or is my desire
> to focus on 2.0 slightly misguided and I'm just not thinking of this in the
> open source way? Please educate me (but briefly so you have more time to
> work on 2.0 ;)
>
>
>
> On Thu, Feb 27, 2014 at 9:46 PM, Remko Popma <re...@gmail.com>wrote:
>
>> I like the idea of having a 2.1 version in Jira for items I intend to
>> address after the 2.0 release. Items without version would (to me) mean
>> either long-term items or items that I don't have the expertise for (or
>> interest in, grin).
>>
>> One thing I find different in an open source project from working on a
>> company project is assigning and scheduling issues. In an OS project you
>> can pretty much only assign to yourself and schedule the items that you are
>> planning to address yourself. (But as it's voluntary work, and other things
>> come up, I find that even planning my own time to spend on log4j is not
>> reliable...)
>>
>> So the Jira is all best effort IMHO.
>>
>> What seems to work ok for me is just picking items I'm interested in from
>> the list of open Jiras, and assign them to myself (basically letting the
>> rest of the team know that I'm currently working on this to avoid double
>> work that would waste other people's time). Then provide the fix (with unit
>> tests to prove the fix works) within some reasonable time.
>>
>> Remko
>>
>> Sent from my iPhone
>>
>> > On 2014/02/28, at 8:34, Bruce Brouwer <br...@gmail.com> wrote:
>> >
>> > One of the things that I find difficult right now is knowing what needs
>> the most attention for the purpose of releasing 2.0. There are actually
>> very few issues in JIRA that are assigned to 2.0 or 2.0-rc2. There are a
>> daunting number of issues that are not assigned a fix version.
>> >
>> > From what I can see, much of the discussion on this mailing list is for
>> issues that are not assigned a fix version. I'm guessing that many of the
>> messages I am seeing could be delayed until after 2.0. How much of our
>> attention is being spent on addressing issues that aren't contributing to
>> releasing 2.0?
>> >
>> > I am willing to help. One of my roles is a JIRA admin in my day job. If
>> I were given edit permission, I could take a stab at assigning unscheduled
>> issues to a proper release. If you gave me the appropriate project admin
>> permission, I could even create new versions (e.g. 2.1, ...). I could
>> always comment my reasoning if I pushed something off to 2.1.
>> >
>> > What is the distinction between 2.0 and 2.0-rc2? Should 2.0 be the
>> bucket for everything that needs to be fixed before GA and we pull those
>> issues into -rcX as we have time?
>> >
>> > I just would like the project to keep focused on release 2.0 and not
>> being distracted by stuff that should really wait for 2.1.
>> >
>> > Is there any interest in having me (or someone else) do this?
>> >
>> > --
>> >
>> > Bruce Brouwer
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>
>
> --
>
> Bruce Brouwer
>
>
>


-- 
Matt Sicker <bo...@gmail.com>

Re: 2.0 release triage

[Ralph Goers <ra...@dslextreme.com>]

All I can tell you is what I do, although I suspect it is similar to what others do.

As I have time I go through the list of Jira issues and look for those that a) look interesting or b) fit with the parts of Log4j I typically work on.  I don’t usually bother assigning the issue to me because I will either have a solution in a few hours or determine that I don’t think what is being asked for is workable, at which point I will put a comment in the issue.  What is unfortunate is that I don’t want to change the status to “Won’t Fix” until the reporter has a chance to provide feedback and there really isn’t another status (at least that I am aware) to set the issue to.

That said, I probably should change my habits and go through the issues and assign the ones I am interested in to me.  In the end that would save me time as I wouldn’t have to search all the open issues for whatever I want to work on next.

If you want to work on an issue go ahead and add a comment that you are working on it.  Of course, that doesn’t mean much if it isn’t followed by a patch or requests for more info, etc.

FWIW, I fixed the one remaining issue I considered a blocker to 2.0 GA yesterday.  However, I do need to go through the JMX code as the last time I looked at it I saw several methods doing stuff I know won’t work.

Ralph


On Feb 28, 2014, at 1:58 PM, Bruce Brouwer <br...@gmail.com> wrote:

> So, because I can't assign any JIRA to myself (I don't have permission), should I just add a comment that says I'm working on it? 
> 
> Should I add comments to issues that I think should wait until after 2.0? Or is that going too far in my newbie status?
> 
> I just find it hard to know where my effort will be best spent. There are currently only 12 issues that have a 2.0-like version assigned. That leaves a huge bucket of 107 issues and I'm left with very little idea on which of these to start with. Of this 107 issues with no fix version, 96 are unassigned. Where do I start such that I'm not wasting my time. I think it would be nice if someone closer to the project helped me out by identifying which issues they believed belonged in version 2.0 and which should wait until after 2.0, leaving them unassigned. 
> 
> Or would doing this cause problems because reporters might feel their issue isn't important enough to be worked on immediately?
> 
> I am just trying to find an easier way to know how to help with 2.0 and I'm hoping others on the project might benefit as well by delaying discussions and debate for issues that don't belong in 2.0. Or is my desire to focus on 2.0 slightly misguided and I'm just not thinking of this in the open source way? Please educate me (but briefly so you have more time to work on 2.0 ;)
> 
> 
> 
> On Thu, Feb 27, 2014 at 9:46 PM, Remko Popma <re...@gmail.com> wrote:
> I like the idea of having a 2.1 version in Jira for items I intend to address after the 2.0 release. Items without version would (to me) mean either long-term items or items that I don't have the expertise for (or interest in, grin).
> 
> One thing I find different in an open source project from working on a company project is assigning and scheduling issues. In an OS project you can pretty much only assign to yourself and schedule the items that you are planning to address yourself. (But as it's voluntary work, and other things come up, I find that even planning my own time to spend on log4j is not reliable...)
> 
> So the Jira is all best effort IMHO.
> 
> What seems to work ok for me is just picking items I'm interested in from the list of open Jiras, and assign them to myself (basically letting the rest of the team know that I'm currently working on this to avoid double work that would waste other people's time). Then provide the fix (with unit tests to prove the fix works) within some reasonable time.
> 
> Remko
> 
> Sent from my iPhone
> 
> > On 2014/02/28, at 8:34, Bruce Brouwer <br...@gmail.com> wrote:
> >
> > One of the things that I find difficult right now is knowing what needs the most attention for the purpose of releasing 2.0. There are actually very few issues in JIRA that are assigned to 2.0 or 2.0-rc2. There are a daunting number of issues that are not assigned a fix version.
> >
> > From what I can see, much of the discussion on this mailing list is for issues that are not assigned a fix version. I'm guessing that many of the messages I am seeing could be delayed until after 2.0. How much of our attention is being spent on addressing issues that aren't contributing to releasing 2.0?
> >
> > I am willing to help. One of my roles is a JIRA admin in my day job. If I were given edit permission, I could take a stab at assigning unscheduled issues to a proper release. If you gave me the appropriate project admin permission, I could even create new versions (e.g. 2.1, ...). I could always comment my reasoning if I pushed something off to 2.1.
> >
> > What is the distinction between 2.0 and 2.0-rc2? Should 2.0 be the bucket for everything that needs to be fixed before GA and we pull those issues into -rcX as we have time?
> >
> > I just would like the project to keep focused on release 2.0 and not being distracted by stuff that should really wait for 2.1.
> >
> > Is there any interest in having me (or someone else) do this?
> >
> > --
> >
> > Bruce Brouwer
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> 
> 
> 
> 
> -- 
> 
> Bruce Brouwer

Re: 2.0 release triage

[Bruce Brouwer <br...@gmail.com>]

So, because I can't assign any JIRA to myself (I don't have permission),
should I just add a comment that says I'm working on it?

Should I add comments to issues that I think should wait until after 2.0?
Or is that going too far in my newbie status?

I just find it hard to know where my effort will be best spent. There are
currently only 12 issues that have a 2.0-like version assigned. That leaves
a huge bucket of 107 issues and I'm left with very little idea on which of
these to start with. Of this 107 issues with no fix version, 96 are
unassigned. Where do I start such that I'm not wasting my time. I think it
would be nice if someone closer to the project helped me out by identifying
which issues they believed belonged in version 2.0 and which should wait
until after 2.0, leaving them unassigned.

Or would doing this cause problems because reporters might feel their issue
isn't important enough to be worked on immediately?

I am just trying to find an easier way to know how to help with 2.0 and I'm
hoping others on the project might benefit as well by delaying discussions
and debate for issues that don't belong in 2.0. Or is my desire to focus on
2.0 slightly misguided and I'm just not thinking of this in the open source
way? Please educate me (but briefly so you have more time to work on 2.0 ;)



On Thu, Feb 27, 2014 at 9:46 PM, Remko Popma <re...@gmail.com> wrote:

> I like the idea of having a 2.1 version in Jira for items I intend to
> address after the 2.0 release. Items without version would (to me) mean
> either long-term items or items that I don't have the expertise for (or
> interest in, grin).
>
> One thing I find different in an open source project from working on a
> company project is assigning and scheduling issues. In an OS project you
> can pretty much only assign to yourself and schedule the items that you are
> planning to address yourself. (But as it's voluntary work, and other things
> come up, I find that even planning my own time to spend on log4j is not
> reliable...)
>
> So the Jira is all best effort IMHO.
>
> What seems to work ok for me is just picking items I'm interested in from
> the list of open Jiras, and assign them to myself (basically letting the
> rest of the team know that I'm currently working on this to avoid double
> work that would waste other people's time). Then provide the fix (with unit
> tests to prove the fix works) within some reasonable time.
>
> Remko
>
> Sent from my iPhone
>
> > On 2014/02/28, at 8:34, Bruce Brouwer <br...@gmail.com> wrote:
> >
> > One of the things that I find difficult right now is knowing what needs
> the most attention for the purpose of releasing 2.0. There are actually
> very few issues in JIRA that are assigned to 2.0 or 2.0-rc2. There are a
> daunting number of issues that are not assigned a fix version.
> >
> > From what I can see, much of the discussion on this mailing list is for
> issues that are not assigned a fix version. I'm guessing that many of the
> messages I am seeing could be delayed until after 2.0. How much of our
> attention is being spent on addressing issues that aren't contributing to
> releasing 2.0?
> >
> > I am willing to help. One of my roles is a JIRA admin in my day job. If
> I were given edit permission, I could take a stab at assigning unscheduled
> issues to a proper release. If you gave me the appropriate project admin
> permission, I could even create new versions (e.g. 2.1, ...). I could
> always comment my reasoning if I pushed something off to 2.1.
> >
> > What is the distinction between 2.0 and 2.0-rc2? Should 2.0 be the
> bucket for everything that needs to be fixed before GA and we pull those
> issues into -rcX as we have time?
> >
> > I just would like the project to keep focused on release 2.0 and not
> being distracted by stuff that should really wait for 2.1.
> >
> > Is there any interest in having me (or someone else) do this?
> >
> > --
> >
> > Bruce Brouwer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>


-- 

Bruce Brouwer

Re: 2.0 release triage

[Remko Popma <re...@gmail.com>]

I like the idea of having a 2.1 version in Jira for items I intend to address after the 2.0 release. Items without version would (to me) mean either long-term items or items that I don't have the expertise for (or interest in, grin).

One thing I find different in an open source project from working on a company project is assigning and scheduling issues. In an OS project you can pretty much only assign to yourself and schedule the items that you are planning to address yourself. (But as it's voluntary work, and other things come up, I find that even planning my own time to spend on log4j is not reliable...)

So the Jira is all best effort IMHO. 

What seems to work ok for me is just picking items I'm interested in from the list of open Jiras, and assign them to myself (basically letting the rest of the team know that I'm currently working on this to avoid double work that would waste other people's time). Then provide the fix (with unit tests to prove the fix works) within some reasonable time. 

Remko

Sent from my iPhone

> On 2014/02/28, at 8:34, Bruce Brouwer <br...@gmail.com> wrote:
> 
> One of the things that I find difficult right now is knowing what needs the most attention for the purpose of releasing 2.0. There are actually very few issues in JIRA that are assigned to 2.0 or 2.0-rc2. There are a daunting number of issues that are not assigned a fix version. 
> 
> From what I can see, much of the discussion on this mailing list is for issues that are not assigned a fix version. I'm guessing that many of the messages I am seeing could be delayed until after 2.0. How much of our attention is being spent on addressing issues that aren't contributing to releasing 2.0? 
> 
> I am willing to help. One of my roles is a JIRA admin in my day job. If I were given edit permission, I could take a stab at assigning unscheduled issues to a proper release. If you gave me the appropriate project admin permission, I could even create new versions (e.g. 2.1, ...). I could always comment my reasoning if I pushed something off to 2.1. 
> 
> What is the distinction between 2.0 and 2.0-rc2? Should 2.0 be the bucket for everything that needs to be fixed before GA and we pull those issues into -rcX as we have time? 
> 
> I just would like the project to keep focused on release 2.0 and not being distracted by stuff that should really wait for 2.1. 
> 
> Is there any interest in having me (or someone else) do this?
> 
> -- 
> 
> Bruce Brouwer

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org