Re: Debian-Gentoo collaboration on GNU/Hurd ports
On Thu, Mar 27, 2003 at 01:33:31PM +0100, Robert Millan wrote:
> > help-hurd seems appropriate for general discussion of porting issues,
> > unless someone has a problem with that.
> fine for me. what if we use a tag to indicate clearly the message is a
> porting patch? eg, if we put "[ported]" or the like in subject it'll be
> made sure we don't forget to look at it and forward it to the respective bts
Please create a new list for that. It's bad enough that this thread is
cross-posted, but I hang out on help-hurd so I can help newbies.
Flooding that list with patches is likely to significantly decrease the
likelyhood that I'll read it.
> > > - how do we share patches? there are a lot of usable patches in
> > > the debian packages that haven't been forwarded upstream yet.
> > > there are more of them pending to be applied in the debian BTS. In
> > > principle, a Gentoo porter should look at these places if he/she
> > > wants to avoid duplicating work, but it'd be interesting to define
> > > a "protocol" on what to do with patches once they're made, to
> > > ensure everyone gets them.
> > I agree, but I don't have any decent ideas for this at the moment beyond
> > announcing patches to help-hurd/bug-hurd so those working on both ends
> > can grab them.
> because the situation is assymetrical at the moment, you have no
> choice but always looking in debian for already-made patches if you
> want them, but debian porters don't need to look in gentoo places for
> patches. if we follow the guideline of always sending new patches to
> help-hurd, then debian porters won't ever need to look in gentoo
> places, and gentoo porters will stop looking in debian places some
> day. is that ok for you?
The only problem with this is that patches that we create from the
buildd go automatically to the BTS.
> > > - what about API porting-related bugs in the Hurd and Glibc? the
> > > debian BTS entries for hurd, libc0.3 and libc0.3-dev contain
> > > porting-related bugs. (ala, "function foo(), needed for package
> > > bar, is broken or unimplemented") maybe we should copy and forward
> > > them to the Savannah BTS?
The problem is that Debian bugs should never really go upstream.
Debian's glibc is heavily modified to deal with the fact that we have
ports that upstream doesn't actively care about (sh and hppa). Some of
those changes involve some fairly invasive hacks. Certainly in the case
of glibc, you risk facing the Wrath Of Drepper (sort of like the Wrath
of Kahn, except that drepper always wins *g*)
> - the Glibc savannah site  doesn't have an entry for bugs. what do
> the libc people here (Roland? :)) think about creating one?
The libc section in savannah was setup by me so that we could rsync the
repository from sourceware (now sources). They used to use gnats, but
IIRC, RedHat's moved to bugzilla for most things. For libc, libc-alpha
is a good place to send things. If they're interesting, someone will
usually pick up the bug and fix it.
(08:53:07) Jeff: (why don't people just use centimetres like God
(08:53:22) Christina: must just be a unitarian god.. :P