On 11/16/22 2:46 AM, Emmanuel Dreyfus wrote:
> On Fri, Nov 11, 2022 at 02:12:09AM +0000, Emmanuel Dreyfus wrote:
>> I will let someone review xml changes in r1905230 before committing
>> the html files.
>
> I committed the html files.
>
> What is the procedure for pushing changes to the 2.4 branch?
Trunk where you committed is under CTR (Commit then Review). Hence you can just
commit
and people will review the commit and give feedback / comments if they see a
need.
In the worst case they will veto the change with a -1, but this only happens
rarely.
A -1 always requires a technical justification. Otherwise it is not valid.
Typically the -1 is just used as a starting point for an intense technical
discussion
about the patch. This discussion either leads to a revert of the patch or a
modification
of the patch that addresses the technical concerns that lead to the -1.
Even though trunk is CTR it is wise to discuss larger changes before committing
them.
You can either post them to the dev list or even better, open a PR on Github
and sent a
mail about it to the dev list.
The advantage of the PR is that it will do the CI on Github and thus eases the
review
as your peers already know then that it compiles and passes the existing tests.
Keep in mind that our Github repo is a read only mirror of our SVN repository
and hence
PR's cannot be merged directly. But we have some handy tools at
https://svn.apache.org/repos/asf/httpd/dev-tools/github to cope with this.
The 2.4.x branch is under RTC (Review then commit) with very few exceptions
(see the section
"Current exceptions for RTC for this branch:" in the STATUS file at
https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x)
If you want to backport a patch to the 2.4.x branch just add your proposal to
the STATUS file
as last proposal in the "PATCHES PROPOSED TO BACKPORT FROM TRUNK:" section.
Three committers (that can include you) need to give a +1 vote to the patch and
no -1 must be voted.
Then the patch can be backported.
Keep in mind that backports need to follow the API and ABI rules we have for
stable branches.
In this case this means that new stuff can be added to the API but you cannot
remove or change
existing API's. For ABI compliance it is important to add new members of
structs always to the end of the struct.
If a patch cannot be merged unmodified from trunk please create a patch that
can be merged and either point to
it or create a PR on Github against the 2.4.x branch. Again the scripts in
https://svn.apache.org/repos/asf/httpd/dev-tools/github
are handy for this task.
Regards
Rüdiger
>
> I have the following changes for DAVLockDiscovery:
> r1905327
> r1905230
> r1905229
> r1905206
> r1905170
> r1904662
> r1904638
>
