> As an aside, in the specific instance of the OpenSSL patch, the
> maintainer *did* get an ack from upstream.
As far as I'm aware, he got a reply from a person he didn't know on
a mailing list he wasn't intimately familiar with. ``Yeah, I met
this friendly guy in the lift, he told me it's probably okay.''
>> Let me restate this: debian/patches/ is a way for lazy maintainers to
>> short-circuit the proper patch submission procedures of an upstream
>> project.
> Heh. This very much depends on the project. An awful lot of upstreams
> are *much* less responsive than you are, are outright dead (e.g. Vixie
> cron),
Somebody should definitely start a new upstream projet for Vixie cron.
It's really annoying that there isn't a canonical, distribution-indepen-
dent upstream source for Vixie cron.
Obviously, the new project should use open procedures, including
a public mailing list and a public RCS repository. Not just shoving
random hacks under debian/patches/.
> not-invented-here syndrome, or simply have intense biases against
> e.g. patches which allow portability to particular platforms,
> regardless of their technical merits (I could name names of major
> package upstreams with all these attitudes, some with more than one
> of these at once).
So could I.
Somebody should fork such projects. There's nothing wrong with
forking, assuming it is done right:
1. the fork has a different name from the original project, so that
the original maintainers are not blamed for buggy forks;
2. the fork uses licensing conditions no more restrictive than the
original project, so that the original maintainers can use the
code if they so choose;
3. the fork should use open procedures, including a public maling
list and a public RCS repository.
Shoving random hacks under debian/patches/ fits none of these
conditions. It doesn't change the name -- the users are usually not
aware that they're not running the upstream code. It doesn't use
permissive licensing procedures (I've seen GPLd Debian patches to
BSD-licensed projects). And it is not done in the open.
I'm not just speaking abstractly. I am aware of at least 3 forks of
Polipo, and 4 forks of other software of mine, and I have in the past
given a hand to the maintainers of some of these forks.
Juliusz
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Polipo-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/polipo-users
