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 > Launchpad User

 
 
LinkBack Thread Tools
 
Old 01-14-2011, 10:51 AM
Alexander Reichle-Schmehl
 
Default Forwarding bugs upstream

Hi!

Am 13.01.2011 11:54, schrieb Olaf van der Spek:

>> Now we just need to define what a proper job is.
> Instead of stepping down, it might be better to ask for a co-maintainer.

You mean like this http://www.debian.org/devel/wnpp/help_requested?
Let's have a look:

# chromium-browser [..] requested 228 days ago.
# dpkg [..] requested 2245 days ago.
# grub2 [..] requested 2439 days ago.
# libreoffice [..] requested 1368 days ago.

Any other good ideas? Perhaps something new ideas, which isn't already
practices?


Best regards,
Alexander


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D3038D4.50105@schmehl.info">http://lists.debian.org/4D3038D4.50105@schmehl.info
 
Old 01-14-2011, 11:08 AM
Olaf van der Spek
 
Default Forwarding bugs upstream

On Fri, Jan 14, 2011 at 12:51 PM, Alexander Reichle-Schmehl
<alexander@schmehl.info> wrote:
> Hi!
>
> Am 13.01.2011 11:54, schrieb Olaf van der Spek:
>
>>> Now we just need to define what a proper job is.
>> Instead of stepping down, it might be better to ask for a co-maintainer.
>
> You mean like this http://www.debian.org/devel/wnpp/help_requested?
> Let's have a look:
>
> # chromium-browser [..] requested 228 days ago.
> # dpkg [..] requested 2245 days ago.
> # grub2 [..] requested 2439 days ago.
> # libreoffice [..] requested 1368 days ago.
>
> Any other good ideas? *Perhaps something new ideas, which isn't already
> practices?

There are lots of packages with old bugs without any comments that are
not on that list.

Olaf


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTikBTzEcpfQQZ_0mFgPYCxtYQ5TnH_i+yyCVqg52@mail .gmail.com">http://lists.debian.org/AANLkTikBTzEcpfQQZ_0mFgPYCxtYQ5TnH_i+yyCVqg52@mail .gmail.com
 
Old 01-14-2011, 11:27 AM
Stefano Zacchiroli
 
Default Forwarding bugs upstream

On Fri, Jan 14, 2011 at 11:29:58AM +0000, Sune Vuorela wrote:
> We have written a bit about what's needed here:
> http://pkg-kde.alioth.debian.org/bugs.html

A while ago I've reviewed a little bit which kind of contributions
distros are looking for, from people who are willing to get involved
with the distro (see #608400 for a corresponding goal).

Most distros are looking for "bug triager" and providing specific
documentation to train contributors in that direction. Historically in
Debian we haven't looked for that, beside the very much understandable
periodic cries for help from maintainers of popular package suites
(GNOME, KDE, etc.).

Maybe its time to generalize that? For instance, it seems to me that
most of the above documentation by the KDE team is general and can be
used to document a general "bug triaging" task on our "how to
contribute" pages? Looking on wiki.d.o and www.d.o we don't seem to have
much (any?) of it.

Would anyone be against inviting explicitly that kind of contributions?

Note: I'm well aware that some contributors are going to make mistakes
and do bad triaging at times, there's now way around that, but I don't
think it's a valid reason not to try.

Cheers.

--
Stefano Zacchiroli -o- PhD in Computer Science PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
 
Old 01-14-2011, 12:32 PM
Felipe Sateler
 
Default Forwarding bugs upstream

On Thu, 13 Jan 2011 00:38:37 +0000, Ian Jackson wrote:

> Felipe Sateler writes ("Re: Forwarding bugs upstream"):
>> On Wed, 12 Jan 2011 16:56:56 +0000, Ian Jackson wrote:
>> > I think it is always reasonable for the maintainer to forward the bug
>> > upstream.
>> >
>> > But what I think is bad is _demanding_ or _requiring_ the maintainer
>> > to forward the bug upstream. If they don't want to do that for
>> > whatever reason then asking the submitter to do so is IMO perfectly
>> > acceptable.
>>
>> We can't demand or require anyone to do anything. Yet we expect
>> maintainers to answer bug reports, provide packages, etc. The fact that
>> you can't force anyone to do anything doesn't mean you can't say that
>> some behavior is preferred or considered best practice.
>
> Yes.
>
> But in this case I don't think we should be "expecting" maintainers to
> necessarily shepherd bug reports upstream. I don't think a maintainer
> who fails to do so is failing in their job as maintainer.
>
> The maintainer should decide whether they think doing that is a useful
> thing to be doing for that package or that bug, and communicate this
> decision to the user (and set the bug state accordingly).

Just like they do about their whole debian work: prioritizing work and
their own free time.

My point is more along the lines of Bernhard's comment: packages where
the maintainer takes (well-defined) reports upstream are better
maintained than packages where the maintainer does no such thing.

Going back to the OP's comment, when one takes the time to fill a well-
described report, maybe even write a patch for it, the maintainer should
(again, time permitting) forward the request upstream. I do not think it
is reasonable to expect every bug reporter to register in upstream's bug
tracker (unfortunately, a big bunch of upstreams require registration,
even for their mailing lists!), specially when the maintainer should have
already an account.


--
Saludos,
Felipe Sateler


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: igpja8$inb$1@dough.gmane.org">http://lists.debian.org/igpja8$inb$1@dough.gmane.org
 
Old 01-14-2011, 12:46 PM
Felipe Sateler
 
Default Forwarding bugs upstream

On Thu, 13 Jan 2011 10:27:12 +0000, Sune Vuorela wrote:

> On 2011-01-13, Felipe Sateler <fsateler@debian.org> wrote:
>> We can't demand or require anyone to do anything. Yet we expect
>
> I think this is mostly wrong.
>
> We can demand or require people to step down. And we should if we don't
> think they do a proper job.

I don't agree. First of all, we don't require people to step down, we
hijack their packages (which means we force them to not do something).
Second, we do that not when they are not doing a proper job, but when
they actually block others from doing the proper job.


--
Saludos,
Felipe Sateler


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: igpk3k$inb$2@dough.gmane.org">http://lists.debian.org/igpk3k$inb$2@dough.gmane.org
 
Old 01-14-2011, 01:53 PM
Lisandro Damián Nicanor Pérez Meyer
 
Default Forwarding bugs upstream

On Fri, Jan 14, 2011 at 9:27 AM, Stefano Zacchiroli <zack@debian.org> wrote:
> On Fri, Jan 14, 2011 at 11:29:58AM +0000, Sune Vuorela wrote:
>> We have written a bit about what's needed here:
>> http://pkg-kde.alioth.debian.org/bugs.html
>
> A while ago I've reviewed a little bit which kind of contributions
> distros are looking for, from people who are willing to get involved
> with the distro (see #608400 for a corresponding goal).
>
> Most distros are looking for "bug triager" and providing specific
> documentation to train contributors in that direction. Historically in
> Debian we haven't looked for that, beside the very much understandable
> periodic cries for help from maintainers of popular package suites
> (GNOME, KDE, etc.).
>
> Maybe its time to generalize that? For instance, it seems to me that
> most of the above documentation by the KDE team is general and can be
> used to document a general "bug triaging" task on our "how to
> contribute" pages? Looking on wiki.d.o and www.d.o we don't seem to have
> much (any?) of it.

If it's worth anything, that same document + the help from the Qt/KDE
team helped me a lot to understand the workflow for bug triaging.
Understanding the technical part was not difficult, but the workflow
tends to be the the most obscure part.

+1 for a general doc for that.

--
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTikoCgu1-PPnmTYGz+Jh0TsU-g9=Wej4zXiE4XJq@mail.gmail.com">http://lists.debian.org/AANLkTikoCgu1-PPnmTYGz+Jh0TsU-g9=Wej4zXiE4XJq@mail.gmail.com
 
Old 01-14-2011, 02:29 PM
Gunnar Wolf
 
Default Forwarding bugs upstream

John Goerzen dijo [Thu, Jan 13, 2011 at 05:08:26PM -0600]:
> So let's run out your scenario a bit: upstream asks user to test with
> upstream version X. Bug isn't reproducible by maintainer. Does the
> maintainer now have to provide user with binaries? This gets
> complicated when packaging isn't ready for the version in question, when
> the user has an arch the maintainer doesn't, etc.

Often, users with not-so-mainstream architectures will have better
technical understanding and more ability to help following up a
report.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110114152919.GA7961@gwolf.org">http://lists.debian.org/20110114152919.GA7961@gwolf.org
 
Old 01-14-2011, 02:49 PM
John Goerzen
 
Default Forwarding bugs upstream

On 01/13/2011 06:19 PM, Jesús M. Navarro wrote:

Hi, Sune:

On Thursday 13 January 2011 00:12:06 Sune Vuorela wrote:

On 2011-01-12, Jesús M. Navarro<jesus.navarro@undominio.net> wrote:

I have considered to take this one step further. Close bugs reported in
Debian BTS with a severity of important or less that is a bug that
should primarily be fixed upstream.


Will this mean that the problem will somehow disappear from Debian?
Because if it's a problem detected within Debian it's my feeling that it
will have to be tracked within Debian till the problem is in Debian no
more.


No. but it is a way to be honest about teh issue: We are not spending
debian time on fixing it.


Then tag is as such. It is quite good to be honest: if you are not going to
deal with it, plainly say so, no problem. But *don't* close them as long as
the problem is still there.


I think it is a huge waste of time to expect DDs to go through 400 bugs
just to see if the problem is still there. Just close them outright.


It is no better to have bugs tagged wontfix that are really fixed than
to have bugs closed in our BTS and filed upstream.


- John


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D30707E.1040505@complete.org">http://lists.debian.org/4D30707E.1040505@complete.org
 
Old 01-14-2011, 10:40 PM
"Jesús M. Navarro"
 
Default Forwarding bugs upstream

Hi, John:

On Friday 14 January 2011 16:49:18 John Goerzen wrote:
[...]

> I think it is a huge waste of time to expect DDs to go through 400 bugs
> just to see if the problem is still there. Just close them outright.

Why the package(s) got 400 bugs to start with? If the problem is there, then
it's there. If somebody opened the bug then there was a bug at least on his
opinion which nobody challenged. If there was a bug, then it need to be
supposed that it will be there till there exists clear indication on the
contrary. Anything else is awful practice.

> It is no better to have bugs tagged wontfix that are really fixed than
> to have bugs closed in our BTS and filed upstream.

It's no better? It's probably orders of magnitude better (basically as the
ratio between Debian users versus Debian developers).

What are the chances of me looking for info about a bug I'm not suffering
(because it's already fixed)? I'd bet nil, so that's the effect of a still
opened -but already corrected bug.

But if I'm suffering a bug and it's already declared on Debian's bug database
I want to know and it'll save not only my time but that of any other people
that will certainly suffer it if I know what to expect about it. Even you,
as a Debian developer want to avoid me and others like me to open duplicate
bugs.

Cheers.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201101150040.39563.jesus.navarro@undominio.net">ht tp://lists.debian.org/201101150040.39563.jesus.navarro@undominio.net
 
Old 01-14-2011, 11:06 PM
Russ Allbery
 
Default Forwarding bugs upstream

"Jesús M. Navarro" <jesus.navarro@undominio.net> writes:

> Why the package(s) got 400 bugs to start with? If the problem is there,
> then it's there. If somebody opened the bug then there was a bug at
> least on his opinion which nobody challenged. If there was a bug, then
> it need to be supposed that it will be there till there exists clear
> indication on the contrary. Anything else is awful practice.

I would argue that by the time the package reaches several thousand open
bugs, all of which are some random mix of upstream, fixed, unreproducible,
packaging, and incomplete reports, the BTS has become essentially unusable
for everyone. The maintainers rarely have time to go back and look at
those thousands of bugs in any meaningful way, and users are not going to
be able to reasonably search through that many bugs to see if any of them
are the problem that they're running into. At that point, the BTS is
about as useful as a mailing list archive and the only chance that
anything in there is going to be helpful is if Google happens to index it.

In my personal experience, generally at that point the mailing list
archive of wherever the bugs were originally sent is actually *more*
useful since it's better-indexed.

I think we have a significant failure mode here with packages that get
large numbers of bugs. The BTS becomes pretty much unusable without very
active triaging for those packages. And this is not a Debian-specific
problem; for example, it's essentially impossible to extract any useful
information from the Ubuntu nvidia-graphics-drivers bug page, and it only
has 350 bugs. (Launchpad is, in my experience, worse than the Debian BTS
at handling large bug volumes and becomes unusable faster.)

There are a lot of things that have been said on this thread that I
completely agree with for the average Debian package that gets a handful
of bugs a month and doesn't have more than 50-100 bugs open at a time. I
think most of the people commenting here have dealt primarily with those
sorts of packages, and that's the experience in which the comments are
grounded.

Packages with thousands of bugs are another world, and while I agree with
the drawbacks of aggressive bug triaging, I think aggressive bug triaging
is still a better approach than letting the BTS page become a junk pile of
abandoned reports no one is ever going to look at again.

Obviously, the ideal is to have teams that scale with the incoming bug
count for the package, who will stay on top of all those bugs and
categorize them appropriately and ping unreproducible bugs, forward
upstream bugs, and do all the great things that make the world a better
place. But in the world in which we live, that manpower simply doesn't
exist. If wishes were horses, beggars would ride. We have to apply
strategies that are realistic given the manpower that we actually have,
not the manpower that we wish we had.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87vd1rt4i0.fsf@windlord.stanford.edu">http://lists.debian.org/87vd1rt4i0.fsf@windlord.stanford.edu
 

Thread Tools




All times are GMT. The time now is 07:31 AM.

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