Re: Development plans
On Wed, 18 Jun 2008, Michael Stefaniuc wrote: [...] What about patches that have no associated bug report but can and probably should be cherry picked into stable? Translation patches come to mind as a class of patches that would fall under this. Note that with translations modifying the rc files directly it takes work to make sure they are applicable to an older Wine: you have to check for each patch that the dialog was identical (same set of buttons, etc) in the older Wine. If we had po files for the resource translations we wouldn't have this problem. -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ Linux: the choice of a GNU generation
Re: Development plans
Francois Gouget wrote: On Wed, 18 Jun 2008, Michael Stefaniuc wrote: [...] What about patches that have no associated bug report but can and probably should be cherry picked into stable? Translation patches come to mind as a class of patches that would fall under this. Note that with translations modifying the rc files directly it takes work to make sure they are applicable to an older Wine: you have to check for each patch that the dialog was identical (same set of buttons, etc) in the older Wine. For the beginning it won't be that hard as a check if the En.rc file changed since wine-1.0 is enough: git log wine-1.0.. En.rc If we had po files for the resource translations we wouldn't have this problem. PO files will have other advantages as well as introducing new problems. bye michael
Re: Development plans
Scott Ritchie [EMAIL PROTECTED] writes: Will the 1.0.1 branch be receiving new conformance tests, or is that unnecessary? If a bug fix comes with a test then the test can be merged too, but otherwise I don't think it's necessary to add tests. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Development plans
Eric Pouech [EMAIL PROTECTED] writes: 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 ? If a patch can't be made to apply then I'll ask the author to merge it, but for 1.0.1 that shouldn't happen, we won't be diverging that fast. And once backporting starts to become too painful then it will be time to make a new stable release. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Development plans
Michael Stefaniuc [EMAIL PROTECTED] writes: What about patches that have no associated bug report but can and probably should be cherry picked into stable? Translation patches come to mind as a class of patches that would fall under this. We could require bugzilla entries for each of them but I'm not sure we want to do that. I mean one bugzilla per patch though 1 entry referencing a lot of patches should be doable. It's easy enough to extract a list of translation patches if we decide to merge them, so I don't think there's a need to maintain a list in bugzilla. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Development plans
Alexandre Julliard wrote: Scott Ritchie [EMAIL PROTECTED] writes: Will the 1.0.1 branch be receiving new conformance tests, or is that unnecessary? If a bug fix comes with a test then the test can be merged too, but otherwise I don't think it's necessary to add tests. As said on IRC the other day, the only possible issue I foresee is when people are running Paul Millard winetest on a stable Wine version. As new tests will incorporate new API's (that are possibly not covered in stable) and new parameter checking will be done this could lead to test crashes and such. -- Cheers, Paul.
Re: Development plans
2008/6/18 Alexandre Julliard [EMAIL PROTECTED]: Again, congrats to everybody for the 1.0 release! Yes, congratulations everyone, especially those who fixed bugs during the code freeze. Now that I'm starting to recover from the shock of having actually shipped 1.0, here are a few notes on future development: 1) Code freeze is over, patches are accepted again. If you sent patches and they didn't get applied during code freeze, please rebase them against 1.0 and resend them. 2) Development will continue as usual in the git master branch. The 1.1.x development releases will be made from that branch every other Friday. Should we take this opportunity to move to a sub-maintainer model for some parts of the Wine tree to take the load off of Alexandre? -- Rob Shearman
Re: Development plans
3) There is now a git stable branch, where only important bug fixes will be committed. The 1.0.x maintenance releases will be made from that branch whenever enough changes have accumulated to justify a release. The process I suggest for the 1.0.1 release is as follows: - all bugs should be fixed in the master branch first - once a bug fix has been committed to master, the corresponding bug report should be marked fixed, with the sha1 of the commit fixing it - the bug report should then be put into the 1.0.1 milestone. This will allow me to periodically query for 1.0.1 bugs that are fixed in master and cherry-pick the corresponding commits into the stable branch. 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+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Development plans
Alexandre Julliard wrote: Hi folks, Again, congrats to everybody for the 1.0 release! Now that I'm starting to recover from the shock of having actually shipped 1.0, here are a few notes on future development: 1) Code freeze is over, patches are accepted again. If you sent patches and they didn't get applied during code freeze, please rebase them against 1.0 and resend them. 2) Development will continue as usual in the git master branch. The 1.1.x development releases will be made from that branch every other Friday. 3) There is now a git stable branch, where only important bug fixes will be committed. The 1.0.x maintenance releases will be made from that branch whenever enough changes have accumulated to justify a release. The process I suggest for the 1.0.1 release is as follows: - all bugs should be fixed in the master branch first - once a bug fix has been committed to master, the corresponding bug report should be marked fixed, with the sha1 of the commit fixing it - the bug report should then be put into the 1.0.1 milestone. This will allow me to periodically query for 1.0.1 bugs that are fixed in master and cherry-pick the corresponding commits into the stable branch. Will the 1.0.1 branch be receiving new conformance tests, or is that unnecessary? Thanks, Scott Ritchie
Re: Development plans
Hello Alexandre, good job on 1.0. Hopefully now the time of boring commit messages is over ;) Alexandre Julliard wrote: The process I suggest for the 1.0.1 release is as follows: - all bugs should be fixed in the master branch first - once a bug fix has been committed to master, the corresponding bug report should be marked fixed, with the sha1 of the commit fixing it - the bug report should then be put into the 1.0.1 milestone. This will allow me to periodically query for 1.0.1 bugs that are fixed in master and cherry-pick the corresponding commits into the stable branch. What about patches that have no associated bug report but can and probably should be cherry picked into stable? Translation patches come to mind as a class of patches that would fall under this. We could require bugzilla entries for each of them but I'm not sure we want to do that. I mean one bugzilla per patch though 1 entry referencing a lot of patches should be doable. bye michael
Re: Development plans
On Wed, Jun 18, 2008 at 3:31 PM, Eric Pouech [EMAIL PROTECTED] 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
Re: Development plans
On Wed, Jun 18, 2008 at 7:41 PM, Steven Edwards [EMAIL PROTECTED] wrote: 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. Sorry I want to be clear. I mean I think its unreasonable to be maintained by Alexandre for hundreds or thousands of patches if there is a good bit of backporting. Assuming as my second paragraph does that 1.0.x is with us for a long time to come there could be a good bit of work in a year or two just to get a simple fix to apply. -- 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
