Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
Buddha Buck wrote:
>
> How does that differ from -any- binary-only NMU, regardless of
> architechture? If binary-only NMU's for i386 are bad, why are
> binary-only NMUs for m68k OK?
>
> The only -real- problem I see with normal NMUs is that then the i386
> and m68k binaries are built from different source packages, and I don't
> know if our archiving system has a way of dealing with that.
This is true, and this should be fixed, IMO. If "Debian", as an entity,
is making a decision to become multi-arch supportive, then maybe it's
time to update the older rules that were made when x86 was the only
arch, and time to implement some rules and methods that are more
consistent with multi-architecture development. In short, instead of
arguing here, let's try to learn to work together on this.
> Both of which, regardless of architecture, are bugs. If there is a
> lame packaging bug that prevents easy porting, it should be dealt with
> as a bug -- and if that calls for a NMU, then it should be a normal NMU.
> Portability fixes are the same way.
Well, I've got mixed emotions on this. Yes, technically, we should be
waiting for the maintainer to handle it, BUT most of the bugs I've filed
haven't even gotten a responce from the maintainer save the automated
one. It would be one thing if it was A bug in A package, but it's
usually five fixes in 100 packages. If there were 100 of me doing
this, I wouldn't have a problem waiting, but in the meantime, I'm
watching 5 new revisions of these packages come out WITHOUT fixes.
Plus, I've got 30 new package to compile, all of which need fixes...
it's a viscious circle. It seems like alot of the maintainers just
don't care sometimes too. In short, it gets frustrating when things
aren't addressed and your problem keeps mounting and compounding like
that.
Ideally, ALL maintainers would have access to a machine of every arch
to compile their own packages on it, but I still have a feeling that
alot of maintainers wouldn't bother compiling their packages on any
other arch than x86.
> Then they probably won't, and if you are lucky, the next Maintainer
> Upload will include the changes made for your NMU.
Yeah, right. I hate to be nasty, but I've got at least three bugs
that have been sitting in the BTS for over 110 days. These are
fixes that are NEEDED to compile on Alphas (one of them is netstd,
so it's not like I'm talking about some dumb game here). Also,
one of them is an improvement that the upstream author had made
a note to change "one day", but that hasn't even made its way into
the package. If 110 days is "not alot of time to wait" on an
important package, then I might as well stop trying to port ANYTHING
anymore because it's becoming obvious to me that not many maintainers
really care how portable their packages are.
> Why are the different? Aside from Binary-only apparantly breaking
> current policy?
Because we're trying to walk both sides of the line in doing a
binary-only NMU. For one, it takes care of a problem that isn't
being taken care of otherwise (because nobody else seems to care)
and also, we file diffs in the BTS. I have to give alot of the
maintainers good credit for incorporating the patches in a timely
manner, but there are still quite a few that remain outstanding.
How would *you* deal with it? Would you wait 110+ days while your
machine doesn't run right because of a broken package or would you
do a binary NMU to help yourself and others WHILE waiting for the
maintainer to get around to fixing their package?
On the x86, it's not much of a problem because usually maintainers
can test and easily incorporate patches easily (not to mention how
much easier it is to diagnose bugs on their native arch). When it
comes to porters, we end up having to make our patches "drop-in"
easily because we want to make it as easy as possible for the
maintainer or else it'll take another three weeks to make the patches
friendly to all archs.
> The only think that I know of that makes ports second-class citizens is
> you claiming that because you are different, you should follow
> different rules.
> I don't think Joey is anti-non-i386, but that he instead wants everyone
> to play by the same rules.
I think that other archs ARE being treated like second-class citizens in
more regards than just NMUs. I *wish* I had more interest from
maintainers as to whether their packages compile ok on Alphas or not.
To date, I've only had three maintainers actually ask me to test build
their packages on Alphas and run some tests (which they provided)
to make sure things worked ok. I was more than willing to do this.
However, on the flip side, I've also received feedback from a couple of
maintainers that basically said that they don't really care about us.
In short, if *you* think the current rules are multi-arch-friendly, then
I might as well stop porting to the Alpha totally. Like it or not,
other archs have to get some latitude because of the problems that come
with being on a machine that most maintainers DON'T have access to.
Hey, if you really want, I can start dbuild on the master archive and
just forward all of the build reports to the main maintainers. If it
doesn't build, it doesn't build. It would then be up to the maintainer
to fix it a billion times until it passed a dbuild (because most
maintainers don't know the quirks of other archs), and in the meantime,
the other arch ports NEVER get released.
Is that a better solution? I hope you don't think it is....
> Just because they don't show up most of the time, they are still
> broken. And they should be fixed, regardless of if it was found by the
> m68k people, the PPC people, the PalmPilot people, or the i386 people.
Yep.
> A source package which doesn't compile out-of-the-box in the standard
> Debian environment (egcs2.9, gcc2.7, libc6/libc++2.9, binutils2.9, etc
> for i386, glibc2.1 plus whatever compiler/libraries/binutils is used
> for m86k, and so forth) has a bug -- unless it is specifically
> architechture dependent. It's not a bug with the m68k version only,
> it's a bug, plain and simple. If it fails on m68k because the
> maintainer unconsiously thought that All The World's an i386, then the
> source package still needs to be changed -- and Procedures and Policy
> should allow that.
I agree. Things need to be changed as to how other archs are dealt
with -- policy-wise and attitude-wise. I wish I was a billionaire
that could drop Alphas on the desks of every maintainer in the
project, but I'm not. I didn't ask to become an Alpha maintainer to
get as much sh*t as I have gotten about changing things. I just did
it to be able to run a good OS and distribution on the three Alphas
that I have. If that means I have to work alot to make things better
then that's fine..and I have worked VERY hard (as have the rest of
the Alpha porters and I'm sure other arch porters as well). Now, it's
really frustrating to hit a brick wall when it comes to x86 maintainers
that don't care. We've come so far and we're a day away from the
freeze (which it's taken the Alpha port over a year to get to the
current status), that I don't want to just let it go at this point...
> I don't think that the non-i386 ports are second-class citizens. I
> think that they should be treated as equally, under Procedures and
> Policies, as possible. If you claim, as I do, that non-i386 ports
> shouldn't be treated as second-class citizens, why do you ask for
> special treatment?
Because we have special problems that are not easily or feasibly
addressed by policy. What makes my bugs less important than some
wishlist item? Believe me, I've seen stuff like that happen (other
wishlist items closed while my bug-fix patch sits).
C
Reply to: