-=| Martín Ferrari, Sun, Jul 19, 2009 at 09:00:36PM +0200 |=-
> > stale WiP
> > - PET section or a cron job reporting to the list?
>
> 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.
Anyway, Gregor has added the notion of stale new WiP packages in PET.
C-o-o-l!
> > - changelog header standard?
>
> what was discussed about this? I'd vote in favor of specifying some
> "official" tags or headers to use
What we decided is that "officially blessed" headers would be nice.
What we didn't is how they should look like.
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.
> > pathces in need to be forwarded
> > - requires headers to be properly filled (DEP3 may need some push)
> > - we need a tool that lists patches that need to be forwarded
> > - some way to easier edit patch headers without risking getting the
> > header wrong (visudo-like)
> > - also a helper function for forwarding the patch upstream (providing
> > a template mail or whatever)
> > - volunteers needed
>
> 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.
[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?
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.
> > next meeting
> > - booked by gwolf at 23:00 on 2009-07-26 in the lower talk room
>
> I'll be there!!
>
> See you next Saturday, foilks!
We have the beer cooling :D
--
dam
Attachment:
signature.asc
Description: Digital signature