Forking is evil. Especially when upstream is an active community. #4 should be avoided at almost any price.
If you think you have to fork, be honest and clear. Forking means that you are now in charge of maintaining the fork and make it succesfull *in general*, not only as part of statusnet. If upstream denies a patch, you should respect it and either find better arguments to make upstream change its opinion or work around it and participate in promoting your patch to upstream. Typically you will find that upstream knows why it refuses a patch and you will find a cooperative solution. And please, please - never ever confuse patches with feature requests ... Jan -- Jan H Wildeboer | EMEA Open Source Affairs | Office: +49 (0)89 205071-207 Red Hat GmbH | Mobile: +49 (0)174 33 23 249 Technopark II, Haus C | Fax: +49 (0)89 205071-111 Werner-von-Siemens-Ring 11 -15 | 85630 Grasbrunn | _____________________________________________________________________ Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, Werner-von-Siemens-Ring 11 -15 85630 Grasbrunn, Handelsregister: Amtsgericht Muenchen HRB 153243 Geschaeftsfuehrer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera _____________________________________________________________________ GPG Key: 3AC3C8AB Fingerprint: 3D1E C4E0 DD67 E16D E47A 9564 A72F 5C39 3AC3 C8AB _____ From: [email protected] <[email protected]> To: [email protected] <[email protected]> Cc: [email protected] <[email protected]> Sent: Sat Oct 31 13:54:16 2009 Subject: Re: [StatusNet-dev] Patches to extlib: don't do it [email protected] wrote: The only patches to extlib/ that are acceptable are release versions of the upstream libraries. What's the recommended course in the meantime while waiting for patches to go through upstream? I'm not entirely sure, but I've put up a README file for the testing branch that gives a proposed process: http://gitorious.org/statusnet/mainline/blobs/testing/extlib/README Kind of in ascending order of urgency: 1. Report the bug, work around it, then integrate the release version when it comes out. 2. If a patch is accepted but not yet released, apply the patch. 3. If the patch is not accepted because the project is unmaintained, adopt it and release changes. 4. If the project cannot be adopted, or if upstream refuses to integrate absolutely necessary changes, do a principled fork in a way that doesn't interfere with other software. Does that sound about right? -Evan -- Evan Prodromou CEO, StatusNet, Inc. [email protected] - http://identi.ca/evan - +1-514-554-3826
_______________________________________________ StatusNet-dev mailing list [email protected] http://lists.status.net/mailman/listinfo/statusnet-dev
