Re: Minutes from the DPG meeting @DebConf9, 2009-07-18
On Sun, Jul 19, 2009 at 22:51, Damyan Ivanov<dmn@debian.org> 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
latest bugs.
> So suggestions are welcome. Please add them to
> http://wiki.debian.org/Teams/DebianPerlGroup/OpenTasks/ChangelogHeaders
> 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[1]? 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[0] with the usual reaction to proposed changes...
> [1] 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
> usefulness.
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
Good! :)
[0]: http://lists.debian.org/debian-devel/2008/03/msg00541.html
--
Martín Ferrari
Reply to: