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
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
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]
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
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
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
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
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
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
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
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
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
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
13 matches
Mail list logo
