On Wed, Jun 18, 2008 at 3:31 PM, Eric Pouech eric.pouech@orange.fr wrote:
how to you plan to handle patches that don't commit cleanly ? do you, by design of the process, intend to drop them (id est: drop every bug fixes that come after a functional change in the same area of code), or do you plan to handle yourself the task of retrofit ? A+
I think the person that submits the patch should take the effort to make sure the fix applies to 1.0.x if they care about it and post a patch for that to the bug also. If there is backporting work involved in getting it to apply I don't think its reasonable to expect that to be multiplied by hundreds or thousands of patches.
Perhaps we could switch to something like the Linux kernel maintenance system where after a certain point, maybe when 1.1 is tagged, Alexandre turns the 1.0 branch over to someone, so that if say a third party vendor has built an application around 1.0.x, there is a public place where such patches can be maintained. Rather than maintenance of the branch just abruptly ending when 1.1 is tagged it would gradually tapper off as those vendors switch to 1.1. Assuming a larger winelib application, some vendor may want to continue to share patches for 1.0 for 3 to 5 years. I don't know if Alexandre will want to maintain 1.0.x for that long assuming 1.1 1.2 1.3 have been tagged or we've moved on to 2.0