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 <bruce.brou...@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 <remko.po...@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 <bruce.brou...@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-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > > > > > -- > > Bruce Brouwer
