Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
MIME-Version: 1.0
In-Reply-To: <541959d0-010b-8bd4-80f0-324c73c4e8ce@gmail.com>
References: <20160816222956.6A8653A0224@svn01-us-west.apache.org> <541959d0-010b-8bd4-80f0-324c73c4e8ce@gmail.com>
From: Yann Ylavic <ylavic.dev@gmail.com>
Date: Thu, 18 Aug 2016 13:11:16 +0200
Message-ID: <CAKQ1sVNAKhtf8fvbGv=wL4M3gonP9mNMQ=D=fhc1XcfLi-sf2Q@mail.gmail.com>
Subject: Re: svn commit: r1756556 - /httpd/httpd/branches/2.4.x/STATUS
To: httpd-dev <dev@httpd.apache.org>
Content-Type: text/plain; charset=UTF-8
archived-at: Thu, 18 Aug 2016 11:11:52 -0000

On Wed, Aug 17, 2016 at 7:08 PM, Jacob Champion <champion.p@gmail.com> wrote:
>
> What's the procedure for dealing with this in STATUS when I propose
> something? A 2.4.x patch hosted... somewhere?

Yes, you can propose a branch merge in a standalone patch, and give a
link to it in a "2.4.x patch: ..." line (otherwise, this line is
usually "trunk works [modulo CHANGES/MMN --which the "merger" can
easily resolve itself]".

That way, the votes refer to the proposed patch, finally simply
applied on the branch (with --record-only for the mergeinfo of trunk
commits).

For hosting the patches, it's either an external address (lifetime of
the vote, at least ;) or your own Apache space at
home.apache.org/~yourid/ (you may want to configure your SSH
authorized_keys line on id.apache.org to be able to access it via
sftp).


> Or do we just rely on proper
> manual resolution by whoever merges the patches?

Ouch, no one would want to merge :)
Also, votes wouldn't always correspond to the result...


Regards,
Yann.