On Sun, May 18, 2008 at 01:37:53PM +0300, Riku Voipio wrote: > On Sun, May 18, 2008 at 12:03:17PM +0200, Aurelien Jarno wrote: > > Do you have a proposal for a remplacement of the glibc then? > > > And note we *do* forward patches we apply to the Debian Glibc, which is > > not always something pleasant to do, especially when it concerns > > "embedded crap" [1]: at best your patch is ignored, at worst you get > > insults. > > Has using eglibc.org as upstream been considered? Forking is a valid > option when upstream is as hostile and unco-operative as glibc's is.
While I plainly support EGLIBC, it is mainly targeted to the embedded world. I am not sure it is a good idea to switch a server/desktop distribution to EGLIBC *yet*, also given that I find this project a big young. Also it would cause divergence from other distributions, which seems to be the exact contrary to what seems to be discussed in this thread. That said, if the relation with upstream doesn't improve, and if in the next years EGLIBC prove to be the way to go, we would consider switching to it. > > That's why I personally don't want another level of administrative task > > like proposed by Joey Hess, which won't improve things in that case. > > It seems very debian way - fix collaboration problems with policies > and bureacracy.. Exactly. The problem is that most maintainers do not really feel it is important to submit patch upstreams. Creating new tools won't help in that case, while they will bother those already doing that. > I would propose that maintainers can suggest alternative > collobarion models with upstream as well. Such as maintaing the delta > against upstream in VCS branch of upstream, maintaining a policy that The problem is that you can't change upstream if it has proved to be non-collaborative. OTOH I think we are currently managing the patches we apply correctly, they are sorted by architecture, and by status (debian specific, submitted and taken from cvs). > packager will only include patches that are already in committed upstream > VCS, or extreme cases declaring that the debian packaging is a fork of > upstream. For the glibc case, that would mean we should drop support for at least half of the currently supported architecture. Our current policy is to not commit a patch (except debian specific ones) in the SVN if it has not been submitted upstream. IMHO, each package is specific, you can't have a global policy on the way to forward patches upstream. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `- people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
