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
