On 04 Nov 2017, at 12:03 PM, Steffen <i...@apachelounge.com> wrote:

> Soon we have:
> 
> branches 2.4.x
> trunk
> 2.5.0-alpha
> patches/2.4.x
> patches/trunk
> 
> Please a procedure:  where and when do we apply patches/fixes. 

When: When you feel your change is appropriate, and when on review-then-commit 
branches you have received three +1’s including yours binding vote.

Where: Read on.

Everything starts on bleeding edge trunk, always, just as we always have done.

People propose backports to the older branches, in order, if people feel those 
patches are warranted, just as we always have done.

If a branch is commit-then-review (CTR), and you believe it is appropriate to 
do so, you commit to that branch, and if people have a problem with it, they 
will say so.

If a branch is review-then-commit (RTC), and you believe it is appropriate to 
do so, you propose a backport in STATUS and when you get three +1’s (including 
your own binding one), you commit to that branch.

The changes cascade down the branches as far as you feel is appropriate.

Concrete example.

You have a change. You believe this change should be backported to v2.4.x, so 
that people using the current v2.4.x line will see your change. You commit it 
to trunk. You propose it for backport to v2.5.0-alpha. You propose it for 
backport to v2.4.x. You could carry on down to v2.2.x if you believe it is 
warranted, but you probably won’t believe it is warranted for a branch that is 
end of life.

What do we want?

- All changes on v2.2.x should also appear in all higher branches and trunk.
- All changes on v2.4.x should also appear in all higher branches and trunk.
- All changes on v2.5.x should also appear in trunk.

What _don’t_ we want?

- Changes to appear on v2.4.x that _aren’t_ also made to v2.5.x. For obvious 
reasons we don’t want things in v2.4.x to suddenly vanish from v2.5/v2.6; 
except for
- Code that only appears in older branches. For example if a module is removed, 
you physically can’t patch it in trunk because it no longer exists. In these 
rare cases you would propose a fix for an older branch only. The rule here is 
“be sensible”.

Nothing has changed in our process.

Regards,
Graham
—

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to