On Sat, Nov 4, 2017 at 10:39 PM, Eric Covener <cove...@gmail.com> wrote:
> On Sat, Nov 4, 2017 at 4:49 PM, Helmut K. C. Tessarek
> <tessa...@evermeet.cx> wrote:
>> 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.
I agree, this has nothing to do with the SCM system.
If one can commit directly to 2.4.x, who is going to frontport the
change to trunk?
We don't want fixes or improvements in current release(s) only, but in
future ones too...
So one has to to know trunk if (s)he wants to be a code committer, I
don't know any other project where it's different, changes always go
to current first.
It's not a requirement for contributors though, patches on any version
is always very welcome and will be back/font-ported as needed by a