Re: allout update checkin questions

[ken manheimer <ken.manheimer@gmail.com>]

(i should add, regardless of checkin privileges, i've searched on
various occasions for info about which branch or tag to use when
checking out the development emacs, and always wind up just guessing
at HEAD and/or what a particular release identifier might be.  i may
well be missing something obvious, but it would have helped me to have
this kind of developer guidance / procedural descriptions linked to
the savannah project home page, and i expect that others would find it
useful, too.)

On Thu, Feb 19, 2009 at 1:43 PM, ken manheimer <ken.manheimer@gmail.com> wrote:
> On Wed, Feb 18, 2009 at 9:58 PM, Stefan Monnier
> <monnier@iro.umontreal.ca> 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
>



-- 
ken
http://myriadicity.net