Re: buildd/porter/maintainer roles again
On Tue, Jul 13, 2010 at 05:22:12PM +0200, Petter Reinholdtsen wrote:
>
> [Clint Adams]
> > Shouldn't it be the responsibility of the buildd admin (if, for some
> > reason, the buildd admin is not a porter) to notify an
> > architecture's porters of any porting issues manifesting themselves
> > in a package build?
>
> You bring up the important topic of expectations on who is responsible
> for what regarding porting of Debian packages to the architectures in
> Debian.
>
> I believe it is important that the separation of responsibilities
> between package maintainers, porters and buildd maintainers is
> described somewhere autorative, to ensure that the entire project have
> a common understanding on who is responsible for what and hopefully
> avoid or reduce the number of conflicts between package maintainers,
> porters and buildd administrators.
>
> To ensure the various ports of Debian to not put unreasonable strain
> on package maintainers, I believe it is important that most of the
> responsibility of getting a package working on a architecture where
> the package have never built before is placed on the porters and
> buildd administrators.
I would like for people not to speak in such generic terms.
Sometimes a package fails to build or work on an architecture because it
does something silly, like
addr = (u32)(p32) ...
which is code that will never ever function correctly on 64-bit
architectures (and before you ask: yes, this is a real-life example).
Expecting porters to find and fix such things is not only unrealistic,
it isn't even fair.
> If this responsibility instead is placed on package maintainers, I
> believe it is a good idea for Debian to drop the lesser used
> architectures to ensure they do not slow down the rate of improvement
> in Debian.
You should note that packages which have never built before on a
particular architecture cannot hold back that architecture, unless they
are part of the base system or Build-Essential set. So dropping that
architecture for that reason isn't a good idea, IMO.
> Those caring for an architecture (which I assume is the set of porters
> and buildd administrators) need to be the ones responsible for
> providing patches to package maintainers to get the architecture
> working with a given package. Of course this work need to be done
> together with the package maintainers, but I believe it is
> unreasonable to expect maintainers to spend time on trying to get
> their packages working on architectures they do not care for, and am
> sure it is the way to get Debian to throw out lesser used
> architectures.
It is fair to expect porters to work on packages when they hold back the
port as a whole (such as packages that are part of the toolchain or the
base system).
It is fair to expect porters to work on packages when asked. E.g., a
package fails to build or function, the maintainer can't figure out why,
and doesn't have hardware of the architecture in question. Porters
should then be willing to download the package, and spend some time in
identifying the bug in question.
I don't think it's fair to expect porters to work on *all* bugs in *all*
packages for their architecture, just because that architecture is
"lesser used".
Please remember that every time a package fails to function correctly on
a particular architecture, barring toolchain bugs, this is a bug in that
package itself. It may be a bug that just doesn't happen to trigger very
often on machines of the architecture that the maintainer used to build
and test the package, or it may be a bug of a kind that is only
problematic on one subset of architectures (such as failure to properly
use the ntoh* functions, or casts of pointers to 32bit variables, or
something similar), but that doesn't make it a bug of the architecture;
it is still a bug in the package itself. As such, while the
architecture's porters should be willing to help out when and where
necessary, I think fixing one's bugs should still be one's own
responsibility. If, of course, a maintainer can't fix something and the
porters can't (or won't) help, then that's a very good reason for that
maintainer to ignore the bug.
In that light, it's also discouraging to see that even if a porter puts
some work in a package Just Because He Can(tm), some maintainers just
don't care, because it works on their architecture and this architecture
is not used that often anyway (#497262, for example).
--
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
http://www.schneier.com/blog/archives/2009/01/biometrics.html
Reply to: