On Sat, Nov 4, 2017 at 4:49 PM, Helmut K. C. Tessarek <tessa...@evermeet.cx> wrote: > On 2017-11-04 11:43, Eric Covener wrote: >> I'd be surprised if it helped someone who felt overwhelmed by the >> existence of 5 branches in SVN (no offense intended). > > I agree to disagree. Graham's long explanation which still doesn't cover > certain scenarios is for sure a reason why not more people contribute to > the project.
> Let's say I have a patch for the current version of Apache: 2.4.29. What > now? I have to get it first into 2.5.0 or trunk, which might not even be > compatible? So I have to figure out how the code in trunk works? Then I > have to do what? Learn SVN and how to use the STATUS file? I can't even > commit to a branch (let alone the fact that feature banches do not > exist) without a userid on svn.apache.org. Contributors do almost none of this. They just need to share a patch. > > All I want to do are 2 steps: Commit the patch to the 2.4.x branch (as a > new feature or patch branch) and send a PR. (X reviewers are required, > and boom it gets merged. Don't forget all the nice CI that can be > triggered before or after the merge.) I don't see the difference in practice. A contributor can open a bug report or send an email and share their changes, or even develop it in git and submit a PR against our r/o mirror on github. But ultimately you've just got a code change. They aren't commiting anything or editing STATUS. If their patch doesn't apply to trunk or 2.4.x, more work is needed regardless of the SCM system. I doubt Graham could describe how to do release management in git much more succintly.
