I'm upstream for pptp, pptpd, and a few other things.
A few years ago, the PPTP project support load came mainly from users who were using
distribution packages and not the raw source. Often they would have an old version, or a
version changed from what I had released.
We weren't being told about changes made by distribution developers.
So pressing was this for me that at one linux.conf.au, after Mark Shuttleworth spoke of his
time in orbit, I went up to him and insisted that Ubuntu at least show people what they
change. patches.ubuntu is presumably the result.
But still, it's a rare distribution developer who will engage with their upstream on trivial
issues that can be easily patched during packaging.
So what I do is hunt around the distributions looking for interesting patches, with my goal to
make the patches useless for the next version ... by merging them where possible. Upstream
developers who don't bother with this are kinda missing the point, in my opinion. Those users
still matter, even if they are hidden behind a DD.
I wish there was a clear list of places to hunt for these patches!
Posted May 21, 2008 13:57 UTC (Wed) by michaeljt (subscriber, #39183)
[Link]
The "patch == bug" proposal would solve this.
Debian contemplates patch management
Posted May 24, 2008 3:24 UTC (Sat) by giraffedata (subscriber, #1954)
[Link]
So what I do is hunt around the distributions looking for interesting patches, with my goal to
make the patches useless for the next version ... by merging them where possible. Upstream
developers who don't bother with this are kinda missing the point, in my opinion.
I don't know what point that is, but what I find as an upstream developer, distributing code as a hobby, is that hunting for patches is far less rewarding than other things I can do with my time. I don't mind working on problems by email, and I don't mind applying patches sent to me with an explanation, but hunting for patches is no fun.
The monotonous part is going over the same set repeatedly, trying to figure out what the patch is for, and separating the ones that are obsolete (I already fixed it a different way) or ideosyncratic from the ones I can actually use.
But I'd subscribe to a tracking system, so I could see reports of problems, and participate in their solution, as they occur.
I usually get downstream patches when a user decides to install my raw stuff to get the latest features and does the patch hunt to see what he'll be losing, then passes the info on to me.