Re: allout update checkin questions

[ken manheimer]

On Wed, Feb 18, 2009 at 9:58 PM, Stefan Monnier
<address@hidden> wrote:

> > First, I'm frankly clueless about use of checkin tags and branches in
> > the emacs project.  i would like my current batch of revisions to be
> > included in the next emacs point release.  is there a particular
> > branch or tag i should be using on my checkin?  in general, where
> > should i be looking to see info for elisp developers about the current
> > emacs checkin branching/release practices?
>
> There is no branch yet for the code "after 23.1".
> I suggest you create a branch on the allout.el file.  Most CVS primers
> should be able to tell you how to do that.

sorry, i was unclear.  i'm well acquainted with using CVS.  what i'm
clueless about are the emacs checkin and release protocols, and i have
completely failed to find guidance docs.

specifically, i'd like to know where to look for things like what the
current development branch is, what to do to nominate something for
release, who to talk to about questions and concerns, etc.  a while
back i spent some time looking for developer guidance documents on
savannah, but that didn't help at all - maybe i missed something, or
maybe it's been added since.  is there a canonical collection of
instructions, or even some generally used guidance docs?

> E.g. something like:
>
>  cvs tag ALLOUT_WORK_BASE allout.el
>  cvs tag -b ALLOUT_WORK allout.el
>
> will create the branch (together with a tag that keeps track of the base
> of the branch, which you can move if/when you sync your code with the
> trunk code) and then
>
>  cvs update -r ALLOUT_WORK allout.el
>
> will get you the ALLOUT_WORK version of allout.el and commits on it will
> go to that branch.

i use my own CVS repository for my personal development.  i can
checkin changes to a gnu repository branch, tagged as you suggest,
when i release my changes from my own repository to the gnu one.

> > also, i notice that the currently checked in allout version excludes
> > some small xemacs compatability provisions, and am wondering why that
> > was done.  specifically, there were numerous:
> >
> >    (local-variable-p varname (current-buffer))
> >
> > that were replaced by:
> >
> >    (local-variable-p varname)
>
> Sounds like mistakes.  Feel free to change the code to be more
> compatible with XEmacs.
>
> > I have let XEmacs compatibility slide, but in general see no reason to
> > deliberately introduce incompatibility.
>
> Neither do I.

great!

thanks!
--
ken
http://myriadicity.net