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 (ver
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 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
>
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
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 preve
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
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 t
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
>>>
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.
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 t
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.
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nice change!
However, we've missed a case completely...I'm not sure how I didnt think
of it at UDS.
Henrik Nilsen Omma wrote:
> Phillip Susi wrote:
>> Henrik Nilsen Omma wrote:
>>> If you are not a developer then it is misleading to set it to In
>>>
On 6/20/07, Henrik Nilsen Omma <[EMAIL PROTECTED]> wrote:
> ...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
On 6/20/07, Henrik Nilsen Omma <[EMAIL PROTECTED]> wrote:
> >> 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.
The new bug states are likely helpful
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
On Tuesday 19 June 2007 20:01, Henrik Nilsen Omma wrote:
> 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 t
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 whic
On 6/20/07, Jordan Mantha <[EMAIL PROTECTED]> wrote:
> On Wed Jun 20, 2007 at 01:13:41AM +0200, Henrik Nilsen Omma 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
On 6/20/07, Henrik Nilsen Omma <[EMAIL PROTECTED]> wrote:
> Jordan Mantha wrote:
> > 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
On Wed Jun 20, 2007 at 01:13:41AM +0200, Henrik Nilsen Omma wrote:
> 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 fi
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 sched
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 publ
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 grea
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 f
On Wed Jun 20, 2007 at 12:41:36AM +0200, Henrik Nilsen Omma wrote:
> Onno Benschop wrote:
> >> 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 deve
On Tuesday 19 June 2007 18:57, Henrik Nilsen Omma wrote:
> 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
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 r
On 20/06/07 06:36, Henrik Nilsen Omma wrote:
> 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
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 state
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 t
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/1
On Tuesday 19 June 2007 18:24, Henrik Nilsen Omma wrote:
> 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 u
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 actu
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 ;)
>
> N
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
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 s
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 d
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
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
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 clo
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 u
Phillip Susi wrote:
> Henrik Nilsen Omma wrote:
>> 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
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 re
Henrik Nilsen Omma wrote:
> 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 eve
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.
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 ter
(``-_-´´) -- 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
I'm sorry, but I like the old status name better!!
Cant we keep them or at least have a poll about it?
On 6/19/07, Henrik Nilsen Omma <[EMAIL PROTECTED]> wrote:
> Tomorrow (2007-06-20) the Launchpad team will update the bug tracker
> with a new set of bug states to help projects like Ubuntu improv
Tomorrow (2007-06-20) the Launchpad team will update the bug tracker
with a new set of bug states to help projects like Ubuntu improve bug
management. The changes will allow for greater fine tuning of our bug
management and the new labels should hopefully also make more sense to
users.
The fol
49 matches
Mail list logo
