Re: LSR updates

[Phil Holmes]

----- Original Message ----- 
From: "David Kastrup" <address@hidden>
To: "Phil Holmes" <address@hidden>
Cc: <address@hidden>
Sent: Friday, July 18, 2014 1:06 PM
Subject: Re: LSR updates


> "Phil Holmes" <address@hidden> writes:
>
> > ----- Original Message ----- 
> > From: "David Kastrup" <address@hidden>
> > To: "Phil Holmes" <address@hidden>
> > Cc: <address@hidden>
> > Sent: Friday, July 18, 2014 11:26 AM
> > Subject: Re: LSR updates
> >
> >
> > > "Phil Holmes" <address@hidden> writes:
> > >
> > > > ----- Original Message ----- 
> > > > From: "David Kastrup" <address@hidden>
> > > > To: "Phil Holmes" <address@hidden>
> > > > Cc: <address@hidden>
> > > > Sent: Thursday, July 17, 2014 12:07 PM
> > > > Subject: Re: LSR updates
> > > >
> > > >
> > > > > Phil Holmes <address@hidden> writes:
> > > > >
> > > > > > I'm starting work on bringing the snippets in git up to date to match
> > > > > > those in the LSR.  Stage one is to change the LSR address of dsi
> > > > > > to di in
> > > > > > them all and to bring their version numbers up to 2.18.0.  This
> > > > > > isn't best
> > > > > > done with makelsr because it does not blindly update sll the 
> > > > > > snippets,
> > > > > > which is what we want.
> > > > >
> > > > > Uh, why would we want this?  convert-ly was changed _exactly_ because 
> > > > > we
> > > > > don't want the version numbers to be updated blindly.
> > > >
> > > >
> > > > Running convert-ly as part of makelsr updated quite a lot, but not
> > > > all.
> > >
> > > Which is as intended.
> > >
> > > > Given that the LSR is now at version 2.18, it seems best to put all
> > > > the snippets at a consistent version, using 2.18 commands.
> > >
> > > At the current point of time it is no longer possible to run makelsr
> > > without having all versions for which there is a
> > > Documentation/snippets/new getting reset to an earlier version.  This
> > > precludes me from being able to push issue 3998.  Also you failed to
> > > update the "Note: this file works from version x.xx.x" comments.
> > >
> > > The current situation is quite a mess.  I don't understand why you could
> > > not be bothered to go through the regular procedure for an invasive
> > > change like that and provided just few hours of warning and no patch to
> > > review.
> > >
> > > I suggest that we revert the respective commit while it can be done
> > > reasonably cleanly and then proceed in a less helterskelter manner.
> >
> >
> > Well - the next part of my aim is to go through all the snippets/new
> > and update the version in the LSR to match the version in snippets/new
> > and then delete the version in /new (unless it requires 2.19 +).  But
> > that will take time.  It seemed preferable to have a consistent
> > baseline to work form.
>
> But Documentation/snippets is not the baseline.  It's pretty much
> completely a generated directory.  The baseline is the LSR after running
> convert-ly on it, with Documentation/snippets/new acting as override.
>
> So what you want to be doing is another LSR import from the current LSR
> first.  Then one has to check which of Documentation/snippets/new is no
> longer needed and can be removed, and which should be retained and/or
> merged with the LSR.
>
> Unless I totally misunderstand something here.


OK.  I'll create a new patch with the updated LSR address change only. 
However, before running a makelsr run from the LSR, I'll need to do some 
further checks on the changes makelsr is making to the snippets, and 
preferably get snippets/new in shape.

Please revert this.

--
Phil Holmes