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.
> 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
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.