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-12-2011, 02:35 PM
Gunnar Wolf
 
Default Forwarding bugs upstream

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
technically knowledgeable user, it might be better just to point him
to a bug report (already opened by you) in the upstream tracker. Also,
when I forward a bug report, I quote the Debian BTS address for the
upstream developers to be able to get the original (although I will
mediate anyway).

Of course, there is not just one kind of user or upstream. Some will
appreciate to get more involved. Some users will sadly just say "this
is b0rken, you must fix it, you suck" - But they are IMO not
prevalent. Many upstreams will want users to use the latest versions,
and it is our task to find how to fix/backport.

> Quite the opposite, from my position. A great feature of the Debian BTS
> is that any user can interact with it through a standard interface
> without maintaining multiple separate identities; heck, without having
> to create a single new identity at all.

FWIW, I have been asked by users and upstreams whether they can
interact with bug reports via a simpler interface, as they prefer not
to use mail for it. Of course, it all depends on the person at hand. I
agree it is good to have a unified, standarized interface for our
users. And, of course, our BTS serves us (the Debian community) very
well.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110112153516.GA26836@gwolf.org">http://lists.debian.org/20110112153516.GA26836@gwolf.org
 
Old 01-12-2011, 03:51 PM
Ian Jackson
 
Default Forwarding bugs upstream

John Goerzen writes ("Re: Forwarding bugs upstream"):
> I'm going to have a slightly different viewpoint on this.

I agree with John, basically.

> I'm adding zero value here. Zero. [...]

Some people have replied suggesting scenarios where the Debian
maintainer is adding something. That's fine - in that case, the
maintainer can do whatever is necessary to add that value.

But I think this should be up to the Debian maintainer. Being a
Debian maintainer should not mean agreeing to be a helpdesk or bug
proxy.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 19757.56337.388114.637603@chiark.greenend.org.uk"> http://lists.debian.org/19757.56337.388114.637603@chiark.greenend.org.uk
 
Old 01-12-2011, 03:56 PM
Ian Jackson
 
Default Forwarding bugs upstream

brian m. carlson writes ("Re: Forwarding bugs upstream"):
> On Tue, Jan 11, 2011 at 09:15:41PM -0600, John Goerzen wrote:
> > I think it is perfectly fine for a user to submit a bug report to
> > the Debian BTS first. They may not always be equipped to know what
> > is a Debian and what is an upstream bug. And I also think it ought
> > to be perfectly valid for the Debian developer to close the bug
> > saying it's an upstream issue, together with a pointer to the
> > upstream BTS and promise to get involved should there be any
> > question about the Debian packaging, environment, etc.
>
> I think this can actually increase the maintainer's burden, since it can
> increase the number of duplicate bug reports, [...]

If the maintainer agrees with you then they will be happy to deal with
the bug report the way you want. But I think this should be up to the
maintainer to decide.

> As I've said, I generally don't mind being added to the CC list, and I
> think that BTS systems should allow non-subscribers (and subscribers) to
> add information via email. I realize that upstreams tend to use BTSes
> that don't do that and therefore make their end users go through a lot
> of unnecessary pain. Also, if the BTS won't CC me when someone responds
> to the bug (even with an account), there is zero chance of me reporting
> the bug upstream, since I have better things to do with my life than
> constantly checking a slew of BTSes.

That is up to you.

If you report the bug to the Debian BTS but neither you nor the Debian
maintainer want to do the make-work of dealing with upstream's tedious
BTS, then the bug will sit in Debian's BTS tagged "should go upstream"
indefinitely.

I don't think it is up to you to say that this is the maintainer's
problem and that they must do something about it. If it bothers you,
you should yourself do the work to improve matters.

> I think it depends on the situation. I've looked at the open and
> forwarded bugs reported under this email address and of the 60, there
> are at least 47 that I could immediately determine (just by being
> reminded of the Subject line) that included a testcase or a patch or
> were trivially easy to reproduce (or understand wrt the desired feature
> for wishlist requests). Those are pretty much forward-and-forget.

If you think the work of forwarding bugs upstream is so important and
useful - more important and useful than the work that you are
currently doing - then perhaps you would like to take on that role for
some existing maintainers who don't have the time, or who feel that it
isn't tha valuable ?

> So I think what my position is is this: if the bug is simple, clear, and
> easily understandable, then I don't think it's unreasonable for the
> maintainer to forward the bug upstream. Examples that I think fit into
> this category:

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.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 19757.56664.836061.356874@chiark.greenend.org.uk"> http://lists.debian.org/19757.56664.836061.356874@chiark.greenend.org.uk
 
Old 01-12-2011, 04:25 PM
Ben Hutchings
 
Default Forwarding bugs upstream

On Wed, Jan 12, 2011 at 02:56:35PM +0000, brian m. carlson wrote:
[...]
> Also, if the BTS won't CC me when someone responds
> to the bug (even with an account), there is zero chance of me reporting
> the bug upstream, since I have better things to do with my life than
> constantly checking a slew of BTSes.
[...]

The bts-link system takes care of polling for upstream bug status
updates for several common bug trackers.

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110112172550.GU3702@decadent.org.uk">http://lists.debian.org/20110112172550.GU3702@decadent.org.uk
 
Old 01-12-2011, 08:52 PM
"Jess M. Navarro"
 
Default Forwarding bugs upstream

Hi, Sune:

On Wednesday 12 January 2011 14:27:23 Sune Vuorela wrote:
> On 2011-01-11, brian m. carlson <sandals@crustytoothpaste.net> wrote:
> > I've noticed a trend lately that I am often asked to forward the bugs I
> > report to the Debian BTS upstream, either by the maintainers or
> > automatically by a bug script. I believe, and I continue to believe,
>
> 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.

> 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.

I've been both sides of the wall (as and end user and as being in charge of
supporting some apps and environments) and here comes my opinion as a "mere
user with some hindsights". I'll try to make my points clear, so if someone
finds them a bit harsh, please understand that it was not my intention, that
my native language is not English and that my aim is mainly make myself as
clear as possible:

From the user point of view:

1) A known operational problem that is still there never should map to a
closed bug, no matter what. That means that "forwarded upstream", while it
might be a valid bug state can't be one meaning "closed". I'm having a
problem so I'm looking at open problems in the bug database. That means that
if there's a problem in, say, Lenny, even if it's demonstrably closed in
Squeeze it should appear opened when I look for bugs in Lenny.

2) The maintainer took over his shoulders some responsibilities when he became
maintainer. When I'm facing a problem with a package in the distribution,
it's you the one that will have to cope with it. You'll take my data and
you'll try to reproduce the bug. If you are able to reproduce the bug, then
it's your problem from now on. If you can't you'll ask me for more data and
will try to hint which data will be more valuable and will explain to me.

3) Corollary of two is that if you are able to reproduce the bug and you deem
it to be an upstream one, you should be the one rising it to upstream and
track it from them on, but since the problem is still there you shouldn't
close the bug (see 1) but mark/tag it as an upstream problem and that you
already are dealing with it with upstream at upstream's XXXX bug number.

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
host a bazillion packages but I really appreciate much more 1/10th of a
bazillion worth of properly maintained packages than a bazillion of half
assed ones. In the first case I know exactly what the situation is, in the
second I don't know if I'm lucky when I see foo already packaged for Debian
or if foo will be one of the less than production-ready ones. It severely
hinders the overall perception about the quality of the project.

5) I as a user should understand that you are not a magician; without enough
data you won't be able to deal with my bug and you will have to close it as
non-reproducible, if I don't feel that to be a good reason I always can go
anywhere else (say, the upstream developer) to see if I'm more lucky there.

6) There will be (rare) cases when the debian maintainer really won't be in a
position of being of help. Then I'll need to understand that, after all,
it's me the one having a problem, not him, so it's in my best interest to
take the time going upstream to see what can be done and make the debian
maintainer (and other who might happen to look at the bug records) know about
that.

7) Tracking bugs is always a burden so don't expect too much from somebody
doing it for free. Try to be helpful since it's in your best interest, say
thanks with open spirit and, please, take the time to introduce a workaround
or the solution you found in the bug system so others can benefit out of it
and the debian maintainer can dedicate his time to something more productive.

From the maintainer point of view:

1) An unreproducible bug is an unexistant bug. It's valid for unexistant bugs
not to show in an open bugs list so you are free to close them with a
non-reproducible message. If nine out of ten bug reports lack enough data,
ask for better data and advise that without new data you won't be able to
reproduce the bug so it will be closed in a decent amount of time (say, two
weeks? one month?) and then you'll be free to close nine out of ten bugs
right away, so more time to deal with the valid ones.

2) If you feel it's probably an upstream bug you can't reproduce because
there's not enough data not because the user lacks the will to produce it to
you but because you don't know the inners of the program good enough to ask
for meaninful info, it is still your burden to communicate to upstream and
act as a man-in-the-middle at least till you convince yourself it won't be
reproducible, in which case you'll tag as it and/or collect enough evidence
as to ask the end user to go upstream if he so likes under the condition that
he will inform you of the upstream's bug number so you can track it. If the
end user produces for you a bug number, then you'll tag yours as forwarded
upstream and you will take the time to track it. If the end-user doesn't
produce the bug number in proper time (again, two weeks? one month?) you'll
close yours as non-reproducible and done with it.

3) Always leave space for alternatives and exceptions. If you deal with a
knowledgeable user and you feel you'll get in the middle instead of being of
help, certainly you can point the user to the upstream developer asking for
the bug number to track it. Tag the bug with the upstream bug no. and if you
are able to reproduce it, give your help on the upstream's bug system to both
your user and the upstreamer.

4) Always be proud of your work but make sure you make what it takes to be
able to be proud of your work.

Cheers.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201101122252.51506.jesus.navarro@undominio.net">ht tp://lists.debian.org/201101122252.51506.jesus.navarro@undominio.net
 
Old 01-12-2011, 10:12 PM
Sune Vuorela
 
Default Forwarding bugs upstream

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.

>> 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?

> 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
- ...

And who do you think should step up ?

/Sune


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: slrniisda6.rvp.nospam@sshway.ssh.pusling.com">http ://lists.debian.org/slrniisda6.rvp.nospam@sshway.ssh.pusling.com
 
Old 01-12-2011, 10:16 PM
Ben Finney
 
Default Forwarding bugs upstream

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> 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.

Indeed, the Debian project can't demand or require any work of anyone. I
think it's perfectly acceptable for any such volunteer to refuse to do
the work.

But if they do refuse, then to what extent is that person accomplishing
the maintainer role?

--
“All progress has resulted from people who took unpopular |
` positions.” —Adlai Stevenson |
_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: 87fwsxd86t.fsf@benfinney.id.au">http://lists.debian.org/87fwsxd86t.fsf@benfinney.id.au
 
Old 01-12-2011, 10:33 PM
Olaf van der Spek
 
Default Forwarding bugs upstream

On Thu, Jan 13, 2011 at 12:12 AM, Sune Vuorela <nospam@vuorela.dk> wrote:
>> 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.

That's better than no response to a bug report at all.

Olaf


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTi=iiVsNRcCEw4V_p-c_faho6ArOfRGFdbT8=ou6@mail.gmail.com">http://lists.debian.org/AANLkTi=iiVsNRcCEw4V_p-c_faho6ArOfRGFdbT8=ou6@mail.gmail.com
 
Old 01-12-2011, 10:35 PM
Russ Allbery
 
Default Forwarding bugs upstream

Ben Finney <ben+debian@benfinney.id.au> writes:

> Indeed, the Debian project can't demand or require any work of anyone. I
> think it's perfectly acceptable for any such volunteer to refuse to do
> the work.

> But if they do refuse, then to what extent is that person accomplishing
> the maintainer role?

I feel like it's rare for any of us, and I'm definitely including myself,
to completely accomplish the maintainer role. There's always more work
that I could be doing: bugs that are still open, things that could be
improved, project-wide updates that need attention, etc. While it's
useful to have an idea of that to-do list, I'm not sure it's useful to
beat oneself or others up about not completely accomplishing everything we
want to do as maintainers. This is a volunteer project, after all (and
even in a non-volunteer project, tasks would be prioritized and some
wouldn't get done because they just weren't high enough priority).

What I think many people are saying in this thread is that, among all the
things that a Debian package maintainer could do to improve the package
and user experience of those using the package, being a go-between for
Debian bug reporters and upstream is something they consider low priority.
It may be something they'd be willing to do if they have free time after
doing other work, or it may be so low-priority that it's below the
threshold of work they're willing to volunteer for, but either way it's
just less important than other things that need doing and therefore will
often go undone.

That seems like a reasonable position to take to me.

I think the question of to what extent a person is accomplishing a
maintainer role is really only a useful question to ask project-wide, in
places like debian-devel (as opposed to personally, when deciding what one
wants to take on) if we're considering either replacing the maintainer or
booting the package for not being properly maintained. I have a hard time
imagining not forwarding bugs upstream to rise to the level of undone
tasks to warrant contemplating either of those actions in most cases.

Note that most of the push-back against the work of forwarding bugs
upstream is from maintainers of huge packages like X, GNOME, or the
kernel, teams that have been begging for help for years. We're obviously
not going to kick those packages out of the archive, and we're obviously
not going to replace the existing maintainers given that the problem we're
having is no one volunteering to be a maintainer (and hence no one else is
going to do a better job than the people who are already working on those
packages). So there doesn't seem to be much point in discussing things
from that angle.

--
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: 874o9du24c.fsf@windlord.stanford.edu">http://lists.debian.org/874o9du24c.fsf@windlord.stanford.edu
 
Old 01-12-2011, 10:59 PM
Ben Finney
 
Default Forwarding bugs upstream

Russ Allbery <rra@debian.org> writes:

> What I think many people are saying in this thread is that, among all
> the things that a Debian package maintainer could do to improve the
> package and user experience of those using the package, being a
> go-between for Debian bug reporters and upstream is something they
> consider low priority. It may be something they'd be willing to do if
> they have free time after doing other work, or it may be so
> low-priority that it's below the threshold of work they're willing to
> volunteer for, but either way it's just less important than other
> things that need doing and therefore will often go undone.
>
> That seems like a reasonable position to take to me.

And to me. None of that argues against the maintainer role entailing
that work, though.

> So there doesn't seem to be much point in discussing things from that
> angle.

Right. My point with raising it was merely to show that it goes both
ways: there's not much point saying “you have to do the work”, just as
there's not much point saying “nobody can force me to do anything”.
Either of those simply polarises the discussion, which is not helpful.

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.

To argue that is *not* to require or demand that anyone do any work, nor
to strip anyone of their role. I wish I knew how to avert the seemingly
inevitable charges of that which arise any time we discuss what the
maintainer role entails.

--
“When I was a kid I used to pray every night for a new bicycle. |
` Then I realised that the Lord doesn't work that way so I stole |
_o__) one and asked Him to forgive me.” —Emo Philips |
Ben Finney


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 878vypd66r.fsf@benfinney.id.au">http://lists.debian.org/878vypd66r.fsf@benfinney.id.au
 

Thread Tools




All times are GMT. The time now is 11:39 PM.

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