Re: Uploaded gdb 4.17-4.m68k.objc.threads.hwwp.fpu.gnat.3.1 (source sparc) to master
CC'ed to Wichert, Guy and Brian for further discussion
On Sun, Feb 14, 1999 at 01:52:47PM -0500, Adam Di Carlo wrote:
>
> [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.
Ok as far as Debian/Sparc is concerned I propose the following scenarios:
Scenario 1 (my preferred scenario)
The sparc and glibc2.1 specific fixes which aren't yet incorporated in the
slink source packages won't be flagged as important to avoid recompilation of
some 50 (and up) packages on all other architectures which could lead to
newly introduced bugs and a delay of the slink release. Instead we leave all
sparc and glibc2.1 specific fixes which haven't made it into slink open until
the next _stable_ release assuring that everyone can get the source patches
for the Debian/Sparc slink release from the BTS. This fact will be
documented prominently in the Sparc release notes. Maintainers are allowed
to set the severity to fixed if they fixed the bug in unstable but they
are _not_ allowed to close the bug report (causing the patch to vanish 28
days after the closure). Additionally (if necessary) I could provide a
tarball of all source sparc patches for inclusion on the CDs.
In this scenario I would send followups to all affected bug reports and
reopen some bug reports which are already fixed in unstable.
sorry, Joey Hess ;-)
_After_ the release of slink I would raise the severity of all these bug
reports to important (they are pretty important then because Joel will
introduce glibc2.1 on i386 too).
Scenario 2
I'll raise the severity of all open glibc2.1 and sparc specific fixes to
important and cause a major headache for the project. We would get some
50+ important (and release critical) bugs but after fixing them we can
assure that the source packages compile on all released architectures
_without_ patches from the BTS.
Thoughts ? Opinions ?
Greetings,
Christian
--
Christian Meder, email: meder@isr.uni-stuttgart.de
What's the railroad to me ?
I never go to see
Where it ends.
It fills a few hollows,
And makes banks for the swallows,
It sets the sand a-blowing,
And the blackberries a-growing.
(Henry David Thoreau)
Reply to: