Re: Launchpad bug workflow change
Am 20.06.2007 um 00:06 schrieb Scott Kitterman: On Tuesday 19 June 2007 17:59, Henrik Nilsen Omma wrote: If you are not a developer then it is misleading to set it to In Progress because nobody is actually working on the fix and it may never be fixed. Um, non-developers work on fixes all the time. ... which ist the original intention of open source, to add my $ 0.02. Allow participation for average people, this encourages a lot. Even with snippets as small as changing a flag in the reporting system. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
Am 20.06.2007 um 00:56 schrieb Jordan Mantha: there *has* to be a workflow that allows for non-developers to work on bugs. Anything less would severely affect Universe and probably Main as well. For a counter-example, have a look at Apple's Darwin / OpenDarwin. What started with (very limited) source code write access had an enthusiastic community. After a few month write access vanished, later the bug database access vanished, today there are only relicts from the past. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Wed, 2007-06-20 at 16:36 -0400, Scott Kitterman wrote: In order to join ubuntu-qa you have to show experience with bug triaging. So once again, this is a new barrier to entry for people that want to fix bugs. Bug triaging and bug fixing are two different things. What you propose is like a layer violation in protocol design. I'd like to agree with Scott and don't let it look like he is alone with his view. I'm an ubuntu *user* and there have been some small bugs that were -- well -- bugging me. I don't have the overview about how the ubuntu community is organized in detail. Sometimes, I find small bugs which I can fix by myself. This has already happened several times in the past. Having to register for a ubuntu-qa group first would definitely discourage me from using LP because my time is quite limited and I only want a certain bug fixed ASAP without having to be a member of a special group. Actually, the problem is not *being* a member of a group but *becoming* it. Such a user has to find out how things are organized and where he needs to apply first, which he just might not be interested in in the first place. Especially, I don't think that ubunqu-qa would be the right group anyway. I'm not interested in triaging bugs. I just don't have the expertise for this. Remember, I just want to fix a bug here and there which is a personal thing and not related to how important a fix actually is for the average user or the community. IMO it's a solution in search of a problem. I have yet to see anyone set a bug to in progress that wasn't actually working on it. If this is the case, I don't see a need to change that, too. If you want to fix something, you need a problem first. If the fix also imposes additional work (group management) it might be counterproductive. I'm sure I wasn't saying anything that wasn't already said here. However, I felt like having to confirm what Scott was writing about from a occasional patch writer perspective. Cheers, Christof Krüger -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Wed, 20 Jun 2007 12:13:57 +0200 Henrik Nilsen Omma [EMAIL PROTECTED] wrote: Hi all, Instead of answering each point made by each person I will try to explain the reasoning behind this change in a more structured way. Thank you for trying again. I don't think lack of understanding on this end is the problem. The reality is that the development team is flooded with open bugs ATM and we need to take steps to improve this situation. We have over 30 000 open bugs presently and only 88 members of ubuntu-dev. Not all these bugs will ever be fixed by ubuntu-dev; some will be fixed upstream, by other distros, by other volunteer developers; some are duplicates and some will be rejected. But the fact is that as it stands today ubuntu-dev potentially has to consider all those 30 000 bugs because there could be serious problems hiding there. Agreed, but making life harder for people who have not yet qualified to upload directly does not advance this goal. snip. * Structure the division of work better to reduce duplication of effort The bug triage process must be improved at all levels, not just in the bugsquad and ubuntu-qa but also within the development teams. We should also encourage more people to join ubuntu-dev as this group performs both important development and triage work. Once again I agree on the goal, but not that your change (the additional restrctions) further that goal. So far I think most will agree. It seems that the controversy centers around the restricted use of In Progress, Fix Committed and Fix Released. There is also a feeling that Todo and Triaged are superfluous. I can see the point in the new states. At worst they just won't get used much. The potential for harm comes with the additional restrctions. As an aside, why was the most controversial aspect of these changes not mentioned in your message to devel-announce? I will try to address these. The Triaged and Todo states and their new restricted nature is important to improving our workflow. Other restrictions are useful for other reasons, but also have disadvantages and the answer may be to reduce the restrictions on some of those. snip * Todo -- A developer now mainly has to look at the trusted Triaged pile of bugs and will decide to move some onto the active ToDo list. The ToDo state seems to be another duplicate of the old 'Confirmed' that only developers can set. Again, therein lies its importance. This allows developers to control their own todo list, which is something they were previously struggling to do. Large packages like ubiquity, openoffice and firefox have over 500 open bugs that must be sorted not only relative to their intrinsic importance but also when they will be worked on. The relation between the Triaged and Todo states also provides a mechanism for developers to feed back information to ubuntu-qa about how bugs should be handled for that particular package. This rationale continues to avoid the very important use case of people working on bug fixes that are not yet official developers. * WontFix -- This new value has been restricted to ubuntu-qa and developers. Since only otherwise valid bugs should be marked as WontFix it is important that this be done by a person who in some way represents the project because it is expression of the features we care about and the reasons for rejecting a bug may not be clear to the submitter. Makes sense (and qa is easy enough to get into). * In Progress, Fix Committed, Fix Released -- these are states related to the development (bug fixing) process. They would normally follow after the Todo state but there are clearly exceptions to this, esp. relating to upstream bugs. These settings have been restricted to developers but I personally have no problem with opening these up to ubuntu-qa or/and the bugsquad. This is the real problem in my view and runs counter to what will be helpful in getting new volunteer developers. Most new developer volunteers do not start with triaging. They start with a particular bug they want to fix. Even your revised proposal raises new barriers to entry. I expect you'll argue the barrier is small, but why raise even small barriers? In my view, if a bug triager is cable to determine correctly when a bug should be WontFix and can confirm that a bug fix from bupstream has been applied in Ubuntu and is now working, etc. they qualify for ubuntu-qa and should be admitted there. I believe we should be growing ubuntu-qa faster tan we are ATM. As a project we may decide that this in not the correct way to handle it and may coose instead to give more powers to the bugsquad. All of which is about triaging, not fixing. In the development teams we have formal processes of review and sponsorship. Submitted work is looked at by more experienced people. Yes and this change does not suite that process well. This ensures the quality of what is committed remains high and helps
Re: Launchpad bug workflow change
On 20 Jun 2007, at 13:26, Henrik Nilsen Omma wrote: Scott Kitterman wrote: So far I think most will agree. It seems that the controversy centers around the restricted use of In Progress, Fix Committed and Fix Released. There is also a feeling that Todo and Triaged are superfluous. I can see the point in the new states. At worst they just won't get used much. The potential for harm comes with the additional restrctions. As an aside, why was the most controversial aspect of these changes not mentioned in your message to devel-announce? The simple answer is that the communication between the Launchpad team and Ubuntu team failed in this instance. I got a brief ping on IRC yesterday and felt I should post a notice about it. I wrote that based on some notes, from my memory and some IRC questions. I had assumed that the new states and renaming would be the controversial part and did not recall the restrictions item until someone asked a question that reminded me. My mistake. It turns out now, after having had more talks with the Launchpad team that *restrictions will not be placed on In Progress, Fix Committed or Fix Released* at this point. More work is needed to make that possible, so it will not be included in this round. Doing that is still part of the plan but this debate will obviously make us look at that again. I've asked the Launchpad developer working on this to post a summary of the changes being made now so we get it directly from the source. I've already contradicted myself so many times that I should probably stop :) I'm a Launchpad developer responsible for these changes, so I'll try and clear up confusion over the 'technical' parts of the bug workflow changes. Henrik has already gone through the motivations and reasoning, and Matthew Revell is putting together some documentation and help pages, so I'll try not to cover that stuff. As Henrik has said, we have not implemented anything from the bug- workflow blueprint relating to developer statuses... yet. They are still planned, but we held off for many of the same reasons that have come up on this thread: we're not yet completely happy with the design either. Here's a full rundown of what's going into the next Launchpad release for bug workflow: 3 statuses have been renamed: * Unconfirmed - New * Needs Info - Incomplete * Rejected - Invalid and 2 more have been added: * Triaged * Won't Fix The 2 additions are restricted. Only bug contacts or project owners can change a bug to Triaged or Won't Fix. We have not removed any statuses, and all but those 2 additions remain unrestricted. You could actually ignore Triaged and Won't Fix and continue to use Launchpad exactly as before, but we obviously want people to start using them. Certainly in larger projects I think they'll have a lot of value, but I'm keen to see how the new statuses are used for real, and what changes that'll have on our plans. Gavin. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
Henrik Nilsen Omma wrote: It turns out now, after having had more talks with the Launchpad team that *restrictions will not be placed on In Progress, Fix Committed or Fix Released* at this point. More work is needed to make that possible, so it will not be included in this round. Doing that is still part of the plan but this debate will obviously make us look at that again. I don't want to see such changes now or in the future. As an unofficial developer (and there are many of us), I _have_ to have access to the In Progress and Todo states. Realize that before one can become an Ubuntu Developer, one must first demonstrate a history of consistently good development work. This is impossible to do if we are unable to use launchpad to do our development work, thus it significantly impedes our ability to ever _become_ Ubuntu Developers. In my case, it may be moot, as I'm currently ubuntu-qa (dunno if it's planned for QA to set Needs Info or Todo, though), but in general it's a problem. I _might_ not be opposed to the restriction, if we added a new, fairly open but still moderated group, to include MOTU Acolytes, capable of setting these states, just to prevent *total* non-developers from setting to/away from them. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Wednesday 20 June 2007 13:34, Micah Cowan wrote: I _might_ not be opposed to the restriction, if we added a new, fairly open but still moderated group, to include MOTU Acolytes, capable of setting these states, just to prevent *total* non-developers from setting to/away from them. That would be better, but still imposes an administrative burden both on unofficial developers and on whoever would have to administer the team. Ironically, virtually all of the bugmail I get dumped on me because a team was incorrectly assigned the bug is because of ubuntu-qa. Personally, I have yet to see in progress misused. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Wednesday 20 June 2007 13:41:13 Scott Kitterman wrote: On Wednesday 20 June 2007 13:34, Micah Cowan wrote: I _might_ not be opposed to the restriction, if we added a new, fairly open but still moderated group, to include MOTU Acolytes, capable of setting these states, just to prevent *total* non-developers from setting to/away from them. That would be better, but still imposes an administrative burden both on unofficial developers and on whoever would have to administer the team. Ironically, virtually all of the bugmail I get dumped on me because a team was incorrectly assigned the bug is because of ubuntu-qa. Personally, I have yet to see in progress misused. Scott K From the converstation, membership in ubuntu-qa grants you access to these items as well correct? Simply join ubuntu-qa and that should solve the problem if I'm correct. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Wednesday 20 June 2007 16:27, Jonathan Jesse wrote: From the converstation, membership in ubuntu-qa grants you access to these items as well correct? Simply join ubuntu-qa and that should solve the problem if I'm correct. In order to join ubuntu-qa you have to show experience with bug triaging. So once again, this is a new barrier to entry for people that want to fix bugs. Bug triaging and bug fixing are two different things. What you propose is like a layer violation in protocol design. I'm glad these changes aren't being imposed immediately, but I don't that they are worth any (even small) discouraging of new volunteers to implement. BTW, driving people who have no interest in triaging to join so they can set status on bugs they are fixing also imposes additional workload on bdmurray (the approver for ubuntu-qa) for no real benifit to him. IMO it's a solution in search of a problem. I have yet to see anyone set a bug to in progress that wasn't actually working on it. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
(``-_-´´) -- Fernando wrote the following on 19.06.2007 18:50 I'm sorry, but I like the old status name better!! Cant we keep them or at least have a poll about it? * Unconfirmed - New * Needs Info - Incomplete * Rejected - Invalid Just because you get used to it doesn´t make them better. ymmv -- Thilo key: 0x4A411E09 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
Henrik Nilsen Omma wrote: * Triaged will mean that a bug has all the information attached to it that a developer needs to fix it. The 'confirmed' state was previously used for this purpose, but many users were 'confirming' bugs when observed by a second person. I disagree with this term. If something has been Triaged, that means it has been evaluated for urgency and had resources assigned appropriately. That doesn't seem to map well to the definition used here of all the information that is needed has been attached. It should simply mean that it has been assigned the appropriate priority and to the appropriate team. * Todo will form the list of bugs that developers expect to work on in the near future. These would typically also be assigned to a developer or a dev team. I see no real difference between this and the proposed use of Triaged. If a bug is confirmed to exist and has had all required information attached to it so that a developer can now fix it, why wouldn't a developer expect to work on it in the near future? -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
Phillip Susi wrote: Henrik Nilsen Omma wrote: * Triaged will mean that a bug has all the information attached to it that a developer needs to fix it. The 'confirmed' state was previously used for this purpose, but many users were 'confirming' bugs when observed by a second person. I disagree with this term. If something has been Triaged, that means it has been evaluated for urgency and had resources assigned appropriately. I agree that 'evaluating the urgency' should also fit into the Triaged state. However, not that this can only be done by ubuntu-qa or developers (setting importance). Assigning resources can really only be done by the people who intend to fix it, which is an even smaller group. The point of having the Triaged step is that the people fixing bugs should not have to look at all 30 000 open bugs. They only look at Triaged and from that group they reject some, push some back to Incomplete and add some to their Todo list. That should make the overall workflow more precise and efficient. We can discuss how well the word 'Triaged' fit that category, but IMO we do need that category. * Todo will form the list of bugs that developers expect to work on in the near future. These would typically also be assigned to a developer or a dev team. I see no real difference between this and the proposed use of Triaged. If a bug is confirmed to exist and has had all required information attached to it so that a developer can now fix it, why wouldn't a developer expect to work on it in the near future? Because we don't have the resources to fix all the bugs that are filed in Ubuntu within the the project. We may file them upstream and leave them Triaged or mark it In Progress if work is ongoing upstream. A developer may also look at a Triaged bug and decide it is a WontFix because it's not appropriate for Ubuntu or we don't have the resources to fix it. Henrik -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Tue, 19 Jun 2007 18:43:33 +0200 Henrik Nilsen Omma [EMAIL PROTECTED] wrote: * Rejected has been split into Invalid and Won't Fix, where the latter may be a valid bug or wish-list change that we don't have the wish or resources to fix. Will 'Won't Fix' bugs show up in default search results? I think it would be good for them to show up to minimize duplicate submissions of things that aren't going to get done. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
Scott Kitterman wrote: Will 'Won't Fix' bugs show up in default search results? I think it would be good for them to show up to minimize duplicate submissions of things that aren't going to get done. It's a closed state so I expect they won't (we'll find out tomorrow). It would be more useful if they show up in the duplicate suggestions shown to the submitter. People who triage and actively look for duplicates can turn the Wont Fix flag on in advanced search. Henrik -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Tue Jun 19, 2007 at 11:00:50PM +0200, Henrik Nilsen Omma wrote: Scott Kitterman wrote: Will 'Won't Fix' bugs show up in default search results? I think it would be good for them to show up to minimize duplicate submissions of things that aren't going to get done. It's a closed state so I expect they won't (we'll find out tomorrow). It would be more useful if they show up in the duplicate suggestions shown to the submitter. People who triage and actively look for duplicates can turn the Wont Fix flag on in advanced search. I believe closed bugs are show in the search results on the +filebug form so I think they should show up there. -Jordan -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On 20/06/07 04:56, Henrik Nilsen Omma wrote: What I did not mention in my first mail (just confirmed this with the LP developer), is that the groups who can set the different states will now also change. [..deleted..] A developer can: * Move the bug from Triaged to ToDo or push it back to a previous category. So, I'm a member of the general community. I have taken ownership of a bug, I'm working on it, and I cannot set it to ToDo, Triaged or In Progress? How do I manage the bugs I'm working on, and more importantly, how do I tell everyone else that I'm working on them? -- Onno Benschop Connected via Optus B3 at S31°54'06 - E115°50'39 (Yokine, WA) -- ()/)/)()..ASCII for Onno.. |?..EBCDIC for Onno.. --- -. -. --- ..Morse for Onno.. Proudly supported by Skipper Trucks, Highway1, Concept AV, Sony Central, Dalcon ITmaze - ABN: 56 178 057 063 - ph: 04 1219 - [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Tuesday 19 June 2007 17:59, Henrik Nilsen Omma wrote: If you are not a developer then it is misleading to set it to In Progress because nobody is actually working on the fix and it may never be fixed. Um, non-developers work on fixes all the time. I did a bunch of them before I was a developer and I sponsor other people's work now that I am one. This just isn't correct. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
Henrik Nilsen Omma wrote: If you are not a developer then it is misleading to set it to In Progress because nobody is actually working on the fix and it may never be fixed. There are those of us who are not developers but do still work on fixing bugs ;) Non developers should be able to set these states if the bug is assigned to them. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On 20/06/07 05:59, Henrik Nilsen Omma wrote: Onno Benschop wrote: On 20/06/07 04:56, Henrik Nilsen Omma wrote: What I did not mention in my first mail (just confirmed this with the LP developer), is that the groups who can set the different states will now also change. [..deleted..] A developer can: * Move the bug from Triaged to ToDo or push it back to a previous category. So, I'm a member of the general community. I have taken ownership of a bug, I'm working on it, and I cannot set it to ToDo, Triaged or In Progress? When you say 'a member of the general community' do you mean not in ubuntu-qa and not a developer (I ask because people from the volunteer community are also in those groups)? If you are not then it it's correct that you cannot set those states. This change gives more structure to the bug flow in that it will be more clear what is meant by a given state. Yes. I'm not a member of any groups. So, I think you're saying I should become a member of those groups :) How do I manage the bugs I'm working on, and more importantly, how do I tell everyone else that I'm working on them? If you are trying to reproduce it or asking for more information from the submitter then this will be clear from the comments and you can set it to Incomplete. If you are not a developer then it is misleading to set it to In Progress because nobody is actually working on the fix and it may never be fixed. Well, no I'm not a developer, err, I am, but not in the Ubuntu context. If I'm working on a bug in say dosfstools, or gphpedit, then there is no need for another developer to spend time duplicating my work. To be accurate, I've not released any actual fixes (yet), so I've not had a problem where I needed to submit a fix. So to say that nobody is working on the fix, sort of makes me a nobody :-) Perhaps a better question for me to ask is: Do I need to become a member of any specific groups to fix bugs in Ubuntu? -- Onno Benschop Connected via Optus B3 at S31°54'06 - E115°50'39 (Yokine, WA) -- ()/)/)()..ASCII for Onno.. |?..EBCDIC for Onno.. --- -. -. --- ..Morse for Onno.. Proudly supported by Skipper Trucks, Highway1, Concept AV, Sony Central, Dalcon ITmaze - ABN: 56 178 057 063 - ph: 04 1219 - [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
Phillip Susi wrote: Henrik Nilsen Omma wrote: If you are not a developer then it is misleading to set it to In Progress because nobody is actually working on the fix and it may never be fixed. There are those of us who are not developers but do still work on fixing bugs ;) Non developers should be able to set these states if the bug is assigned to them. I don't think you should assign a bug to yourself if you are not working on fixing it. IMO you should try to move it along to the Triaged state as efficiently as possible and bugs should be assigned to the developer or dev team who is going to fix it. I realise that this thinking does not match current triaging policy but IMO that policy should be changed. Too many bugs are being held up in half-triaged states. Important bugs are sometimes not getting the attention they should while less important ones are cluttering up the field. FWIW, I'm not a developer myself, I'm simply looking at ways of making the triage process more structured and efficient. Henrik -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Tuesday 19 June 2007 18:09, Cody Somerville wrote: Top posting fixed. On 6/19/07, Scott Kitterman [EMAIL PROTECTED] wrote: On Tuesday 19 June 2007 17:59, Henrik Nilsen Omma wrote: If you are not a developer then it is misleading to set it to In Progress because nobody is actually working on the fix and it may never be fixed. Um, non-developers work on fixes all the time. I did a bunch of them before I was a developer and I sponsor other people's work now that I am one. This just isn't correct. Scott K I suppose the question is: What is the definition of a developer? Generally in Ubuntu/LP terms that means someone who is a member of the Ubuntu Development Team in LP (https://launchpad.net/~ubuntu-dev). Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
Being a member of that group is a certification of your work as a developer in Ubuntu. There are many Ubuntu developers who are not in that group OR are in other groups on launchpad. I think the definition of developer should be strongly examined before being implement in this context. On 6/19/07, Scott Kitterman [EMAIL PROTECTED] wrote: On Tuesday 19 June 2007 18:09, Cody Somerville wrote: Top posting fixed. On 6/19/07, Scott Kitterman [EMAIL PROTECTED] wrote: On Tuesday 19 June 2007 17:59, Henrik Nilsen Omma wrote: If you are not a developer then it is misleading to set it to In Progress because nobody is actually working on the fix and it may never be fixed. Um, non-developers work on fixes all the time. I did a bunch of them before I was a developer and I sponsor other people's work now that I am one. This just isn't correct. Scott K I suppose the question is: What is the definition of a developer? Generally in Ubuntu/LP terms that means someone who is a member of the Ubuntu Development Team in LP (https://launchpad.net/~ubuntu-dev). Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Firefox (www.getfirefox.com) -- A browser you can trust -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
Scott Kitterman wrote: On Tuesday 19 June 2007 17:59, Henrik Nilsen Omma wrote: If you are not a developer then it is misleading to set it to In Progress because nobody is actually working on the fix and it may never be fixed. Um, non-developers work on fixes all the time. I did a bunch of them before I was a developer and I sponsor other people's work now that I am one. This just isn't correct. OK, so I should have said 'Ubuntu developer' (member of core dev or MOTU) instead of 'developer'. Lots of fixes are being worked on by upstreams or other non-Ubuntu developers all the time, but we don't mark a bug as In Progress unless someone is working on a fix in Ubuntu, or at least in a remote bugtracker to which we have set an upstream task. We would encourage anyone who is a developer to join MOTU and later core-dev so you can upload fixes directly. If you submit useful patches you would also very easily qualify for ubuntu-qa. Henrik -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
Onno Benschop wrote: When you say 'a member of the general community' do you mean not in ubuntu-qa and not a developer (I ask because people from the volunteer community are also in those groups)? If you are not then it it's correct that you cannot set those states. This change gives more structure to the bug flow in that it will be more clear what is meant by a given state. Yes. I'm not a member of any groups. So, I think you're saying I should become a member of those groups :) Yes, please do! If you are trying to reproduce it or asking for more information from the submitter then this will be clear from the comments and you can set it to Incomplete. If you are not a developer then it is misleading to set it to In Progress because nobody is actually working on the fix and it may never be fixed. Well, no I'm not a developer, err, I am, but not in the Ubuntu context. If I'm working on a bug in say dosfstools, or gphpedit, then there is no need for another developer to spend time duplicating my work. To be accurate, I've not released any actual fixes (yet), so I've not had a problem where I needed to submit a fix. So to say that nobody is working on the fix, sort of makes me a nobody :-) Please don't interpret it that way :) As I replied to Scott, if the bug is not handled by someone who can upload to Ubuntu then it's fair to say that nobody is working on a fix in Ubuntu. Do I need to become a member of any specific groups to fix bugs in Ubuntu? To do it independently, yes. I we encourage you to! Henrik -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
Scott Kitterman wrote: I don't think you should assign a bug to yourself if you are not working on fixing it. IMO you should try to move it along to the Triaged state as efficiently as possible and bugs should be assigned to the developer or dev team who is going to fix it. I realise that this thinking does not match current triaging policy but IMO that policy should be changed. Too many bugs are being held up in half-triaged states. Important bugs are sometimes not getting the attention they should while less important ones are cluttering up the field. So is this imposing policy change through system updates without discussing it with those affected or were there people involved in the triaging process that were consulted? First, you are mixing up two things. The technical change made to launchpad has been discussed for a while, including at UDS in Sevilla where community members participated and the phone lines to the world were open. Second, we are not imposing 'this' policy (that triagers should not assign themselves) at all. I just gave you my personal opinion. I know that many disagree with me on that and that I will have to make my case here in much more detail before in can get any more traction. FWIW, I'm not a developer myself, I'm simply looking at ways of making the triage process more structured and efficient. Currently in LP assigned means this is the person who is expected to take the next step on the bug (for example when I set a bug to needs info, I generally assign it to the reporter to make this clear). That's what you take it to mean and that's what the wiki suggests. I happen to think it's not the best way to do it. Traditionally in open source projects a bug has been assigned to the person intending to fix it. I'm not sure how taking away triaging tools aligns with your stated goal? I think I have helped create more triage tools than I have taken away ;) Henrik -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Wed Jun 20, 2007 at 12:41:36AM +0200, Henrik Nilsen Omma wrote: Onno Benschop wrote: snip If you are trying to reproduce it or asking for more information from the submitter then this will be clear from the comments and you can set it to Incomplete. If you are not a developer then it is misleading to set it to In Progress because nobody is actually working on the fix and it may never be fixed. Well, no I'm not a developer, err, I am, but not in the Ubuntu context. If I'm working on a bug in say dosfstools, or gphpedit, then there is no need for another developer to spend time duplicating my work. To be accurate, I've not released any actual fixes (yet), so I've not had a problem where I needed to submit a fix. So to say that nobody is working on the fix, sort of makes me a nobody :-) Please don't interpret it that way :) As I replied to Scott, if the bug is not handled by someone who can upload to Ubuntu then it's fair to say that nobody is working on a fix in Ubuntu. This is just not true. In Universe we have a great number of people working on bugs that are not able to upload. These people use status, subscriptions, and assignments to get their work sponsored. Even in Main there are quite a number of people who aren't in ubuntu-dev that work on bugs. Your statement is only true in the sense that a developer must touch it at some point to upload the fix, but the work is often enough not done by the developer. Bottom line, people who are assigned to a bug need to be able to modify it. If you want to control who can be assign bugs then that's a slightly different matter, but there *has* to be a workflow that allows for non-developers to work on bugs. Anything less would severely affect Universe and probably Main as well. -Jordan -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Tuesday 19 June 2007 18:36, Henrik Nilsen Omma wrote: Scott Kitterman wrote: On Tuesday 19 June 2007 17:59, Henrik Nilsen Omma wrote: If you are not a developer then it is misleading to set it to In Progress because nobody is actually working on the fix and it may never be fixed. Um, non-developers work on fixes all the time. I did a bunch of them before I was a developer and I sponsor other people's work now that I am one. This just isn't correct. OK, so I should have said 'Ubuntu developer' (member of core dev or MOTU) instead of 'developer'. Lots of fixes are being worked on by upstreams or other non-Ubuntu developers all the time, but we don't mark a bug as In Progress unless someone is working on a fix in Ubuntu, or at least in a remote bugtracker to which we have set an upstream task. We would encourage anyone who is a developer to join MOTU and later core-dev so you can upload fixes directly. If you submit useful patches you would also very easily qualify for ubuntu-qa. Yes and I was in -qa before I was a 'developer', but that's not the point. There are people who aren't in any team who get their work sponsored by people who are. You've now changed the system to make it harder for those people to assign themselves bugs they are working on. By extension, you've added work for those of us who will be asked to do it for them. Not progress in my book. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
Jordan Mantha wrote: Please don't interpret it that way :) As I replied to Scott, if the bug is not handled by someone who can upload to Ubuntu then it's fair to say that nobody is working on a fix in Ubuntu. This is just not true. In Universe we have a great number of people working on bugs that are not able to upload. These people use status, subscriptions, and assignments to get their work sponsored. Even in Main there are quite a number of people who aren't in ubuntu-dev that work on bugs. Your statement is only true in the sense that a developer must touch it at some point to upload the fix, but the work is often enough not done by the developer. Right, and that's the only sense in which I intended it (though I can see I have been too terse). We are trying to make a 1-dimesional setting field fit a range of situations here. A bug tracker that is used by many projects of different sizes will never fit everyone perfectly, but that common bug tracker also has its advantages. If we want a certain group of people who write code but are not MOTU or core-dev to be able to set the whole range of status settings then we can set up a team that gives that access. I agree that people can write valuable code without doing .deb packaging for example. Bottom line, people who are assigned to a bug need to be able to modify it. If you want to control who can be assign bugs then that's a slightly different matter, but there *has* to be a workflow that allows for non-developers to work on bugs. Anything less would severely affect Universe and probably Main as well. We have not made any changes to bug assignment (though I have my own opinions about that). I agree that we should encourage more people to work on bug fixes. If this change makes that more difficult then we need to find solutions to that. Henrik -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
Scott Kitterman wrote: OK. I guess I missed the meeting. Where is this change documented? Was there a spec? Anything those of us who were unable to participate in UDS could have seen this coming? The discussion was scheduled on a public webpage, but the Launchpad spec was not public (and thus I have opened a much larger discussion ...). I'm CCing the launchpad community contact who might want to comments on this. Restrictions imposed by the technical change are defacto policy. If you change the system, you've changed policy. That is true, but I'd like you to recognise that the policy that you suggested above had been imposed (that bugs should not be assigned to triagers) is in no way related to this technical change. It is only my personal opinion and I've stated that twice. I'm not sure how taking away triaging tools aligns with your stated goal? I think I have helped create more triage tools than I have taken away ;) I have no idea. I think here you are taking them away for no good reason that I have seen. What has beene taken away? The ability for anyone with an email address to set bugs to In progress and similar. We have also added 3 new bug states which I think will be very useful. Henrik -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
On Tuesday 19 June 2007 19:28, Henrik Nilsen Omma wrote: Scott Kitterman wrote: OK. I guess I missed the meeting. Where is this change documented? Was there a spec? Anything those of us who were unable to participate in UDS could have seen this coming? The discussion was scheduled on a public webpage, but the Launchpad spec was not public (and thus I have opened a much larger discussion ...). I'm CCing the launchpad community contact who might want to comments on this. Restrictions imposed by the technical change are defacto policy. If you change the system, you've changed policy. That is true, but I'd like you to recognise that the policy that you suggested above had been imposed (that bugs should not be assigned to triagers) is in no way related to this technical change. It is only my personal opinion and I've stated that twice. I understand that now. Thanks for the clarification. I'm not sure how taking away triaging tools aligns with your stated goal? I think I have helped create more triage tools than I have taken away ;) I have no idea. I think here you are taking them away for no good reason that I have seen. What has beene taken away? The ability for anyone with an email address to set bugs to In progress and similar. We have also added 3 new bug states which I think will be very useful. Yes. So now anyone who is not in -dev or -qa that wants to work on a bug will need to bother someone else to set the status or not set it and risk duplication of effort (or give up on the bureaucracy and go home). Is there evidence that this solves an actual problem? Sott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
Scott Kitterman wrote: I have no idea. I think here you are taking them away for no good reason that I have seen. What has beene taken away? The ability for anyone with an email address to set bugs to In progress and similar. We have also added 3 new bug states which I think will be very useful. Yes. So now anyone who is not in -dev or -qa that wants to work on a bug will need to bother someone else to set the status or not set it and risk duplication of effort (or give up on the bureaucracy and go home). Is there evidence that this solves an actual problem? There are currently a range of related problems as I see it: * People are setting a bug to confirmed when they also see it (a 'me too') while we at the same time use this state to imply that a bug report has all the required information. * Bugs are staying in the Unconfirmed or Need Info states too long. Sometimes important bugs to not reach the developer radar for this reason and stable releases are put out with bad breakage. I think more structure can help clear the Unconfirmed swamp. * Several people look at the same bug independently without that being recorded in a useful way, wasting effort. A more fine grained status system will let more people make at least some change to it, moving it forward. * Status settings mean different things to different teams and in different contexts. This makes starting to triage much more confusing. * We have no good mechanism (other than IRC and the bugsquad list) or policy for giving feedback to those doing triage and that is key to improving skills. Buglog is intended to help with that, but a state field that encourages feedback through the triage process may be more effective. I'm not claiming that tomorrow's change will fix all these complex problems but I'm hoping it will help. If we need to give wider permissions to more people then I'm sure we can do that, both for triaging and fixing, either through ubuntu-qa or other teams that we can set up. Even an open team with thousands of members might be better than just anyone with a launchpad account. The registration page for that team could refer to triaging guidelines. Launchpad does have a certain feature set, and that will gradually change with input from the user base (many projects, not just Ubuntu). But how the Ubuntu project decides to use those tools will be decided by us, through discussions like this and the CC and TB if needed. We can use the team structure or social mechanisms to give the access we want to various groups. Henrik -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug workflow change
Jordan Mantha wrote: If we want a certain group of people who write code but are not MOTU or core-dev to be able to set the whole range of status settings then we can set up a team that gives that access. I agree that people can write valuable code without doing .deb packaging for example. OK, but it wasn't so much the new status fields that has people concerned as changing who can set the status like: A developer can: * Move the bug from Triaged to ToDo or push it back to a previous category. Why should only a person in ubuntu-dev be able to use ToDo? Other people need to be able to set ToDo, In Progress, Fix Commited, and Fix Released. Yes I can see how that becomes a sensitive change, I also happen to think it's useful. I don't agree that someone working by themselves, outside of the ubuntu structures, should be able to set the state to In Progress (or the new ToDo) because that implies a promise to the submitter that a fix _in Ubuntu_ is in the works and that promise can really only be made by someone with upload rights. If you have to get a change sponsored you can also notify the potential sponsor ahead of time and ask for a state to be set. That way the responsible sponsor is aware of the work and duplication can be avoided. If I file an RFE for an unlikely change to Ubuntu and someone who can code and agrees with me might go ahead and start coding, setting the status to In Progress, but that change will not likely be accepted when it comes time to sponsor it. We have not made any changes to bug assignment (though I have my own opinions about that). No, but what is being changed is who can do what. And you previously stated that people shouldn't assign themselves to bugs they aren't going to fix. I think that is very true and perhaps a solution to the current problem is to allow the person who is assigned to a bug to change the status as neccessary because that is the person doing the actual work. OK, but that would only work if you also limit who can assign, otherwise you can just assign a random bug to yourself and mark it Fix Released (as you can do now). Under that model, if you ask to have it assigned to you, then you should be able to set any state up to Fix Committed. That should work. I agree that we should encourage more people to work on bug fixes. If this change makes that more difficult then we need to find solutions to that. Well, I think Scott's point is that if the people affected by such a change were consulted earlier on then maybe a better solution would have been found in the first place. A UDS BOF is no where near enough input on essential workflow/permission changes. I agree that this should have been handled better. I was only made aware of tomorrow's change this afternoon and I'm the head of Canonical's distro QA team :) We are a big project and messages do sometimes get lost. The fact that major decisions are taken at the UDSes where only a very few can attend has always been a problem. Those direct sessions are also very productive, so I'm not sure there is an easy answer. Perhaps this is all a lot of misunderstanding and a big deal over nothing, but sudden changes to one of the most important workflows we have maybe need more warning/discussion in the future. I agree. This should have been more transparent. Henrik -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
