Re: Can't get a patch through because of weekly development releases.

[Carl Sorensen]

On 7/14/10 2:46 AM, "Graham Percival" <address@hidden> wrote:

> On Wed, Jul 14, 2010 at 08:47:17AM +0200, David Kastrup wrote:
>> Graham Percival <address@hidden> writes:
>> 
>>> If you have the patch as a single file, then (in vim) it would be
>>>   %s/2.13.28/2.13.29/g
>>> 
>>> But if you're working on a separate branch (as is right and proper
>>> for a major change), then I'm not certain how to go about it.  I'm
>>> looking forward to opinions.
>> 
>> I don't see a problem here.  Just merge origin/master into your work
>> branch occasionally, then the patch will be relative to the current
>> version.
> 
> The problem is the convert-ly rule for the changed syntax -- if he
> wrote the rule for 2.13.25 but doesn't merge until 2.13.29, then
> convert-ly will have an incorrect version.  This also applies to
> the version number in input/regression/ files.
> 
> I'm not entirely certain why he's changing the version number in
> Documentation/ files, since those should be updated by running
> convert-ly on them (followed by any manual changes that are
> necessary)... but here we're in uncharted and definitely
> disorganized territory.

Because the convert-ly rules are manual rules, so doing convert-ly doesn't
do any good.  And I'm trying to keep the changes to only the necessary files
for patch review.  For example, I don't run makelsr.py, then upload the
patch (because *all* of the snippets will be changed, not just the ones I
changed for the patch).

So I already have to get the code all patched, do a git commit, do
makelsr.py, make && make doc, make check.  Then I do git reset --hard HEAD,
git-cl upload master, and wait for a review.

So for this type of patch, the overhead is quite substantial.  I'm thinking
of writing a script that will do the version update automatically, but I
haven't done it yet...

Thanks,

Carl