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

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



James Troup wrote:
> They don't compile from freshly unpacked source.

How odd. Other maintainer must work substantially differently than I, then.

> Another thing is that i386 maintainers _won't_ notice is two of our
> most common problems: YAFHIC386 in debian/control's Architecture and
> debian/files not being removed during debian/rules clean.

I can see the first, but I've certianly ran into the second before I
modified debhelper to delete debian/files.

> > I seem to be hearing the argument that binary-only NMU's can be made without
> > waiting, while a normal NMU requires that you wait for the maintainer to
> > have a reasonable time to do something about a bug report. I don't
> > understand why this would be so.
> 
> Because I refuse to wait for maintainers who take weeks and weeks (if
> not months or years [This was actually the case till Guy finally
> purged the old style source format packages]) to respond to trivial
> bugs; there is no reason why non-i386 users and developers should be
> held up by slow-to-respond i386/source maintainers, when we have
> already done the work and found the fix for their bugs.

But you're missing my point. Why does a binary-only NMU give you the right
to skip waiting, while a normal NMU does not? Why are they different? Why
does one let you circumvent the rules, for however noble a purpose?

Binary-only and normal NMU's are the same thing, and if you can do a
binary-only NMU w/o waiting, you should be able to do a normal NMU w/o
waiting. And if you can do that, it follows you should, since a normal NMU
is better.

> > [1] I recognize the value of binary-only NMU's when a new port is being
> >    started and you can't afford to wait on the maintainer,
> 
> Eh?  Why should a port be able to afford to wait on i386-maintainers
> just because it's no longer new?  

Do you want the ports to remain forever second class citizens, or do you
want them to eventually mature to be equal with i386? If you want the
latter, at some point you're going to have to start playing by the same
rules as everyone else.

Put another way, how would you like it if I did an i386 binary-only NMU?
I'll bet I'd be flamed to death.

> All ports needs to make a lot of changes because so many source
> packages are broken.  It's got little or nothing to do with the
> newness of the port (if you look at the {binary-,}NMU's and bug
> reports, they aren't predominantly from the new ports, but rather the
> older ones (m68k && alpha)).

Broken source package has nothing to do with a port at all. I can find the
same errors rebuilding on i386.

> Eh?  Define ``standard'', please?  I rather hope you don't mean "what
> i386 uses".

I mean that we should converge on using the same build environment and build
mechanisms (and NMU mechanisms) for all architectures, and until we do, the
ports are going to remain second class citizens.

-- 
see shy jo


Reply to: