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.

Reply via email to