FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Masters Of The Universe

 
 
LinkBack Thread Tools
 
Old 05-30-2008, 11:14 PM
Stefan Potyra
 
Default don't use bug tasks for transitions

Hi folks,

as overheard on #ubuntu-devel today, please don't use one bug with many
different tasks for transitions. The problem with this is, that any
subscriber of an affected package will get every mail for a change in that
bug (in short: [he/she'll get] "zillion mails" [in which he/she has] "no
interest in"[1]).

For what tasks are not meant to be used, I'll give you this quotation: "if the
fixes required would be independent, they should be separate bugs" [2]

Finally, one option to handle transitions via LP was also proposed: "it's
easier to file [separate] bugs and tag those" [3].

Cheers,
Stefan.
--
[1]: two quotes mixed up here from seb128 in #ubuntu-devel
[2]: cjwatson
[3]: seb128

(cf. <http://irclogs.ubuntu.com/2008/05/30/%23ubuntu-devel.html>).
--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-31-2008, 12:01 AM
Scott Kitterman
 
Default don't use bug tasks for transitions

On Sat, 31 May 2008 01:14:16 +0200 Stefan Potyra <sistpoty@ubuntu.com>
wrote:
>Hi folks,
>
>as overheard on #ubuntu-devel today, please don't use one bug with many
>different tasks for transitions. The problem with this is, that any
>subscriber of an affected package will get every mail for a change in that
>bug (in short: [he/she'll get] "zillion mails" [in which he/she has] "no
>interest in"[1]).

I think this is an unfortunate aspect of the curent LP design.

>For what tasks are not meant to be used, I'll give you this quotation: "if
the
>fixes required would be independent, they should be separate bugs" [2]

I don't understand. By definition all packages that need changes to fix a
bug will be different. If I understand this statement, then also affect
should never be used for different packages. This isn't what I would have
expected.

>Finally, one option to handle transitions via LP was also proposed: "it's
>easier to file [separate] bugs and tag those" [3].
>
Tags have their own problems (see recent discussions on ubuntu-devel). I'd
say it's much harder. One mass bug is one email. One bug per package is
one email per package.

I don't think LP currently offers a good solution for this type of problem.

Scott K

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-31-2008, 12:35 AM
Stefan Potyra
 
Default don't use bug tasks for transitions

Hi,

Am Samstag 31 Mai 2008 02:01:56 schrieb Scott Kitterman:
> On Sat, 31 May 2008 01:14:16 +0200 Stefan Potyra <sistpoty@ubuntu.com>
>
> wrote:
> >Hi folks,
> >
> >as overheard on #ubuntu-devel today, please don't use one bug with many
> >different tasks for transitions. The problem with this is, that any
> >subscriber of an affected package will get every mail for a change in that
> >bug (in short: [he/she'll get] "zillion mails" [in which he/she has] "no
> >interest in"[1]).
>
> I think this is an unfortunate aspect of the curent LP design.

Can you elaborate on this? (as Sebastien already noted on irc, one might be
interested in comments to fixed bugs as well. So I personally don't see a
design, which would fix this... of course I'd be happy to get good ideas on
this).

>
> >For what tasks are not meant to be used, I'll give you this quotation: "if
>
> the
>
> >fixes required would be independent, they should be separate bugs" [2]
>
> I don't understand. By definition all packages that need changes to fix a
> bug will be different. If I understand this statement, then also affect
> should never be used for different packages. This isn't what I would have
> expected.

Let me give two examples:
perl transition: you can upload each package individually, so these should be
two different bugs.

OTOH, you might want to look at bug #59945 (which I wrongly never added a task
for nvidia-settings). This was only fixed by updating both nvidia-settings
and sensors-applet.
(sorry, you'll need to dig in the bug comments probably to find out the
problem for this example.)

>
> >Finally, one option to handle transitions via LP was also proposed: "it's
> >easier to file [separate] bugs and tag those" [3].
>
> Tags have their own problems (see recent discussions on ubuntu-devel). I'd
> say it's much harder. One mass bug is one email. One bug per package is
> one email per package.

The problem afaict is that mass bugs generate email, for each package, even if
this package is already fixed. And yes, tags have their own problems. That's
why I wrote that it could be one option. I'd be eager to hear what other
solutions exist for this problem.

>
> I don't think LP currently offers a good solution for this type of problem.
This may very well be true .

Cheers,
Stefan.
--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-31-2008, 08:15 AM
Michael Bienia
 
Default don't use bug tasks for transitions

On 2008-05-31 01:14:16 +0200, Stefan Potyra wrote:
> as overheard on #ubuntu-devel today, please don't use one bug with many
> different tasks for transitions. The problem with this is, that any
> subscriber of an affected package will get every mail for a change in that
> bug (in short: [he/she'll get] "zillion mails" [in which he/she has] "no
> interest in"[1]).

OK, will do so in the future for the remaining perl 5.10 transition (as
this discussion started about bug #230016).

I've done the first rebuild sponsorship requests (for -perl packages in
main) via seperate bugs, but found it cumbersome (when you need several
requests):
- test if a rebuild works (are the build dependencies already
transitioned?)
- open a bug on LP to get a bug number
- add bug number to debian/changelog
- create debdiff and attach it to the bug
- subscribe u-m-s
Repeat this for every rebuild request (mostly copy the bug title and
description from the previous bug).

I started then using one bug for all my sponsoring request, as I could
add the bug number to the changelog entry while preparing the test-build
of the package. This made the process much lighter:
- add a changelog entry for the rebuild (incl. bug number)
- check if the package actually builds
- if yes, create debdiff
- attach debdiff to the bug and add a task for that package

This bug got out of control when someone added tasks for all affected
packages

It's a nice feature that one can add attachments while filing new bugs
but that doesn't help in case of debdiffs where one needs to know the
bug number in advance.

Michael

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-31-2008, 05:47 PM
Scott Kitterman
 
Default don't use bug tasks for transitions

On Sat, 31 May 2008 02:35:03 +0200 Stefan Potyra <sistpoty@ubuntu.com>
wrote:
>Hi,
>
>Am Samstag 31 Mai 2008 02:01:56 schrieb Scott Kitterman:
>> On Sat, 31 May 2008 01:14:16 +0200 Stefan Potyra <sistpoty@ubuntu.com>
>>
>> wrote:
>> >Hi folks,
>> >
>> >as overheard on #ubuntu-devel today, please don't use one bug with many
>> >different tasks for transitions. The problem with this is, that any
>> >subscriber of an affected package will get every mail for a change in
that
>> >bug (in short: [he/she'll get] "zillion mails" [in which he/she has] "no
>> >interest in"[1]).
>>
>> I think this is an unfortunate aspect of the curent LP design.
>
>Can you elaborate on this? (as Sebastien already noted on irc, one might
be
>interested in comments to fixed bugs as well. So I personally don't see a
>design, which would fix this... of course I'd be happy to get good ideas
on
>this).
>
It could be solved one of two ways:

1. Not send the mails relavent to packages users aren't subscribed to and
then users can subscribe to the bug if they want more.

2. Send bugmail as currently but allow users to unsubscribe from/
blacklist specific bugs so they get no more bugmail on that bug but remain
subscribed to the package.

I think either of those would be an improvement. I'm not sure which would
be better.

Scott K

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 05-31-2008, 09:19 PM
"Jordan Mantha"
 
Default don't use bug tasks for transitions

BTW, shouldn't this discussion be on ubuntu-devel or launchpad-users? It doesn't seem specific to MOTU.

On Sat, May 31, 2008 at 10:47 AM, Scott Kitterman <ubuntu@kitterman.com> wrote:

On Sat, 31 May 2008 02:35:03 +0200 Stefan Potyra <sistpoty@ubuntu.com>


wrote:

>Hi,

>

>Am Samstag 31 Mai 2008 02:01:56 schrieb Scott Kitterman:

>> On Sat, 31 May 2008 01:14:16 +0200 Stefan Potyra <sistpoty@ubuntu.com>

>>

>> wrote:

>> >Hi folks,

>> >

>> >as overheard on #ubuntu-devel today, please don't use one bug with many

>> >different tasks for transitions. The problem with this is, that any

>> >subscriber of an affected package will get every mail for a change in

that

>> >bug (in short: [he/she'll get] "zillion mails" [in which he/she has] "no

>> >interest in"[1]).

>>

>> I think this is an unfortunate aspect of the curent LP design.

>

>Can you elaborate on this? (as Sebastien already noted on irc, one might

be

>interested in comments to fixed bugs as well. So I personally don't see a

>design, which would fix this... of course I'd be happy to get good ideas

on

>this).

>

It could be solved one of two ways:



1. Not send the mails relavent to packages users aren't subscribed to and

then users can subscribe to the bug if they want more.



2. *Send bugmail as currently but allow users to unsubscribe from/

blacklist specific bugs so they get no more bugmail on that bug but remain

subscribed to the package.


There are two relevant Launchpad bugs open:

1) https://bugs.launchpad.net/bugs/83488
- this is to implicitly unsubscribe people/teams who have been
implicitly subscribed (by being subcribed to the package) when the
relevant task has been changed to Invalid. This would make it so that
mistaken tasks wouldn't been so annoying. It might also be possible to
do the same thing for Fix Released but I think there may be some debate
on that.


2)https://bugs.launchpad.net/bugs/204980
- I filed this bug to allow people/teams implicitly subscribed to
unsubscribe to a specific bug. This is Scott's 2. above. However, my
impression after talking with Launchpad developers is that this is
rather difficult to do with the current Launchpad code so it might be
quite some time (if ever) for it to get implemented.


I also wrote an email to launchpad-users back in early April on
this subject [0] but didn't get any response from Launchpad people. I
believe, as a generalization, they believe such "metabugs" are an abuse
of bug tasks, though one that they open themselves up to by having such
a feature. Indeed, they are a bit of a corner case and don't happen all
that often. It's just that when they do it's rather annoying to be
spamming hundreds of people :-)


Another solution, IMO, would be to file individual bugs against the packages but then have a "transition tracker" on ubuntuwire.com
that would track the various bugs. It would be fairly easy I think to
have a general template where all you needed to do is tell it the bug
numbers and it would set up a page to track the status. We could also
have a submission script to help with the mass filing for transitions.


I don't like the idea of tracking activities in one tool (LP) with another tool (pages on qa.ubuntuwire.com)
but I think the fact of the matter is that Launchpad will never fully
cater to our needs so we need a rubust toolset to be able to get what
we need. If we can at least standardize on one place for such
extra-Launchpad scripts (like qa.ubuntuwire.com or people.ubuntu.com) then I think it'd really help.



-Jordan

[0] https://lists.ubuntu.com/archives/launchpad-users/2008-April/003550.html


--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 06-01-2008, 04:42 AM
Sarah Hobbs
 
Default don't use bug tasks for transitions

Hey all!

I've recently discovered another reason not to use this too - if the
number of tasks in the bug is too high, launchpad will fall over
(timeouts) in attempting to open them. Launchpad has managed to improve
this in the last couple of releases, but this is clearly still a problem.


This effects more than just transition bugs (eg, #230350) - so perhaps
implementing a policy on reasonable sizes of bug tasks for each bug
would be wise. Clearly, this is not just a mail problem.


For those unfortunate enough to encounter bugs like these, which tend to
require multiple page refreshes to make anything change, remember that
you can use the email interface, documented at:

https://help.launchpad.net/BugTrackerEmailInterface

Hobbsee

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 06-03-2008, 10:33 AM
Stephan Hermann
 
Default don't use bug tasks for transitions

Moins,

sorry for the delay of replying to this thread, but the LinuxTag was
not so good for reading and writing mails

On Sat, 31 May 2008 02:35:03
+0200 Stefan Potyra <sistpoty@ubuntu.com> wrote:

> [...]
> >
> > >Finally, one option to handle transitions via LP was also
> > >proposed: "it's easier to file [separate] bugs and tag those" [3].
> >
> > Tags have their own problems (see recent discussions on
> > ubuntu-devel). I'd say it's much harder. One mass bug is one
> > email. One bug per package is one email per package.
>
> The problem afaict is that mass bugs generate email, for each
> package, even if this package is already fixed. And yes, tags have
> their own problems. That's why I wrote that it could be one option.
> I'd be eager to hear what other solutions exist for this problem.

as long as LP doesn't offer a real task tracker...there is no solution
(without introducing new tools which are not linked to LP).
The discussion is always about workflow tasks...and not about real "bug
reports".

So...what are the LP people thinking about adding workflow structures
to LP? IMHO this could be also a good "business case" for customers...

Regards,

sh

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 

Thread Tools




All times are GMT. The time now is 12:26 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org