On 17/07/2018 11:24, Branko Čibej wrote:
> On 17.07.2018 11:17, Stefan wrote:
>> That said, if the majority of the team is fine with a change, so will
>> I be in the end and won't argue against it.
> Correction: not "if the majority of the team etc." but "if the consensus
> of the team is etc." We
On Mon, Jul 16, 2018 at 05:49:53PM +0100, Julian Foad wrote:
> Julian Foad wrote:
> > Stefan Sperling wrote:
> > >I ran a sync merge from trunk/CHANGES to branch/CHANGES, and manually
> > >deleted any entries above the one for the release being prepared.
> > >
> > >This worked quite well for me and
On 17.07.2018 11:17, Stefan wrote:
> That said, if the majority of the team is fine with a change, so will
> I be in the end and won't argue against it.
Correction: not "if the majority of the team etc." but "if the consensus
of the team is etc." We don't do majority votes here. :)
-- Brane
On 17/07/2018 10:37, Branko Čibej wrote:
> On 17.07.2018 10:05, Johan Corveleyn wrote:
>> On Tue, Jul 17, 2018 at 9:03 AM, Branko Čibej wrote:
>>> On 16.07.2018 21:46, Johan Corveleyn wrote:
(why would CHANGES in a 1.9.x tarball need to contain changes of the
1.8 line?)
>>> Because I, as
On 17.07.2018 10:05, Johan Corveleyn wrote:
> On Tue, Jul 17, 2018 at 9:03 AM, Branko Čibej wrote:
>> On 16.07.2018 21:46, Johan Corveleyn wrote:
>>> (why would CHANGES in a 1.9.x tarball need to contain changes of the
>>> 1.8 line?)
>> Because I, as an admin, want to see the whole relevant histor
On Tue, Jul 17, 2018 at 9:03 AM, Branko Čibej wrote:
> On 16.07.2018 21:46, Johan Corveleyn wrote:
>> (why would CHANGES in a 1.9.x tarball need to contain changes of the
>> 1.8 line?)
>
> Because I, as an admin, want to see the whole relevant history in
> CHANGES when something breaks and I have
On 16.07.2018 21:46, Johan Corveleyn wrote:
> (why would CHANGES in a 1.9.x tarball need to contain changes of the
> 1.8 line?)
Because I, as an admin, want to see the whole relevant history in
CHANGES when something breaks and I have to fix it.
Johan Corveleyn wrote on Mon, 16 Jul 2018 21:46 +0200:
> (why would CHANGES in a 1.9.x tarball need to contain changes of the
> 1.8 line?)
I see no reason for a 1.9.x tarball to contain the CHANGES stanzas of
1.8.y with y>1, since the contents of those sections are repeated under
1.9.x sections, b
On Mon, Jul 16, 2018 at 6:57 PM, Daniel Shahaf wrote:
> Julian Foad wrote on Mon, 16 Jul 2018 17:49 +0100:
>> Actually the "sync merge" way isn't as automatic as I would like. The
>> merge always conflicts when there is a new or modified trunk CHANGES
>> entry for 1.10.x. Maybe --accept=mine-confl
Julian Foad wrote on Mon, 16 Jul 2018 17:49 +0100:
> Actually the "sync merge" way isn't as automatic as I would like. The
> merge always conflicts when there is a new or modified trunk CHANGES
> entry for 1.10.x. Maybe --accept=mine-conflict would completely solve
> that. Haven't tested that.
Julian Foad wrote:
> Stefan Sperling wrote:
> >I ran a sync merge from trunk/CHANGES to branch/CHANGES, and manually
> >deleted any entries above the one for the release being prepared.
> >
> >This worked quite well for me and I never found it burdensome.
>
> That, or scripting that as Johan sugge
On 13.07.2018 19:43, Daniel Shahaf wrote:
> Julian Foad wrote on Fri, 13 Jul 2018 17:12 +0100:
>> $ svn ls ^/subversion
>> README
>> branches/
>> developer-resources/
>> site/
>> site-ng/
>> svn-logos/
>> tags/
>> trunk/
>> upstream/
>>
>> Brane's suggestion of locating CHANGES in the web site tree
On 14 July 2018 09:08:12 BST, Stefan Sperling wrote:
>On Fri, Jul 13, 2018 at 05:12:04PM +0100, Julian Foad wrote:
>> I guess previous release managers merged the relevant changes
>manually to achieve this.
>
>I ran a sync merge from trunk/CHANGES to branch/CHANGES, and manually
>deleted any entri
On Fri, Jul 13, 2018 at 05:12:04PM +0100, Julian Foad wrote:
> I guess previous release managers merged the relevant changes manually to
> achieve this.
I ran a sync merge from trunk/CHANGES to branch/CHANGES, and manually
deleted any entries above the one for the release being prepared.
This wo
On 13/07/2018 18:12, Julian Foad wrote:
> Stefan Hett wrote:
>> On 7/13/2018 4:28 PM, Branko Čibej wrote:
>>> On 13.07.2018 16:19, Julian Foad wrote:
svn ps svn:externals '^/subversion/CHANGES CHANGES' trunk-wc/.
>>> This would be mildly horrible as it would show up in release branches
>>>
Julian Foad wrote on Fri, 13 Jul 2018 17:12 +0100:
> $ svn ls ^/subversion
> README
> branches/
> developer-resources/
> site/
> site-ng/
> svn-logos/
> tags/
> trunk/
> upstream/
>
> Brane's suggestion of locating CHANGES in the web site tree makes quite
> good sense to me too, although as long
Stefan Hett wrote:
> On 7/13/2018 4:28 PM, Branko Čibej wrote:
> > On 13.07.2018 16:19, Julian Foad wrote:
> >>svn ps svn:externals '^/subversion/CHANGES CHANGES' trunk-wc/.
> > This would be mildly horrible as it would show up in release branches
> > and become part of the release. Up to now,
On 7/13/2018 4:28 PM, Branko Čibej wrote:
On 13.07.2018 16:19, Julian Foad wrote:
Our releasing docs say, "CHANGES should always be edited on trunk and then merged
over to the release branch(es)". The 'CHANGES' file in 1.10.1 doesn't have the
latest two fixes that were merged to 1.10.x last ni
On 13.07.2018 16:19, Julian Foad wrote:
> Our releasing docs say, "CHANGES should always be edited on trunk and then
> merged over to the release branch(es)". The 'CHANGES' file in 1.10.1 doesn't
> have the latest two fixes that were merged to 1.10.x last night, because I
> missed manually re-ex
Our releasing docs say, "CHANGES should always be edited on trunk and then
merged over to the release branch(es)". The 'CHANGES' file in 1.10.1 doesn't
have the latest two fixes that were merged to 1.10.x last night, because I
missed manually re-executing that step.
Possible improvements:
1) Ha
20 matches
Mail list logo
