Bug#551386: Per-package link to upstreams bugtracker

[Joachim Breitner]

Package: bugs.debian.org
Severity: wishlist

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

just an idea that occured to me right now when filing a bug against a
package where I already know that it’s an upstream bug, but I don’t want
to spend time finding out
 * where the upstream bugtracker is
 and
 * how to properly list all upstream bugs.

Therefore, I’d find it handy to have, on the header of the package’s bug
page a link "Search upstream bugtracker" that directly sends me to the
upstream bugtracker, ideally to a search request for all bugs affecting
this particular program/component.


Implementation-wise, this is probably best implemented via a new
control header, similar to Homepage, containing the URL. But of course
I’m open for other ideas.

Greetings,
Joachim

- -- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkraNtEACgkQ9ijrk0dDIGxmmQCfX0q7b2Huz0XYpaN3IWNLRheG
OLQAn1uhzqu2E4aveAAP3+ru6eg/LaRo
=cEsf
-----END PGP SIGNATURE-----



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Don Armstrong]

tag 551386 moreinfo help
thanks

On Sat, 17 Oct 2009, Joachim Breitner wrote:
> Therefore, I'd find it handy to have, on the header of the package's
> bug page a link "Search upstream bugtracker" that directly sends me
> to the upstream bugtracker, ideally to a search request for all bugs
> affecting this particular program/component.

Once someone has implemented a table in some format that the BTS can
understand, I've no problem implementing this in the BTS. I'm just not
going to be able to drive the process of generating these links.

It'd also be nice if along with links to upstream BTSes, an optional
link to a wiki page on wiki.debian.org about package specific
bug-reporting information could also be included. (In such a page,
more links to upstream mailing lists or debugging resources could be
provided.)


Don Armstrong

--
I learned really early the difference between knowing the name of
something and knowing something
 -- Richard Feynman "What is Science" Phys. Teach. 7(6) 1969

http://www.donarmstrong.com              http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[gregor herrmann-3]

On Sat, 17 Oct 2009 23:27:45 +0200, Joachim Breitner wrote:

> Therefore, I’d find it handy to have, on the header of the package’s bug
> page a link "Search upstream bugtracker" that directly sends me to the
> upstream bugtracker, ideally to a search request for all bugs affecting
> this particular program/component.

I agree, and we had a similar discussion during Debconf in the Debian
Perl Group. [0]

> Implementation-wise, this is probably best implemented via a new
> control header, similar to Homepage, containing the URL. But of course
> I’m open for other ideas.

In order not to bloat the Packages file we where thinking about a
header in debian/copyright (which has, according to DEP5, already
information about the Upstream-Author and Upstream-Source).

But there may be other and better places to put the information.

Cheers,
gregor

[0]
http://lists.debian.org/debian-perl/2009/07/msg00104.html
--
 .''`.   http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-    NP: Cat Stevens: Bitter Blue

[Paul Wise-3]

On Sun, Oct 18, 2009 at 6:23 AM, gregor herrmann <gregoa@...> wrote:
> On Sat, 17 Oct 2009 23:27:45 +0200, Joachim Breitner wrote:
>
>> Implementation-wise, this is probably best implemented via a new
>> control header, similar to Homepage, containing the URL. But of course
>> I’m open for other ideas.
>
> In order not to bloat the Packages file we where thinking about a
> header in debian/copyright (which has, according to DEP5, already
> information about the Upstream-Author and Upstream-Source).

I'd like to re-iterate my earlier mail on this subject about splitting
up the Packages file:

http://lists.debian.org/debian-devel/2009/08/msg00057.html

I heard a rumor that the Description fields were going to be split out
into Translation-en files and I'd like this trend to continue.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Marschke]

> I'd like to re-iterate my earlier mail on this subject about splitting
> up the Packages file:
>
> http://lists.debian.org/debian-devel/2009/08/msg00057.html
>
> I heard a rumor that the Description fields were going to be split out
> into Translation-en files and I'd like this trend to continue.
 
I think that this idea is quite good, too. But in my view it seems a little
hard to really make out a date at that the proposed changes to the way
packaging currently works would be really applied.
I 'm thinking here of following problems that we might come to by realizing
such a thing:

        (1) Lintian apt and dpkg would have to be updated acchordingly and would eat  
              up a lot of manpower getting to this point.
        (2) It would need a date to begin and end to switch/transfer the packages
              from one model to another.
        (3) Other Distributions using Debian as their base would have to wait
              untill all the pieces are collected which would make it a mess to keep
              in their timed releases.
        (4) by the time the new packaging rules/forms start to apply Documentation
              and Translation would need to be in place so  that all packagers that
              depend on it can start applying changes to their packages.

Looking at these facts I see that its possible that the next release after
squeeze or the time untill would be the best time to organize and plan such
things. It would be nice to hear one of the  head developers of lintian or apt
on this case. They have to do the first/hardest part right?


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[gregor herrmann-3]

On Sun, 18 Oct 2009 10:23:02 +0800, Paul Wise wrote:

> > In order not to bloat the Packages file we where thinking about a
> > header in debian/copyright (which has, according to DEP5, already
> > information about the Upstream-Author and Upstream-Source).
> I'd like to re-iterate my earlier mail on this subject about splitting
> up the Packages file:
> http://lists.debian.org/debian-devel/2009/08/msg00057.html

Good point.

Another approach would be to make some of our tools more VCS-aware
(or UDD-aware if UDD imports data from VCSses).
 
Cheers,
gregor
--
 .''`.   http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-    NP: Spider Murphy Gang: Sch-Bum ('s Leb'n is wiar a Traum)

[Charles Plessy-12]

Le Sun, Oct 18, 2009 at 02:34:24PM +0200, gregor herrmann a écrit :

> On Sun, 18 Oct 2009 10:23:02 +0800, Paul Wise wrote:
>
> > > In order not to bloat the Packages file we where thinking about a
> > > header in debian/copyright (which has, according to DEP5, already
> > > information about the Upstream-Author and Upstream-Source).
> > I'd like to re-iterate my earlier mail on this subject about splitting
> > up the Packages file:
> > http://lists.debian.org/debian-devel/2009/08/msg00057.html
>
> Another approach would be to make some of our tools more VCS-aware
> (or UDD-aware if UDD imports data from VCSses).

For my packages, I am preparing to test the following workflow: store the
upstream metadata in YAML format in the source package, and make some tools
aware of the content of the file as it is in the VCS containing the source
package. In the Debian Med team we need a mechanism to indicate registration
pages to our users. I have not yet figured out if the best is a spider
mechanism, where the tool checks the file from time to time, or a push
mechanism, with a proper commit hook that will advertise that the changes.

Whichever the implementation, if we manage to move out metadata from
debian/control, it means that we will probably expand the fields a lot. How
about briefly documenting them on a wiki page to avoid collisions?

Lastly, a radically different solution would be to centralise everything in a
big monolithic file, and give commit access to all DDs for instance. That would
also completely untie the update of upstream metadata from package upload, and
if the file is managed in a VCS, it would be easy to revert mistakes and find
misusers, if somebody ever dares.

Have a nice day

--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Joachim Breitner]

Hi,

Am Montag, den 19.10.2009, 11:20 +0200 schrieb Olivier Berger:

> Le samedi 17 octobre 2009 à 23:27 +0200, Joachim Breitner a écrit :
> > just an idea that occured to me right now when filing a bug against a
> > package where I already know that it’s an upstream bug, but I don’t want
> > to spend time finding out
> >  * where the upstream bugtracker is
> >  and
> >  * how to properly list all upstream bugs.
>
> Such information is already used by bts-link to track changes on remote
> bugs linked with the 'forwarded' tag from Debian bugs.
>
> The sources of bts-link ('s configuration file) contain already a
> description of many bugtrackers of source packages.
>
> More details at : http://bts-link.alioth.debian.org/
>
> Hope this helps.

I thought about bts-link as well, of course, but there are some
differences in what is tried to achieve:

bts-link is
 * per-bug.
 * thus can and needs to handle different trackers per package
 * needs manual intervention once (by setting the forwarded field)
 * aim for high-level technical integration.

my proposal is
 * per-package
 * should be present and visible _before_ the user files a bug
 * aims not for technical integration, but just lowering the effort for
   the user to check the upstream bug tracker first

Also, just specifying a simple URL somewhere in the Package file, the
copyright file or somewhere else is sufficiently simple to be actually
implemented :-)

Also note that the information, like Homepage, should be set and stored
in the package first, and not, for example, in a list in the BTS. The
information is everything but Debian-specific and will be valid even
downstream.


I guess this could just be tried out by having early adopters add
XBS-Upstream-BTS: http://bugzilla.gnome.org/...
to some of their packages’ debian/control, add support to
bugs.debian.org, and see how it goes. If it goes well, debian-policy can
be amended and the XBS- prefix dropped. If not, it was worth a try and
did not hurt :-)

@dons: What are your requirements until you will accept this feature on
bugs.d.o, in terms of number of packages or clear consensus on d-devel
or such or actual inclusion in the policy?

Greetings,
Joachim


--
Joachim "nomeata" Breitner
Debian Developer
  nomeata@... | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata@... | http://people.debian.org/~nomeata

[Don Armstrong]

On Mon, 19 Oct 2009, Joachim Breitner wrote:
> @dons: What are your requirements until you will accept this feature on
> bugs.d.o, in terms of number of packages or clear consensus on d-devel
> or such or actual inclusion in the policy?

Depends on the complexity of me actually getting the information to
the bts,[0] but assuming that there's:

1) a clear consensus on the methodology to make/update the links[1]

2) a tab-delineated text file generated somewhere[2] with the source
package name in the first field, the link to the upstream bts in the
second, and the wiki page on wiki.debian.org for additional bug
reporting/triage information in the third

3) enough source packages implementing #1 for me to actually test it;
I imagine if we get at least a half dozen packages from different
maintainers it'll be enough to demonstrate that it's workable.

then I'll shove it into my queue to implement.


Don Armstrong

0: the more complexity, the longer it'll take; the actual code change
to debbugs is relatively trivial.

1: probably a good idea to also have a draft for inclusion in
devel-reference

2: where this is depends on the method, but probably ftpmaster is the
ideal place; dunno, though.

--
Some pirates achieved immortality by great deeds of cruelty or
derring-do. Some achieved immortality by amassing great wealth. But
the captain had long ago decided that he would, on the whole, prefer
to achieve immortality by not dying.
 -- Terry Pratchet _The Color of Magic_

http://www.donarmstrong.com              http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Olivier Berger]

Hi.

Sorry to be late on that discussion (vacation time in between). I'm just
adding a few bits in case it would help.

Le lundi 19 octobre 2009 à 12:54 +0200, Joachim Breitner a écrit :
> Hi,
>

SNIP

> I thought about bts-link as well, of course, but there are some
> differences in what is tried to achieve:
>
> bts-link is
>  * per-bug.

Not exactly as far as the definition of where the upstream bugtracker
lies, which was your concern IIRC.

Even if the forwarded tag is set on individual bugs, it's very much
likely that all those being forwarded to URLs point to the same
bugtracker for all of the bugs filed on the same package. So the
bts-link config file contains references of bugtrackers per packages
IIRC as you can see in :
http://git.debian.org/?p=bts-link/bts-link.git;a=blob;f=btslink.cfg;hb=HEAD

>  * thus can and needs to handle different trackers per package

I'm not sure this is the case actually.

>  * needs manual intervention once (by setting the forwarded field)
>  * aim for high-level technical integration.

SNIP

> Greetings,
> Joachim

Just my 2 cents,

Best regards,
--
Olivier BERGER <olivier.berger@...>
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Olivier Berger]

Hi.

Some more feedback, again.

Le lundi 19 octobre 2009 à 11:21 -0700, Don Armstrong a écrit :

> On Mon, 19 Oct 2009, Joachim Breitner wrote:
> > @dons: What are your requirements until you will accept this feature on
> > bugs.d.o, in terms of number of packages or clear consensus on d-devel
> > or such or actual inclusion in the policy?
>
> Depends on the complexity of me actually getting the information to
> the bts,[0] but assuming that there's:
>
> 1) a clear consensus on the methodology to make/update the links[1]
>
> 2) a tab-delineated text file generated somewhere[2] with the source
> package name in the first field, the link to the upstream bts in the
> second, and the wiki page on wiki.debian.org for additional bug
> reporting/triage information in the third

The conf file of bts-link is very close to that IMHO, and is probably
one of the best resources for building this (unless launchpad holds
better data ?) :
http://git.debian.org/?p=bts-link/bts-link.git;a=blob;f=btslink.cfg;hb=HEAD

>
> 3) enough source packages implementing #1 for me to actually test it;
> I imagine if we get at least a half dozen packages from different
> maintainers it'll be enough to demonstrate that it's workable.
>

It seems to me that more than 150 packages are configured in bts-link's
config file... so that makes it more evident maybe that this is already
a pretty common need for Debian, even if it's only implemented inside
bts-lik and not in a more general way.

Just my 2 cents,

> then I'll shove it into my queue to implement.
>
>
> Don Armstrong
>
> 0: the more complexity, the longer it'll take; the actual code change
> to debbugs is relatively trivial.
>
> 1: probably a good idea to also have a draft for inclusion in
> devel-reference
>
> 2: where this is depends on the method, but probably ftpmaster is the
> ideal place; dunno, though.
>
> --
> Some pirates achieved immortality by great deeds of cruelty or
> derring-do. Some achieved immortality by amassing great wealth. But
> the captain had long ago decided that he would, on the whole, prefer
> to achieve immortality by not dying.
>  -- Terry Pratchet _The Color of Magic_
>
> http://www.donarmstrong.com              http://rzlab.ucr.edu

Best regards,
--
Olivier BERGER <olivier.berger@...>
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...