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.
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
Michael Stefaniuc mstefani@redhat.com 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.
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 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
2008/6/18 Alexandre Julliard julliard@winehq.org:
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:
- 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.
- 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?
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:
- 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.
- 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.
- 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
Scott Ritchie scott@open-vote.org 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 wrote:
Scott Ritchie scott@open-vote.org 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.
-
Alexandre Julliard -
Francois Gouget -
Michael Stefaniuc -
Paul Vriens -
Rob Shearman -
Scott Ritchie