On 11/04/2017 12:51 PM, Steffen wrote:
> Thanks Graham, very helpful.
> 
> Question left is when/where is patches/2.4.x and patches/trunk used ?  Free 
> to use ? You do not mention them in the process.
> 
> Resume:
> 
> CTR: trunk
> RTC: branches/2.4.x
> RTC: 2.5.0-alpha

I don't see a 2.5.0-alpha branch, let alone RTC. 2.5.0-alpha releases will be 
directly cut from trunk until an API
freeze makes sense at which point of time we should branch.
Regarding the review topic: My impression is that trunk is reviewed in general 
but not thoroughly tested. The testing
should be improved by cutting the alpha releases which should make them easier 
to consume for a broader audience then
checking out stuff from svn trunk directly and compile it. It also sends the 
signal of some movement towards an API
freeze for a new major release.
There might be some parts of trunk which only received weak review, but I guess 
once testing intensifies and bugs pop
up this will be remedied by those working on resolving the bugs.
In the end I can also think that we rip out certain parts of trunk if we as a 
community get to the conclusion that the
code is not working and that nobody is willing to work on this. As long as it 
was not part of GA release I see no issue
with this. Ripping out does not mean that it gets to /dev/null. It can be put 
in a branch, it can get forked as a
separate module, whatever seem appropriate. What I want to avoid is that we get 
in a situation that says: That part of
the code is buggy, so we cannot do a GA with it, nobody is willing to work on 
it, but we cannot remove it. This
shouldn't happen.
Some remark on the backport new features to the stable branch vs. having the 
new features only in a new major release:
I personally like the backporting approach, because from my personal 
perspective as httpd user I cannot easily upgrade
to a new major release as I depend on 3rd party closed source modules that do 
not quickly adopt support for new major
release. So with the current way I get new stuff much faster. But I admit the 
following two things:

1. I think we had too much regressions lately. So I think we need to improve 
our QA process here to reduce this.
2. Having the new features in the stable branch seems to lower the appetite for 
a new major release which does
   not seem to be good in the long run. OTOH we there might have been just too 
few people that are keen on the new
   release and were working towards this. Looks like this is changing.

> ? : patches/2.4.x
> ? : patches/trunk

These are not branches. Just convenience locations to store your patches. For 
backports the preferred way is to do them
via svn merge, but sometimes this does not work due to differences between 
trunk and the stable branch. In this case you
need to prepare a merge patch manually and propose it. So far people used 
different locations e.g. home.apache.org to
store these patches and have them available for review for their fellows.

Regards

RĂ¼diger

Reply via email to