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-13-2011, 01:56 PM
Ian Jackson
 
Default Forwarding bugs upstream

Ansgar Burchardt writes ("Re: Forwarding bugs upstream"):
> Ubuntu has a team (Bug Squad[1]) that tries to triage incoming bug
> reports, including forwarding them upstream when applicable.
>
> I don't know how successful this is, but if it has success, then maybe
> we could try to recruit volunteers for a similar team in Debian as well?
> This should of course include mentoring them a bit as well.

Ubuntu on the whole has more of a problem with large numbers of
poor-quality bug reports than Debian, but there are certainly serious
problems in some parts of Debian that less-skilled triagers will be
able to help with.

Overall I think the Ubuntu approach was helpful while I was there.
Perhaps some people who have more substantial current involvement with
Ubuntu can comment in more detail.

What I saw was that less-skilled triagers have a tendency to:
* make more mistakes than a maintainer will
* overall, between them, have more effort than maintainers so
it can be difficult to correct these mistakes
* copy each other in a way that can make undesirable memes
and particular undesirable behaviours spread and then be
very hard to stamp out
* apply fixed rules to situations rather than trying to rely on
judgement (and anyway their judgement might be poor) which
in the worst case can make them seem robotic
* apply approaches out of their appropriate context - eg
aggressively triage bugs for packages which don't have a bug
flood problem or interfere with bugs filed by developers
* behave as if bug reports are a bad thing and the idea is to
close as many as possible (the opposite problem from
the other common meme which is that bug reports are a good thing
and we should try to get users to file as many as possible)

I think many of these things could be dealt with by better education
and mentoring, if we could find some people to do that mentoring and
oversight of bug-squad style triagers.

Debian would also have the problem that Debian maintainers are
generally a lot more "prickly" than Ubuntu maintainers. Ubuntu tries
very hard to be approachable; this has advantages and disadvantages
but in the context of a "bug squad" Debian will also have the risk
that bug squad members will get flamed and thus discouraged over small
mistakes.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 19759.4746.747018.61439@chiark.greenend.org.uk">ht tp://lists.debian.org/19759.4746.747018.61439@chiark.greenend.org.uk
 
Old 01-13-2011, 02:11 PM
Don Armstrong
 
Default Forwarding bugs upstream

On Thu, 13 Jan 2011, Olaf van der Spek wrote:
> The point is focus on solving bugs shouldn't be limited to BSPs and
> the end of the release cycle.

It never is restricted to just those times; it just becomes more
important as we get closer and closer to release.


Don Armstrong

--
This isn't life in the fast lane, it's life in the oncoming traffic
-- Terry Pratchett

http://www.donarmstrong.com http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110113151101.GO5454@teltox.donarmstrong.com">htt p://lists.debian.org/20110113151101.GO5454@teltox.donarmstrong.com
 
Old 01-13-2011, 05:25 PM
John Goerzen
 
Default Forwarding bugs upstream

On 01/12/2011 09:35 AM, Gunnar Wolf wrote:

Ben Finney dijo [Wed, Jan 12, 2011 at 04:01:46PM +1100]:

(...)

I'm adding zero value here. Zero. It is a huge and frustrating waste
of my time.


Not in my view. I appreciate the Debian package maintainer acting in the
interest of “lower the barrier for each Debian user of this package to
report useful bug information”.

To be clear: Thank you for the time you spend doing this, and the same
to any other Debian maintainer who does unromantic work to keep the
good information flowing.


You are clearly adding value, you will probably word the user's
request in a better way, you will know the library versions and
settings the package was compiled with, the way it is installed,
etc. You will probably forward only some relevant bits - We as package
maintainers should bridge between a nontechnical user and the upstream
developers. Of course, if your bug report was initially submitted by a


Those are some valid points, probably more valid for many packages than
Bacula (for reasons I'll get into later).


But still, let's say that a Debian developer has X minutes to spend on
Debian a day. What kinds of tasks that the developer does will add the
most value to Free Software or benefit the most people to the greatest
degree?


* Working on Debian packaging

* Fixing bugs that are within their scope/ability

* Working on documentation

* Cut-and-paste monkey with upstream BTSs

I suggest that the last item provides the least value. If we realize
that it is displacing time that Debian developers could be spending on
things that benefit Free Software more, and frankly they are likely to
enjoy more, it's a disturbing picture.


Some of what you've suggested above could be accomplished by the DD
telling the user, "Here, include this info in your bug report and get me
back in the loop if you need me."


This is a special case of more general communication problems. It is
rarely a good idea to have a gatekeeper in place between people that are
capable of communicating already.


If the user is not capable of producing cogent answers and a useful bug
report, even when asked for specific details, this user is unlikely to
produce a useful bug report for upstream. But the user is also unlikely
to produce a useful bug report for Debian. I don't see my task as a
maintainer to provide education to the user on how to read standard
logfiles, use the command line (when relevant), etc.


This is a particular problem with Bacula. There are many users that are
unable to distinguish between a configuration mistake or
misunderstanding on their part and a bug. I imagine this phenomenon
exists in any sufficiently complex package that takes users out of their
existing comfort zone. If it's clear to me that it's not a bug, I'll of
course close it and point them to the Bacula users mailing list.
Sometimes it is unclear immediately whether they have discovered a bug
or not, but it is quite clear that they don't understand how to
configure Bacula and would need a tremendous amount of handholding to
get to the point where we know if there's even a bug or not. Again I
try to push these to bacula-users. If someone asks me a question I know
the answer to off the top of my head, I'll answer, but I never promised
to provide free tech support by maintaining Bacula ;-)


-- John


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D2F43B7.6070800@complete.org">http://lists.debian.org/4D2F43B7.6070800@complete.org
 
Old 01-13-2011, 08:02 PM
Russ Allbery
 
Default Forwarding bugs upstream

Olaf van der Spek <olafvdspek@gmail.com> writes:

> That's unfortunately true. Why is it that bug squashing parties only
> happen a short time before release while it appears that the rest of the
> time the issue is ignored?

This didn't happen during this release cycle, at least from my
perspective. I remember lots of bug-squashing parties early on in
squeeze's development.

--
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: 87lj2ocyaj.fsf@windlord.stanford.edu">http://lists.debian.org/87lj2ocyaj.fsf@windlord.stanford.edu
 
Old 01-13-2011, 08:08 PM
Ben Finney
 
Default Forwarding bugs upstream

John Goerzen <jgoerzen@complete.org> writes:

> On 01/12/2011 09:35 AM, Gunnar Wolf wrote:
> > You are clearly adding value [… enumeration of many ways the
> > maintainer adds significant value by relaying bug report discussions
> > …]

> Those are some valid points, probably more valid for many packages
> than Bacula (for reasons I'll get into later).
>
> But still, let's say that a Debian developer has X minutes to spend on
> Debian a day. What kinds of tasks that the developer does will add
> the most value to Free Software or benefit the most people to the
> greatest degree?

That issue (use of limited resources) is of course important, and I
appreciate that it is sub-optimal to have skilled maintainers spend
limited resources on what feels like mechanical work.

I would ask, though, that this description:

> * Cut-and-paste monkey with upstream BTSs

be amended, even if only in the maintainer's mental description of the
task, in light of the points raised by Gunnar and others about the value
added by the maintainer relaying information from the user. It's usually
more valuable than merely cut-and-paste monkey, and realising that may
help it feel (a little?) less frustrating.

> I suggest that the last item provides the least value.

Of the items you listed, I agree that yes, relaying bug report
information is often low in terms of value added.

But it does add significant value in more cases than not. At the least,
it adds the value that, if it gets to the point where such a decision
needs to be made, a significant proportion of such valid bug reports
would not otherwise be reported upstream at all.

So, thank you to any maintainer who does this work, and I hope this
thread helps it happen more by making clearer the value maintainers are
adding when they do so.

--
“Yesterday I parked my car in a tow-away zone. When I came back |
` the entire area was missing.” —Steven Wright |
_o__) |
Ben Finney


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87tyhca4vs.fsf@benfinney.id.au">http://lists.debian.org/87tyhca4vs.fsf@benfinney.id.au
 
Old 01-13-2011, 08:14 PM
Stefano Zacchiroli
 
Default Forwarding bugs upstream

On Thu, Jan 13, 2011 at 02:46:35PM +0000, Ian Jackson wrote:
> Anecdote: while I was employed by Canonical I had to dissuade some of
> my colleagues from implementing and deploying, without consent from
> Debian, a feature in Launchpad that would automatically file
> corresponding bug reports in the Debian BTS. I expressed the view
> that doing so would be considered abuse by the Debian BTS admins and
> would probably result in some emergency ad-hoc wholesale blocking of
> Launchpad's access to Debian infrastructure. Not to mention an
> absolutely enormous flamewar.
>
> To all of us that would obviously have been a really bad idea.
> Let us be careful not to do to our upstreams what we don't want our
> downstreams to do to us.

Right, it's a sane principle.

By the same principle, I'm sure that we in Debian would not appreciate
if Ubuntu developers would ask their users to submit _packaging_ bugs to
Debian no matter what, instead of filing them to Launchpad first. By
doing so, they would risk that a bug apparently due to Debian is in fact
induced---in some non obvious [1] way---by some other Ubuntu change.

The example can easily be transposed from the Ubuntu<->Debian border to
the Debian<->Upstream border. If we ask users to submit bug report
upstream no matter what, we risk of upsetting upstreams if, repeatedly,
they'll start getting bug reports which users believe to be upstream
whereas they are Debian's "fault", in some non obvious way.

The only conclusions I can make from the above are:

a) Getting upset for *specific* bug reports is pointless: there are
always going to be bug reports filed at wrong targets which are
someone-else's "fault". Getting upset for them won't make them less
likely in the future and will just worsen relationships between the
corresponding upstream (resp. downstream). The best we can do is
devise practices that reduce the *overall* risk of shooting bugs at
the wrong target.

b) To reduce that risk, the best we can do is teach users guidelines
about where to report bugs. The driving principle could be something
like:

"if you feel confident in judging that and if you think the bug
belongs upstream then please report it upstream directly; doing
otherwise will just increase communication overhead"

Note that our *current* policy [2] is exactly dual to that; we
explicitly ask users to report the bug to Debian even if the user
thinks it belong upstream. Clearly, the current policy err on the
cautious side; this thread might lead to consensus in empowering
users more with that decision. (Then, if we reach it, we should
document it properly in various places, including that page and
reportbug---discussing it only among devs without informing users
will be quite useless.)

Note that, even with that policy, there will be users reporting to
Debian (because they don't read the doc, because they don't know how
to report upstream, because they can't make the judgement, etc.).

Cheers.


[1] "obvious" here is in user's opinion, as when a bug report is filed
there are only users who can judge that
[2] http://www.debian.org/Bugs/Reporting

--
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-13-2011, 09:59 PM
John Goerzen
 
Default Forwarding bugs upstream

On 01/12/2011 05:59 PM, Ben Finney wrote:


Rather, I'm arguing that the maintainer role, as a mediator and
interface between upstream and the Debian user, entails a whole lot of
different tasks, and being a mediator in the discussion between
upstream-who-doesn't-care-about-Debian-specifically and
Debian-user-with-a-bug-report is part of that role.


That's a good point, and I actually agree with that. But I (think) I
disagree on how it necessarily is implemented. In other words, I would
be happy to point the submitter to the upstream BTS, send them a
paragraph to cut and paste into their report that contains anything
relevant from the Debian perspective, and leave them with a promise to
be willing to get involved should anyone think I need to be. That part
does add value. Copying and pasting conversations back and forth doesn't.


- John


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D2F83D1.4070904@complete.org">http://lists.debian.org/4D2F83D1.4070904@complete.org
 
Old 01-13-2011, 10:08 PM
John Goerzen
 
Default Forwarding bugs upstream

On 01/12/2011 12:52 AM, Nikita V. Youshchenko wrote:

I understand that maintainers' time is limited and that forwarding bugs
is not an enjoyable task. But I also understand that having a BTS
account for the upstream BTS of each of the 2405 packages I have
installed on my laptop (not to mention my other machines) is simply not
practical. I also don't have the benefit of the rapport that a
maintainer has with upstream and knowledge of upstream practices.


Upstream tend to request users to install latest and greatest versions,
often for source or using other unsafe methods. Not only for package in
question but also for explicit and implicit dependences. Non-technical
follow these broken advices and break their systems. And then complain
that Debian is problematic for them.


Not all upstreams are like that, but I think that brings to the front an
important point: there are vast differences in users, in upstreams, and
in maintainers.


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.


-- John


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D2F85EA.1050205@complete.org">http://lists.debian.org/4D2F85EA.1050205@complete.org
 
Old 01-13-2011, 11:19 PM
"Jess M. Navarro"
 
Default Forwarding bugs upstream

Hi, Sune:

On Thursday 13 January 2011 00:12:06 Sune Vuorela wrote:
> On 2011-01-12, Jess 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.

> >> Currently, the debian Qt/KDE team has around 800 open, non-forwarded
> >> bugs reported against their packages. I would guess that maybe 20 of
> >> them is packaging issues. But we can't find them.
> >
> > Start one at a time.
>
> With more bugs arriving than we are able to close?

Start one at a time.

Your end-year bonus won't suffer if your Debian's bug queue is longer by then,
will it?

If your problem is too short of a workforce don't be ashamed of it and be
honest enough for the bug queue to grow as it should.

> > 4) It's not my problem that you lack the time, really. And no, that you
> > are not paid for it it's no excuse either.
> > Maybe it's that you lack the time for the *boring* side of the task or
> > maybe it's that you really don't have the time. In the first case resign
> > as a debian maintainer; in the second one orphan the package. Debian is
> > proud to
>
> Dear Jesus. Are you seriously saying that
> - the kernel mainatiners should step down
> - the xorg maintainers should step down
> - the mozilla maintainers should step down
> - the gnome maintainers should step down
> - the kde maintainers should step down
> - the xfce maintainers should step down
> - the openoffice/libre office maintainers should step down

If they are not ready to take over their shoulders what it takes to do it
properly, undoubtly yes. If that means that Debian project becomes
irrelevant so be it because gaming the statistics for the project to look
what it in fact is not, already means exactly the same only it deludes it
users... for a while.

Please pay attention that I said *if*. That doesn't mean neither an
endorsement nor a beliveness from my side that that's current situation (I'm
far of thinking so, in fact, or else I wouldn't be expending my time here).

> And who do you think should step up ?

Not my problem.
Sorry if I sound harsh but please think about it coldly and you'll see that's
in fact the proper response: if nobody is really up to the task, then the
task should be abandoned.

(This message sounded much more negative than both my mood and my real
intention wanted to, but I found no other way to send the message I wanted to
send. Sorry in advance).

Cheers.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201101140119.22762.jesus.navarro@undominio.net">ht tp://lists.debian.org/201101140119.22762.jesus.navarro@undominio.net
 
Old 01-13-2011, 11:50 PM
"Jess M. Navarro"
 
Default Forwarding bugs upstream

Hi, John:

On Thursday 13 January 2011 19:25:59 John Goerzen wrote:
> On 01/12/2011 09:35 AM, Gunnar Wolf wrote:

[...]

> But still, let's say that a Debian developer has X minutes to spend on
> Debian a day.

Let's be true: it's not that a Debian developer has X minutes to spend but
that a Debian developer *wants* to spend X minutes. Probably same end result
but wildly different motivations.

> What kinds of tasks that the developer does will add the
> most value to Free Software or benefit the most people to the greatest
> degree?
>
> * Working on Debian packaging
>
> * Fixing bugs that are within their scope/ability
>
> * Working on documentation
>
> * Cut-and-paste monkey with upstream BTSs

Managing information, always managing information. Remember: information is
power. First information, then everything else.

In your proposed scope that means:

1) Working on *a* Debian packaging: Without *a* Debian package wouldn't be
bugs for it, would it? But pay attention to the "a" within "a package": it's
of no value (worse than that: it's of negative value) working on new packages
when the already packaged ones are not in good shape (I'll limit my scope to
packages maintained by the same person: it seems to me that there are some
Debian Maintainers -really and luckily a true minority of them, that seem to
be trying to break a record in that they maintain a bazillion of them but
when you look at those packages bug records they have bugs from back to the
day Armstrong footed the Moon. That's of no good).

2) Cut-and-paste monkey with upstream BTSs (for those bugs worth to do it):
that will allow for you to parallelize your effort and more bugs will be
corrected in a given time. If any, bugs you (properly) pass to the upstream
developer are bugs that will cost you not a dime of your valuable time from
them on.

3) Working on documentation (including documenting which bugs are your working
on, which bugs will be dealt with later and which bugs have a known
workaround or you just won't even try to fix and why): properly informing
about your intentions and the real state of your packages will reduce the
rate that bugs come in and will relax your users so they'll be more kind to
you... or at least, it will allow you to say RTFM (or RTF bug reports, or RTF
FAQ) and be with it.

4) Fixing bugs that are within their scope/ability.

I know this will seem quite counterintuitive but yes, fixing bugs is the
lowest of your priorities. If you understand what I said, good; if you
didn't, please, make me the honour of considering me as an authority and act
accordingly (and by act accordingly I mean ala popperian, consider my
reasonements as the less valuable of your knowledge chain but still
valuable).

> Some of what you've suggested above could be accomplished by the DD
> telling the user, "Here, include this info in your bug report and get me
> back in the loop if you need me."

Regarding bugs, the first priority of a package maintainer should always be to
be able to reproduce it and once he is able to reproduce it, taking the user
out of the loop (except for timely informing him of his advances) till the
bug is properly solutioned.

> This is a special case of more general communication problems. It is
> rarely a good idea to have a gatekeeper in place between people that are
> capable of communicating already.

Once the package maintainer is able to reproduce the bug, odds are he will be
the most capable one to properly care about it.

> If the user is not capable of producing cogent answers and a useful bug
> report, even when asked for specific details, this user is unlikely to
> produce a useful bug report for upstream. But the user is also unlikely
> to produce a useful bug report for Debian.

Then, after proper time and effort you will find yourself in the position of
honestly close it with a "non-reproducible" tag.

> I don't see my task as a
> maintainer to provide education to the user on how to read standard
> logfiles, use the command line (when relevant), etc.

Why not? You want to provide Debian with good packages and the end user with
valuable software, don't you?

>
> This is a particular problem with Bacula. There are many users that are
> unable to distinguish between a configuration mistake or
> misunderstanding on their part and a bug.

I know your pain: being there, seen that, got the t-shirt. But you are in the
great situation of being able to tell them RTFM without pain nor remorse. Do
it as needed.

> I imagine this phenomenon
> exists in any sufficiently complex package that takes users out of their
> existing comfort zone. If it's clear to me that it's not a bug, I'll of
> course close it and point them to the Bacula users mailing list.

That should be OK... once you tell the user "out of all my knowlege it seems
to be a configuration problem, please treat it accordingly".

> Sometimes it is unclear immediately whether they have discovered a bug
> or not, but it is quite clear that they don't understand how to
> configure Bacula and would need a tremendous amount of handholding to
> get to the point where we know if there's even a bug or not.

If you don't like our parties, you are free not to come here. In other words:
if you find Bacula to be too hard a package to deal with you are free to
orphan it. After all, packaging it for yourself won't take you any more
effort than packaging it for Debian, will it? But if you want to package it
for Debian, do what it takes to do it properly.

> Again I
> try to push these to bacula-users. If someone asks me a question I know
> the answer to off the top of my head, I'll answer, but I never promised
> to provide free tech support by maintaining Bacula ;-)

That's exactly what you (impliclty) promised -if only just to Debian users.

Cheers.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201101140150.52952.jesus.navarro@undominio.net">ht tp://lists.debian.org/201101140150.52952.jesus.navarro@undominio.net
 

Thread Tools




All times are GMT. The time now is 06:52 PM.

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