Hi,

So 2.5.0-alpha will be RTC.
Good for me, it is what I personally prefer.

Will it be a fork of latest 2.4.x and trunk things will have to be
proposed, voted and backported?
Or will it be a fork from trunk with things likely never (IMHO) really
reviewed?

My own opinion is a copy of 2.4.x + RTC process because I think it is
safer. But I'm not sure it is what others have in mind.

CJ


Le 04/11/2017 à 11:59, Graham Leggett a écrit :
On 04 Nov 2017, at 12:03 PM, Steffen <i...@apachelounge.com <mailto: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
—


Reply via email to