bug-hurd
[Top][All Lists]
Advanced

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

Re: Upstreaming patches


From: Samuel Thibault
Subject: Re: Upstreaming patches
Date: Mon, 7 Apr 2014 11:57:05 +0200
User-agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)

Justus Winter, le Mon 07 Apr 2014 11:41:47 +0200, a écrit :
> > I end up spending my time mostly fixing & pushing more-or-less-baked
> > patches to Debian packages, so people at least get to try them, but the
> > polishing+submitting work is much more work, and if nobody gives help
> > there, well things can only go slowly for sure.  There's a question of
> > priority.  For instance, should have I spent my time the other day on
> > DDE / exec_filename / pushing some glibc patches upstream, or on fixing
> > the pthread_condattr_setclock() so glib2.0 can continue working at all?
> > 
> > Maybe I should just not do this kind of ugly pushing, so Debian doesn't
> > get them, and thus people would have to really push their changes in
> > properly, and not be happy with just seeing them applied to Debian.
> > 
> > In the end, I'd essentially say "Patch Thankfully Welcome", like they
> > do so often on the cygwin mailing list.
> 
> Well, the patches are there.  The exec_filename_* series has been
> proposed two times, by Emilio in 2010, and then by Jeremie in 2011.
> The second posting didn't even receive a single reply.  What else can
> one do?

Probably understand that Roland wasn't talking about the patch, but the
principle, and thus just reposting the patches as they are will not get
any better answer, so rather discuss explicitly with Roland about the
exact concern he raised (usefulness of the patch, apparently).

> > Of course, that means baked patches, which is quite some work, but
> > the Hurd project is no exception to this requirement.
> 
> I don't buy it.  I do not believe in getting it right from the
> beginning, I believe in incremental refinement.

I fully agree.  But we can't really commit patches which don't even
explain what they are doing and why. I'm not saying all patches are
like that, but a lot of them are. Also, the more crap you accept, the
more tedious it becomes to maintain it too. The DDE thing was really a
big mess, it couldn't be commited as such at all. Perhaps now it can,
one has to check. Up to now I have always been pressed my more urging
matters.

> > Put another way, please people just dive into patches, check why they
> > are not upstream (just ask if it's not written in there), and have a
> > look at how to fix that.  I don't think there is anything strongly
> > blocking anywhere, it's just a matter of doing things, so that things
> > get done...
> 
> ... I disagree here.  If I start developing for a new project, the
> first thing I do is clone the repo and build it.  Doing that for Hurd
> results in a broken system.  That surely has the potential to scare
> away potential contributors, and I cannot blame them a bit.

Sure, again I FULLY agree.

And what is the solution?  I *DONT* have the time to fix it all myself.
It's as simple as that.  What can I do more about it?

Samuel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]