On 11/04/13 4:23 PM, "prasanna" <t...@apache.org> wrote:
>On 11 April 2013 15:52, Abhinandan Prateek ><abhinandan.prat...@citrix.com> wrote: >> >>>> >>>>I will start with an example: A critical bug (CLOUDSTACK-1941) that is >>>>blocking a release (4.1) is not picked up by any community member for 5 >>>>days ! >>>>The reason being that it is a UI issue but not that clear from the >>>>desc, >>>>the nature of the bug is known after someone spends time on it. >>>> >>>>Now is it wrong to ask the community members who have expertise on UI >>>>to >>>>fix it, in a bid to help Chip get the release out ? >>>> >>>>A set of guidelines are necessary so that this whole confusion about >>>>bugs >>>>getting assigned is cleared up. I will start by proposing some simple >>>>rules: >>>> >>>>1. Never assign bugs that are not critical or blocker unless they meet >>>>any >>>>of the below condition. >>> >>>Never would be too lenient. Maybe assign it after 7-8 days since they >>>don't need immediate attention. >> >> 7-8 days is a huge time lost. I was suggesting that this to be 3 days. >>Let >> other community members chime in too. >> > >Just to note: contributors will enter anytime. They don't necessarily >know of our release roadmap when they come in looking to contribute. >And typically they'd be looking at low hanging fruit - ie not blocker, >criticals. If you're saying 'x days are lost' then that doesn't make >much sense to an external contributor, x days based on what? If a bug >is blocking someone else's progress then the person who is blocked >should make noise on this list so the appropriate person can fix it. >I think the issue this thread is trying to address is assignment of >bugs in the background without community participation and/or >knowledge. There are two issues here a bug blocking someone and that he has the option of using mailing list to reach out, I am in absolute agreement here. The other is a bug is left with no taker, probably even after someone has shouted on the mailing list that someone take it up. This is where intelligent triaging say from the release manager will help. I guess the work as well as the end result are equally important if not one more. There are people who are out there waiting for a release, definitely we do not want to disappoint them. Also pleeezee do not distinguish between community members by trying to come up with a notion of external or internal contributor. All of us external members are equally passionate as internal members. All apache releases happen as per schedule I expect any new contributor joining the team to have access to the schedule. > >Also I don't think bugs are getting fixed immediately after assignment >as you indicate. Bugs go between Triager 1 to Triager 2 to Developer 3 >and then Developer 3 assigns it to the Developer 4 who fixes the bug. >Instead - Developer 4 should have got to it first or explained the >nature of the fix if he hasn't the time to fix it. Which doesn't >happen either. As Alex proposed, when someone takes up a bug they >should mark it in progress so that we know work is on going. Instead >if Triagers are just assigning bugs based on some kind of weird >LRU-cache in their head of who's (usually $dayjob stakeholder) the >rightful owner I find it exclusionary to community participation. We can limit the people who can triage the bugs to say release manager(s). When a bug goes from 1 person to another as in the example I quoted above it just shows that it is getting closer to resolution and not just lying there unclaimed. Again if we have a list of contributors and there area of interests we can come up with a heuristic to assign unclaimed bugs. Again I am saying we limit this ability to triage to release manager or his designated team. Please clarify what a $dayjob stakeholder is ? > >There is no contest on the bugs being assigned by the RM that are >essential to be fixed for a release. So I agree with you on that. Yes, I do agree, check above and that too governed by certain rules. >
