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

Re: divergence from upstream as a bug

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

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
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Reply to: