Development plans

[Steven Edwards]

On Wed, Jun 18, 2008 at 3:31 PM, Eric Pouech <eric.pouech at 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

-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo