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

Re: [fab] Architecture Policy.

On Tue, 2006-11-21 at 11:38 -0500, Greg Dekoenigsberg wrote:
> +1 to Seth's point.  But beyond that...

Would you care to suggest alternative nomenclature? I personally happen
to think that 'package-monkey' is a perfect term -- it definitely
describes my maintenance of the one gtk+dbus package I own (and which
I'm trying to get rid of) to a tee.

> David, what would you suggest?  In the abstract case:
> 1. A packager will almost always be packaging primarily for x86 or
> x86_64;
> 2. A packager will almost never have access to the hardware to test on
> other arches.

Packagers always have at least remote access to PowerPC machines if they
need it.

> Given those two constraints, the duties of the secondary arch teams
> are to:

You omitted the duties of the package owner, which include not
committing gratuitously non-portable code.

> 1. Make changes directly to any offending packages;
> 2. Notify the maintainer that the changes are being made;
> 3. Work with the maintainer to ensure that arch-specific changes do
> not break the packages.
> What, exactly, is unreasonable about this proposal? 

I didn't call it 'unreasonable'. I said that I like it in general, with
the proviso that we should make sure we don't start to allow packagers
to pay less attention to portability issues than they do at the moment.

We currently have a relatively good balance in package maintenance.

In cases where the code is just plain stupid and unportable, it falls to
the owner of the package to fix it; in the first instance, we tend to
just offer guidance and access to PPC machines for testing.

Where that fails, because the issue is actually arch-specific, the PPC
folks will get their own hands dirty with the fix.

Currently, it works well. What I said is that I don't want to see a
regression in that situation -- I don't want to see packagers saying "I
don't care -- it works for me on little-endian machines where char is

The appropriate response was "yes, that's a valid concern and we'll make
sure it doesn't happen". Not the dismissive attitude which Bill showed.


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