[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposing a new source control header to link to upstream BTSs

(reply-to as requested)

On Mon, Mar 17, 2008 at 5:45 AM, Bas Wijnen <wijnen@debian.org> wrote:

>  > It could be used to automatically forward bugs,
>  I don't think bugs should be forwarded automatically.

See my previous mail, I did choose the wrong word here.

>  > track which bugs are open that we don't know about today,
>  This would indeed be useful, but if automated tools should be using it
>  (like DEHS), a lot of work is needed to parse all those bug systems.  If
>  there's a prospect that this work will be done in the near future, then
>  I agree that the fields would be useful.

I thought about the proposal because I'd like to add this kind of
information to the package tracking tool used in pkg-perl (and some
other groups) [0], of course I know I have to write the parsers :).
Parsing RT and (source|g)forge already covers 99.9% of pkg-perl

>  > and simply to avoid the need to look up manually where should one
>  > submit a bug.

>  This is the main reason I dislike the idea.  Users shouldn't need to
>  submit bugs upstream.  They use Debian, they submit bugs to Debian, and
>  if Debian (by means of the maintainer) thinks it's an upstream issue,
>  Debian forwards it to them.

No, of course this is not intended for users, but for Debian
developers/maintainers/etc. We already have the watch file, which can
be related to this idea.

>  Given this position, you probably understand that I don't think
>  providing a link to the upstream BTS is very useful for the users.

I agree completely on that premise. But then again, users also don't
care about where we host our pakcages' VCS repositories.

>  It may be interesting information in case the maintainer goes MIA, or
>  something.  Most of the time, Homepage should be enough to find it out,
>  though.  If not, I think it would be good practise to write it in the
>  package somewhere, but I don't think the control file is a good place
>  for it.  Especially given the very minimal amount of packages where
>  Homepage doesn't provide the information (and for those cases, upstream
>  is probably dead, so there isn't really anything useful to say either).

It is true that having the homepage you can easily find the bug
tracker, but I'm aiming at a different goal that what I thing you
understood, which is enabling us to write more tools that help _us_.

[0]: http://pkg-perl.alioth.debian.org/cgi-bin/qareport.cgi

Martín Ferrari

Reply to: