Re: Uploaded gdb 4.17-4.m68k.objc.threads.hwwp.fpu.gnat.3.1 (source sparc) to master
[Redirected to <debian-devel>]
On Sun, 14 Feb 1999 18:20:13 +0100, Christian Meder <meder@isr.uni-stuttgart.de> said:
> On Sat, Feb 13, 1999 at 11:52:38PM -0500, Adam Di Carlo wrote:
>> On Sun, 14 Feb 1999 02:15:53 +0100, Christian Meder
>> <meder@isr.uni-stuttgart.de> said:
>>
>> > You shouldn't upload new source just to fix the compilation on >
>> sparc.
>>
>> Why not? If source changes (patches) are required, there should be
>> another source package. Read the developer's reference (2.6.0) for
>> justification and guidelines on this.
>>
>> Ian Jackson, for instance, insists on this.
> There are two different issues involved:
> - I complained that the fix is a hack which probably isn't
> architecture independent. Additionally it's a conflict in the
> glibc2.1 package which includes the kernel-header asm-sparc/ptrace.h
> and the general sys/ptrace.h header and therefore shouldn't be fixed
> in the gdb sources. So I guess I didn't state my point clearly
> enough ;-)
Well, clearly, any sourceful NMUs need to be written to try to be
portable across all platforms. I know this can be a PITA, but I don't
see any other way.
> - after your reply I read the chapter on porter NMU's in the 2.6.0
> developer's reference and, provided the chapter represents the
> consensus on the topic, I guess I've got to change the severity of a
> _lot_ of my bug reports to important. Additionally I've got to
> change my habit of doing sourceless binary NMU's of patched versions
> and just reporting the patch to the BTS. This will put a _lot_ of
> pressure on slink as I'll introduce (guessing) some 50 - 70
> important bugs and a couple of patched source packages. Even without
> too much sleep I'll need around two weeks to do the patched source
> uploads of the glibc2.1 fixes (assuming the maintainers won't do it
> themselves).
First, let me state that the developers-reference is not a statement
of official policy. Obviously, we have to make 'best effort' attempts
to comply with licensing terms.
On the other hand, my intention is to make life easier for porters,
not harder. The intention is to have *documented* guidelines and
documentation for porters. The new sections *are* new. I formulated
them with the input of James Troup and Roman and other porters,
however, the responsibility for any inaccuracies, rampant
impracticalities, or flaws is mine. Again, it's not policy, but
guidelines. Obviously, as documented guidelines I'm going to document
the ideal processes, not the "currently broken but we gotta get this
stuff out anyway" processes, which nevertheless may be required at
this point in time.
The other intention is to raise the level of collaboration between
porters and x86-centric maintainers (the majority, I'll wager), and to
stamp out x86-centricity and insensitivity.
If anything which is stated in the developers-reference is going to
make slink release hell for your architecture, I encourage you to
ignore it for now, and think about how to fix the general problem (and
fix the devel-ref documentation). In short, I personally have no
problems with you doing whatever you have to do to get Debian/Sparc
released, and for you to consider the developers-reference to be what
we're going to shoot for more completely in potato. The keywords here
are 'best effort' and 'maximal return given time constraints'.
> If that's the way to go I'll start immediately after getting an 'Go
> ahead' so we'll get all sparc fixes in the source packages.
I'd love to see this happen, but again, lets not go nuts and hamstring
the slink release at this point.
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: