In that case
<ballot>
> [ ] +1
> [ ] 0
> [X] -1
> </ballot>
For ensuring new features start in "trunk" and work their way back, I'd
+1. But since bugs (in BZ not marked as enhancement) would also need RTC
- that is my reason for -1.
-Tim
jean-frederic clere wrote:
Tim Funk wrote:
What is a change? Any commit?
Is a change only for new features and bug fixes are out of scope?
My idea is to have it for all commits but only on release branches.
The idea is more to force people participating on the development of new
feature and help to fixing bugs.
Cheers
Jean-Frederic
-Tim
jean-frederic clere wrote:
Hi,
I would also propose that we take an handling of release branches
similar to httpd.
The votes will get in a file named STATUS file and once accepted in a
file named CHANGES.
The proposal of backports/fixes should be a description of the
feature/PR number and a link to a commit (in another branch or sandbox)
or a patch (diff -u) against the branch.
A proposal needs 3 +1 votes and no -1 to be accepted. The committer that
makes the proposal is responsible to commit the new code (and move the
proposal from STATUS to CHANGES) in the branch once accepted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
