Re: Minutes from the DPG meeting @DebConf9, 2009-07-18
On Sun, Jul 19, 2009 at 22:51, Damyan Ivanov<email@example.com> wrote:
>> I'd say that PET can effectively override many mails and is much less
>> noise in the list. The same could be said of many other mails we
>> receive, like archive notifications, testing migration, and even bug
>> reports. Not that I'm active now, but I been consistently deleting
>> most of that stuff since is easier to me to see the report.
> I agree to all of this, except of the bug reports. How would you
> notice there is a new bug reported? We just have too many packages
> with bugs so looking on that list and discovering a new bug is not
> very likely.
That's true, but rc bugs already pop up prominently. Maybe it would be
nice to add more reports to PET (a separate CGI) to list things like
> So suggestions are welcome. Please add them to
> We can use the input for deciding in a week.
OK, will take a look.
>> About all of this, again it shows the usefulness of having fields in
>> d/control that allow the tools to automatically do things like talking
>> with upstream bug trackers.
> XS-Upstream-Bug-Tracker? These would be rt.cpan.org for most of the
> packages. Unfortunately some of the upstreams hate RT. Whoever goes
> and adds that header please try to detect these.
I think we discussed this at some point, and I've even sent an email
to debian-devel with the usual reaction to proposed changes...
>  is there a way to put a header in debian/control that won't end
> up neither in the source package nor in the binary packages? Or
> do we want this to end up in the source package?
Tthe only way would be to actually modify the control file during
build, which I find totally evil. Anyway, I think it is useful there,
as that information can be used even without a repository checkout.
> Still, the tool shouldn't forward patches blindly, without user
> interaction. reportbug is a good example here: first browse existing
> bugs, then go on and report a new one. Covering all possible bug
> trackers won't be easy, but starting with rt.cpan.org will be of great
Of course not, sorry if I didn't make it clear. The idea is to
automate boring tasks, like finding the patches to forward and
manually entering them on each (possibly different) bug tracker. A
human will still be needed to start the action.
> We have the beer cooling :D