Re: Divesting ourselves of i386 bigotry...
Michael, you mentioned that you didn't get the discussion on this
topic that you had hoped. I'm going to quote your message heavily in
an attempt to tickle debate and put in my two cents.
To start with, I would like to state that I sympathize with the poor
position that porters often find themselves in, and can imagine the
level of frustration they sometimes must feel.
OTOH, blaming the ignorance or bigotry of x86-based debian
maintainers, which perhaps factually correct on some level, is not as
productive as it should be. I believe that these are structural
problems that need to be solved, mostly be heightening awareness and
fostering collaboration. I'll also state my last point, which is that
schemes which imply deep changes to Debian infrastructure (dinstall,
the BTS, dpkg) are probably much less viable than not requiring such
changes.
Michael Alan Dorman <mdorman-debian-devel@debian.org> writes:
> First, I'd like to report that, as of today, the Alpha is 243 packages away
> from being in sync with i386/main. This makes me confident that we can have
> a hamm release for Alpha, even if it takes another month or two to finish up
> and might not encompass the whole of contrib and non-free.
>
> *Unfortunately*, it should be closer than that---in the last couple of
> months, I've fixed bugs in several packages that were not building properly
> because of i386-centric oversights, when the maintainers incorporate them
> into the packages, they have often been putting them slink only.
Were there important or greater level bugs filed against the package,
making it clear that the current state of the pkg was unaccepable for
Alpha?
Another nit is that it has not been stated clearly and authoritatively
(until recently i suppose) exactly which ports would be co-releasing
hamm with x86.
> Given that these changes are necessary for the packages to build
> properly for hamm on another architecture, I think this is wrong.
I agree, but I wonder if it was made clear to the maintainer that it
is wrong and how to fix it. Too often, I see porters altering my
packages with *zero* indication given to me (the official maintainer)
that there's a rogue version of the package floating around.
> I would like to ask what I should do about this:
>
> 1) File a release-critical bug on ftp.debian.org that could be closed if the
> corrected package was copied from hamm to slink?
>
> 2) File a release-critical bug on the package that could be closed if the
> corrected package was copied from hamm to slink?
Yes, this is better!
> 3) Do NMUs to slink that resolve the problems?
I think an NMU to hamm is acceptable if the deadlines are pending, the
changes are not going to mess anything else up.
> 3) Something else?
>
> I get really frustrated by this. I would rather not have to resort to
> guerilla warfare, but I find that gets the best results---doing an NMU to
> hamm to fix a bug often gets the maintainer's attention in a way a simple
> bug report doesn't.
>
> Does anyone have suggestions?
I suggest it would maybe make life easier for porters to have a hacked
'dupload' where it would compare the original diff with the new diff
for the package, auto-submit porter diffs to the BTS, at a severity
they could specify, say with a subject line of "diff required for
compilation on Alpha" or what have you.
--
.....A. P. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: