On Fri, 16 Sep 2011, Lars Wirzenius wrote:
> On Thu, Sep 15, 2011 at 06:47:52PM -0700, Don Armstrong wrote:
> > I am looking for a set of perl modules which can handle being fed mail
> > and managing a subscription list in response to that mail while also
> > allowing for subscriptions/unsubscripti
On Sep 15, 2011, at 06:47 PM, Don Armstrong wrote:
>On Wed, 14 Sep 2011, Barry Warsaw wrote:
>> Can you provide a bit more detail on this?
>
>I am looking for a set of perl modules which can handle being fed mail
>and managing a subscription list in response to that mail while also
>allowing for s
On Thu, Sep 15, 2011 at 06:47:52PM -0700, Don Armstrong wrote:
> I am looking for a set of perl modules which can handle being fed mail
> and managing a subscription list in response to that mail while also
> allowing for subscriptions/unsubscriptions from an external interface.
> Such a thing may
On Wed, 14 Sep 2011, Barry Warsaw wrote:
> On Sep 13, 2011, at 04:48 PM, Don Armstrong wrote:
>
> >The main thing that is blocking me from implementing it currently is a
> >set of perl modules which can handle the hard bit of managing a
> >mailing list correctly so I don't have to write them from
On Tue, 13 Sep 2011 15:14:33 +0200, Stefano Zacchiroli wrote:
> Steve suggested a feature that might improve the status quo:
I like the idea.
> - enable people to subscribe to bug traffic only if it matches specific
> tags (the idea being of forwarding upstream only the traffic for
> "confi
On Wed, Sep 14, 2011 at 02:06:39PM +0200, Bernd Zeimetz wrote:
> even if upstream is interested in bug reports (may be even in all of
> them) - it is not that easy to figure out how to subscribe to the bug
> mails of a package. We should make it easier for upstreams to subscribe
> to bts mails. May
On Sep 13, 2011, at 04:48 PM, Don Armstrong wrote:
>The main thing that is blocking me from implementing it currently is a
>set of perl modules which can handle the hard bit of managing a
>mailing list correctly so I don't have to write them from scratch.
Can you provide a bit more detail on this
Hi,
> status quo
> -
> *If upstream is aware of the option*, they can choose to be advised of
> all bugs or none.
>
> This gives upstream some control, and protects downstream from
> accusations of spamming, since upstream has to subscribe to mailings.
>
> But it's all-or-nothing. I
ble with such an arrangement.
Cheers!
--
On Tue, Sep 13, 2011 at 3:14 PM, Stefano Zacchiroli wrote:
> After GHM [1], I've head a lengthy discussion with Steve White (Cc:-ed,
> GNU maintainer [upstream]) about Debian's procedures for forwarding bugs
> upstream.
>
> [
On Tue, 13 Sep 2011, Gergely Nagy wrote:
> Stefano Zacchiroli writes:
>
> > Steve suggested a feature that might improve the status quo:
> >
> > - enable people to subscribe to bug traffic only if it matches specific
> > tags (the idea being of forwarding upstream only the traffic for
> > "c
Quoting Stefano Zacchiroli (z...@debian.org):
> After GHM [1], I've head a lengthy discussion with Steve White (Cc:-ed,
> GNU maintainer [upstream]) about Debian's procedures for forwarding bugs
> upstream.
>
> [1] http://lists.debian.org/debian-project/2011/09/msg4
On 09/13/2011 03:14 PM, Stefano Zacchiroli wrote:
> - enable people to subscribe to bug traffic only if it matches specific
> tags (the idea being of forwarding upstream only the traffic for
> "confirmed" bugs)
>
> - add a DELAYED-like mechanism where upstream is notified of a bug only
> if
Stefano Zacchiroli writes:
> Steve suggested a feature that might improve the status quo:
>
> - enable people to subscribe to bug traffic only if it matches specific
> tags (the idea being of forwarding upstream only the traffic for
> "confirmed" bugs)
I'd love this, even with having only my
After GHM [1], I've head a lengthy discussion with Steve White (Cc:-ed,
GNU maintainer [upstream]) about Debian's procedures for forwarding bugs
upstream.
[1] http://lists.debian.org/debian-project/2011/09/msg4.html
The conversion touched the usual suspects:
- Debian is committed
Hi, Olaf:
On Thursday 20 January 2011 09:51:27 Olaf van der Spek wrote:
> On Wed, Jan 19, 2011 at 9:27 AM, Nikita V. Youshchenko
wrote:
> > Then, maybe explicitly request upstream - at appropriate forums and in
> > appropriate polite wording - to help debian team(s) to handle the bug
> > report
On Wed, Jan 19, 2011 at 9:27 AM, Nikita V. Youshchenko wrote:
> Then, maybe explicitly request upstream - at appropriate forums and in
> appropriate polite wording - to help debian team(s) to handle the bug
> report stream?
I think upstream has the same problem in some cases: too many bug reports
Hi
After reading this thread, I've got a strange thought.
So teams maintaining important projects in Debian can't handle the load
caused by bug report stream.
Large presentange of bugs actually as upstream bugs. If so, upstream should
be interested in that information non less than in any oth
On Wed, 12 Jan 2011 13:27:23 + (UTC), Sune Vuorela
wrote:
>On 2011-01-11, brian m. carlson 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 c
"Jesús M. Navarro" 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 til
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
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 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
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 packagin
On Fri, Jan 14, 2011 at 9:27 AM, Stefano Zacchiroli wrote:
> On Fri, Jan 14, 2011 at 11:29:58AM +, 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
> distr
On Thu, 13 Jan 2011 10:27:12 +, Sune Vuorela wrote:
> On 2011-01-13, Felipe Sateler 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 prope
On Thu, 13 Jan 2011 00:38:37 +, Ian Jackson wrote:
> Felipe Sateler writes ("Re: Forwarding bugs upstream"):
>> On Wed, 12 Jan 2011 16:56:56 +, Ian Jackson wrote:
>> > I think it is always reasonable for the maintainer to forward the bug
>> > upstrea
On Fri, Jan 14, 2011 at 11:29:58AM +, 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
On Fri, Jan 14, 2011 at 12:51 PM, Alexander Reichle-Schmehl
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.o
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 [..] reque
Le jeudi 13 janvier 2011 à 11:54 +0100, Olaf van der Spek a écrit :
> Instead of stepping down, it might be better to ask for a co-maintainer.
I hereby request a new co-maintainer for the GNOME packages.
--
.''`.
: :' : “You would need to ask a lawyer if you don't know
`. `' that a h
On 2011-01-14, Iker Salmón San Millán wrote:
> 2011/1/14 Sune Vuorela
>
>>
>> Hi Andreas. Would you like to be delegated to help reporting bugs in
>> packages maintained by Qt/KDE team upstream?
>>
>> /Sune
>>
>>
> I would be glad if i could help you in that (or any) way sune.
> Unfortunately mi
As new (sponsored) mantainer i have a few things to say about this thread.
First of all. If i receive a bug report, i do my best to handle it in the
rigth way, i am in contact with upstream author and fortunately i have no
bugs in my package. I personally don't care to forward bugs to upstream.
Bu
Hi, Peter:
On Friday 14 January 2011 10:29:57 Peter Samuelson wrote:
> [Jesús M. Navarro]
>
> > 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.
>
> You didn't read the rest of the thread, did you?
Yes I did.
On Fri, Jan 14, 2011 at 08:43:36AM +, Sune Vuorela wrote:
> On 2011-01-13, Andreas Tille wrote:
> > In short: The Debian maintainer is responsible that a bug will be
> > reported upstream. I don't see a problem if he delegates the actual
> > work to somebody else who is able and willing to do
[Jesús M. Navarro]
> 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.
You didn't read the rest of the thread, did you?
> If you understand what I said, good; if you didn't, please, make me
> the honour of cons
[Jesús M. Navarro]
> > 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
> >
On 2011-01-13, Andreas Tille wrote:
> In short: The Debian maintainer is responsible that a bug will be
> reported upstream. I don't see a problem if he delegates the actual
> work to somebody else who is able and willing to do the job (but please
> be nice to the user when asking for this kind o
Andreas Tille writes:
> In short: The Debian maintainer is responsible that a bug will be
> reported upstream. I don't see a problem if he delegates the actual
> work to somebody else who is able and willing to do the job (but
> please be nice to the user when asking for this kind of help). Free
Hi, Andreas:
On Thursday 13 January 2011 09:19:35 Andreas Tille wrote:
[...]
> In short: The Debian maintainer is responsible that a bug will be
> reported upstream. I don't see a problem if he delegates the actual
> work to somebody else who is able and willing to do the job (but please
> be ni
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 Debia
Hi, Sune:
On Thursday 13 January 2011 00:12:06 Sune Vuorela wrote:
> On 2011-01-12, Jesús M. Navarro 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.
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 m
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
On Thu, Jan 13, 2011 at 02:46:35PM +, 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 th
John Goerzen 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 (f
Olaf van der Spek 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
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 fo
Zitat von "Ansgar Burchardt" :
Sune Vuorela writes:
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.
The rest of the bugs (780 open-non forwarded (and 300
Package: debbugs
Severity: wishlist
Tags: help
On Thu, 13 Jan 2011, Ian Jackson wrote:
> Don Armstrong writes ("Re: Forwarding bugs upstream"):
> > I personally would love to see patches to the BTS to enable forwarding
> > these kinds of bug reports to upstreams
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 mayb
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 lif
Olaf van der Spek writes ("Re: Forwarding bugs upstream"):
> The point is focus on solving bugs shouldn't be limited to BSPs and
> the end of the release cycle.
No, Stefano's point was that if you want something done, you should go
and do it rather than whining her
Don Armstrong writes ("Re: Forwarding bugs upstream"):
> I personally would love to see patches to the BTS to enable forwarding
> these kinds of bug reports to upstreams more easily and integrate
> everything tightly with the BTS. Unfortunately, I am perpetually short
> of
On Thu, 13 Jan 2011, Ben Finney wrote:
> But if they do refuse, then to what extent is that person
> accomplishing the maintainer role?
To the greatest extent they can, which is what all of us do. I don't
believe any maintainer is going to stand in the way of anyone who
wants to help triage their
Sune Vuorela writes:
> 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.
> The rest of the bugs (780 open-non forwarded (and 300 forwarded)) is
> pure upst
On Thu, Jan 13, 2011 at 2:25 PM, Stefano Zacchiroli wrote:
> On Thu, Jan 13, 2011 at 02:03:07PM +0100, Olaf van der Spek wrote:
>> > Remember: there is no shortage of bug reports.
>>
>> That's unfortunately true. Why is it that bug squashing parties only
>> happen a short time before release while
On Thu, Jan 13, 2011 at 02:03:07PM +0100, Olaf van der Spek wrote:
> > Remember: there is no shortage of bug reports.
>
> 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?
Pl
On Thu, Jan 13, 2011 at 1:40 PM, Ian Jackson
wrote:
> Remember: there is no shortage of bug reports.
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?
--
Olaf
--
To UNSUBSC
Ben Finney writes ("Re: Forwarding bugs upstream"):
> Ian Jackson writes:
> > But if a maintainer tells me "please go and talk to them yourself" or
> > even "please stop filing these kind of upstream bugs in Debian - you
> > know how to do it you
Bernhard R. Link writes ("Re: Forwarding bugs upstream"):
> The maintainer should of course assess where their work is best invested
> and act accordingly.
>
> But a package where bug reports to Debian are not properly handled or
> users are required[1] to report them el
* Ian Jackson [110113 01:54]:
> > 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
On Thu, Jan 13, 2011 at 11:27 AM, Sune Vuorela wrote:
> On 2011-01-13, Felipe Sateler 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 jo
On 2011-01-13, Felipe Sateler 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.
Now we just need to define what a proper job is.
/Sune
--
On Thu, Jan 13, 2011 at 10:59:40AM +1100, Ben Finney wrote:
> Russ Allbery writes:
I really like Russ Allbery's sane words about this topic.
> 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
> ine
Olaf van der Spek writes ("Re: Forwarding bugs upstream"):
> Maybe some tools (PTS) should warn about bugs that are older than X
> days and are still unclassified?
That's just a way to make more noise. They show up in the BTS
searches already.
Ian.
--
To UNSUBSCRIBE,
Ian Jackson writes:
> As I understand it we are not in danger of having infrastructure
> capacity problems at the BTS due to these bugs, and the maintainers
> who think they are a very low priority don't want to see them can
> easily arrange that with the pretty sophisticated filtering and
> sear
On Thu, Jan 13, 2011 at 1:38 AM, Ian Jackson
wrote:
> 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
Felipe Sateler writes ("Re: Forwarding bugs upstream"):
> On Wed, 12 Jan 2011 16:56:56 +, 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 _requiri
Olaf van der Spek writes ("Re: Forwarding bugs upstream"):
> On Thu, Jan 13, 2011 at 12:12 AM, Sune Vuorela wrote:
> >> Will this mean that the problem will somehow disappear from
> >> Debian? Because if it's a problem detected within Debian it's my
>
On Wed, 12 Jan 2011 16:56:56 +, 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 t
Russ Allbery 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
ces 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
ta
On Thu, Jan 13, 2011 at 12:12 AM, Sune Vuorela 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 i
Ian Jackson 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
On 2011-01-12, Jesús M. Navarro 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? Be
Hi, Sune:
On Wednesday 12 January 2011 14:27:23 Sune Vuorela wrote:
> On 2011-01-11, brian m. carlson 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 believ
On Wed, Jan 12, 2011 at 02:56:35PM +, 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
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
>
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 addi
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 packa
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 t
On 2011-01-11, brian m. carlson 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 furthe
Drake Wilson, 2011-01-11 20:19:34 -0700 :
[...]
> This doesn't leave much in the way of good options:
>
> - Having the user report bugs twice
[...]
> - Having the maintainer be the reporter of record for upstream
[...]
> - Having the maintainer forward the bug report but make the user the
>
* Drake Wilson [2011-01-12 08:09] wrote:
> Quoth Paul Wise , on 2011-01-12 10:55:34 +0800:
> [among other responses]
> > Sourceforge and probably Gforge/FusionForge trackers.
> >
> > The only tracker I'm aware of which would work is Trac, some instances
> > of which allow anyone to put in anyone
Le mardi 11 janvier 2011 à 23:54 +, brian m. carlson a écrit :
> 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,
> that maintainers
On Mi, 12 ian 11, 10:55:34, Paul Wise wrote:
> On Wed, Jan 12, 2011 at 9:29 AM, Drake Wilson wrote:
>
> > Which upstream bug trackers, if any, would make the above not work?
>
> Sourceforge and probably Gforge/FusionForge trackers.
>
> The only tracker I'm aware of which would work is Trac, som
> 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
On 12 January 2011 14:15, John Goerzen wrote:
> 8) This continues.
For what it is worth, I generally will ask the submitter to use the
upstream bug tracking system if there is any dispute or problems with
the bug report. Sure, this isn't ideal, but seems to me to be a
compromise between getting t
John Goerzen writes:
> Now, here's how it proceeds if I have to forward a bug upstream for
> Bacula, which uses Mantis. Creating a Mantis account takes 30
> seconds
I don't know Brian's position on this, but “time to create an account
with arbitrary upstream BTS” isn't the issue.
“Having an ac
On 01/11/2011 05:54 PM, brian m. carlson 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,
that maintainers should forward bugs upstre
(Woopsy, forgot to send to the list the first time.)
Quoth Paul Wise , on 2011-01-12 10:55:34 +0800:
[among other responses]
> Sourceforge and probably Gforge/FusionForge trackers.
>
> The only tracker I'm aware of which would work is Trac, some instances
> of which allow anyone to put in anyone
On Wed, Jan 12, 2011 at 9:29 AM, Drake Wilson wrote:
> Which upstream bug trackers, if any, would make the above not work?
Sourceforge and probably Gforge/FusionForge trackers.
The only tracker I'm aware of which would work is Trac, some instances
of which allow anyone to put in anyone else's e
On Tue, 2011-01-11 at 18:29 -0700, Drake Wilson wrote:
> Quoth Cyril Brulebois , on 2011-01-12 01:59:03 +0100:
> > > If a bug is not readily reproducible or isolatable, it may be
> > > necessary to pass it over to an upstream maintainer who will know
> > > what further questions to ask. But they n
Quoth Cyril Brulebois , on 2011-01-12 01:59:03 +0100:
> > If a bug is not readily reproducible or isolatable, it may be
> > necessary to pass it over to an upstream maintainer who will know
> > what further questions to ask. But they need to send those
> > questions to the user, not to the Debian
"brian m. carlson" writes:
> 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,
> that maintainers should forward bugs upstream instead of
Ben Hutchings (12/01/2011):
> If a bug is not readily reproducible or isolatable, it may be
> necessary to pass it over to an upstream maintainer who will know
> what further questions to ask. But they need to send those
> questions to the user, not to the Debian maintainer. In the kernel
> team
On Tue, 2011-01-11 at 23:54 +, brian m. carlson 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,
> that maintainers should fo
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,
that maintainers should forward bugs upstream instead of requiring (or
strongly encouraging)
97 matches
Mail list logo
