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

Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs



Adam P. Harris wrote:
> 
> I agree, although I'd like to know exactly what in Policy is
> anti-porter, and how, specifically, we can improve the process and the
> quality of the ports.
> 
> What parts of policy are unfriendly to porters?  I will personnally do
> my utmost to correct and bugs in Policy, if you could point me to the
> actual sections which have the problems.

Honestly, I'm not even sure anymore.  Initially, I had found a few
things that were kinda vague when it came to NMUs and such, but I think
a definite time period should be established for responding to bugs
filed.  The autoreply is just not sufficient in most cases.

> I'd love to be able to do this, as an x86 maintainer.  Are the
> accounts available to x86-maintainers on other boxes?  How do x86
> maintainers go about getting such an account?  I'd be happy to add
> this information to the Developer's Reference, if you can give me some
> information.

Given that Maddog just got Debian an Alpha, this can probably be
arranged easily now (once it's set up that is).  As far as other ports
go, though, I think it would be in Debian's best interest to purchase or
seek donations of machines of every arch for porting efforts for ALL
maintainers to access (meaning, we'll have to spend some serious money
to get higher end versions of each to satisfy load demands, but it'll be
worth it).

> IMHO, Porters do have slightly different rules, because their duties
> as packagers are so radically different from the duties of normal
> package maintainers.  Maintaining a port *is* different from
> maintaining just one package for one architecture.  We have to realize
> this, and allow for it.

Agreed.  In general, porters are aware that changes may cause problems
on other archs (since we're usually the ones hurt by these changes to
begin with), so we try to isolate our changes with the appropriate
#ifdefs and such (believe me, I wish alot of x86 maintainers and
upstream authors did this more often).  Yeah, sure, so we make a mistake
here and there, but that's life.  I don't see why maintainers get so
upset about things like that since they can still fall back on the
binary that's already in the archive until the problem gets resolved.  I
have had made a few mistakes here and there and some maintainers were
willing to work with me to make a multi-arch-friendly package from then
on.

> 
> I'll try to add some stronger wording about porting and why
> maintainers *must* care about them if they're going to maintain a
> package.  We can't force people to care, but if they don't care, maybe
> they shouldn't be a Debian maintainer at all?

I agree.  I just took over binutils and have heard both sides of the
argument about having a non-x86-based maintainer of such an important
devel package.  I don't see how that argument was terribly relevant
unless we actually believe that the x86 is more important that the rest
of the archs.  I don't, so I just took it over and let the chips fall
where they may.  Like it or not, the bulk of Debian's maintainership
will have to be indoctrinated into the multi-architecture work model.

> No, but I'd like to know specific steps we can take to fix this.

I'll look into it further soon (granted, free time is horribly limited
lately).

> Definately not.  Maybe it would be a good idea if we had
> source-depends though.  AFAIK, the lack of source-depends is one of
> the most annoying problems that porters have to deal with.  Do you
> think we could add an extra field to control files to get this going?
> Just so long as it was understood by dbuild, we would be in pretty
> good shape to start getting source-depends working.  Then we could
> require that field by Policy... ?
> 
> (Yes, I know this is a complex issue, but I'd like to see interest in
> this functionality revived.)

I totally agree.  I don't know how many times I've been pouring over
build logs only to find out that I just spent 6 hours compiling
something that was trying to find "gtk-config" initially when I didn't
have gtk installed at that moment. :-)

> Who's given you sh*t ?  Ignorant maintainers?  Take some names -- lets
> embarrass some people who should know better in a public forum, eh?

I piped their mail into /dev/null long ago.  I've kinda shrugged off all
of the criticism in the past and continued my work on the port.  Now I
just try to upload alot and talk little (except now, of course).

> Perhaps we should think about making these porting bugs, for the slink
> architectures (i386, m68k, alpha), at level Important or higher?  Then
> the bugs have to be cleared out before we release.  Maybe we're too
> late to do this for slink, but IMHO a bug which prohbits compilation
> for a port should be considered Important or higher.  I mean, if we
> don't think bugs preventing a package from running on non-x86 is
> *important*, then why are we releasing ports as part of Debian?

An excellent idea.  Actually, it should be dependent on the priority of
the packages really.  In other words, a build error in dpkg on the
Alpha, let's say, should be severe, but a problem with an "extra"
package could be bumped down to important or below.  In short, any
'required' or 'standard' level package should use 'severe', IMO, and all
else can probably be just 'important'.

C

> 
> .....A. P. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>


Reply to: