Re: Bug Reporting system
joost witteveen wrote:
>
> > James Troup wrote:
> > >
> > > Goswin Brederlow <goswin.brederlow@student.uni-tuebingen.de> writes:
> > >
> > > > My proposal is to add an architecture field to the maintainer and
> > > > having one maintainer for each architecture.
>
> My proposal is to keep things as they are now, or even stronger:
> A maintainer for package foo is the maintainer of the _source_
> package foo, and whoever compiles that package for the various
> architectures should not get any bugs at all.
Yes, thats right. Nonmaintainer uploads should not get bugreports, and
they wouldn't unless they put themself as maintainers for the
architecture. On most packages the maintainer would select to maintain
all architectures, but on certain thinks he won't/can't. Look at the
kernel-source package for example. It's totaly broken for anything
except i386. Should I ask the i386 maintainer to fix it? He would
probably have no clue about what to to and no chance of testing it. A
m68k bug report should be send to the m68k list and not to debian-devel
as it would be now. That is the main feature I think the bugreporting
system needs. Multiple maintainer for various architectures is not
strictly neccessary to implement it, but one possible way. For packages
like the kernel-sources and other base packages that are arch=all but
really architecture dependand maintainer for various architectures would
be better. Of cause the main maintainer is THE maintainer and all others
would have to send patches to him. But submaintainer could make patches
for the specific arch and upload binaries. Bugreports would go to the
maintainer of the architecture the bug hapens and would inform THE
maintainer if it is a general bug of all systems.
> Really, if package foo works for i386, but fails on Alpha, that still
> is a bug in the _source_ of package foo, and it is thus the job
> of the _source_ maintainer of pacakge foo to change it.
The package xpaste is broken on m68k. Should I ask the maintainer of the
source to recompile and upload it for m68k (the source is alright, it's
just the binary). He's not the right person to make a m68k binary
otherwise he would have uploaded one with his i386 binary. Who should I
ask? Who is maintaining the m68k binary? Having maintainers for
different architecture would make it possible to inform him to recompile
and upload the package if anything is wrong with it. This would also
help THE maintainer, since all submaintainers could be notified of a new
version automatically.
> Or do you also intend to have one source maintainer for every
> architecture? I hope not!
If a source maintainer is neccessary we would have package-i386
package-m68k package-sparc and so on. I don't intend that.
> Of cource, if I find a bugreport on my package bar that apparently
> only is triggered on Alpha systems, I'll try to get in touch with
> someone who has actually got an alpha. He then may look into the
> problem, and possibly send me a patch for the problem (or tell
> me "forward to upstream maintainer", if he cannot find it).
The bugreport will be send out to debian-devel if its not maintainer
only, whereas it should be send to debian-arch instead. I got replies
from people being anoyed that I posted possible bugs on debian-devel
nearly every time I did. (The only exception is this one so far). And
the time I did a bugreport for an m68k specific bug I got quite a few
replies from anoyed people. I don't want to anoy people, so I stoped
filling bugreports unless I'm sure it's a real archindependand bug, but
thats not the way the bugsystem is indendet to work.
>
> But as there is only one _sourece_ package bar, there should also
> be one maintainer who makes changes to that source. Having n maintainers
> who maintain the same source seems very strange.
I'm most concerned about the binary packages. Often things have to be
recompiled for architectures the maintainer can't support. A benefit of
submaintainers would be that they can be notified automatically when the
source changes and upload the new version much faster than now. Having
automatik compileing would erase this benefit, but untill then...
Most changes that are architecture dependand are small (little bugs in
the endian, wrong sign in arch specific code, to old packages or wrong
dependancies..). The problem with them is that the maintainer can search
for years for them because he uses the wrong CPU to notice them and the
bug would remain unfixed for a long time, until some other person takes
on the job and fixes it himself and sends diffs to the maintainer. Thats
the same as having a submaintainer, just more chaotic ans slower.
Maybe we should only have multiple maintainers for binary, but having a
unique setup fpor all packages wouldn't hurt. For source the maintainer
would put himself as the maintainer of all and it would be just like
now.
How about adding an arch entry to the bug report system now and think
about a good way to do anything else. Maybe that would be enough to
sort thinks out.
Comments?
May the source be with you.
Mrvn
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: