allout update checkin questions

allout update checkin questions

[ken manheimer]

hi, all!

i'm working on a few allout changes and have a few incidental
procedural questions.

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?

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)

in (i think, current) xemacs, the buffer argument is not optional, so
this specifically introduced incompatibilities, for no purpose i can
see.  i would like to reestablish that provision in the allout version
i checkin.  is this somehow contrary to policy/practice?  i have let
xemacs compatibility slide, but in general see no reason to
deliberately introduce incompatibility.

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

Re: allout update checkin questions

[Stefan Monnier]

> 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.
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.

> 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.


        Stefan

Re: allout update checkin questions

[ken manheimer]

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

Re: allout update checkin questions

[Glenn Morris]

ken manheimer wrote:

> specifically, there were numerous:
>
>    (local-variable-p varname (current-buffer))
>
> that were replaced by:
>
>    (local-variable-p varname)

These lines are unchanged since you supplied them in July 2006:

http://lists.gnu.org/archive/html/emacs-devel/2006-07/msg00547.html

Re: allout update checkin questions

[ken manheimer]

(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

Re: allout update checkin questions

[ken manheimer]

On Thu, Feb 19, 2009 at 1:57 PM, Glenn Morris <rgm@gnu.org> wrote:

> ken manheimer wrote:
>
>> specifically, there were numerous:
>>
>>    (local-variable-p varname (current-buffer))
>>
>> that were replaced by:
>>
>>    (local-variable-p varname)
>
> These lines are unchanged since you supplied them in July 2006:
>
> http://lists.gnu.org/archive/html/emacs-devel/2006-07/msg00547.html

hmm - i added them to my development copy a year ago, i'm surprised to
think i've not re-released since then!  sorry about the false alarm!
-- 
ken
http://myriadicity.net

Re: allout update checkin questions

[Stefan Monnier]

> sorry, i was unclear.  i'm well acquainted with using CVS.

Great!

> What i'm clueless about are the emacs checkin and release protocols,
> and i have completely failed to find guidance docs.

There's nother written down.  But you asked at the right place (sorry
for not understanding at first).  Development of "future code" always
takes place on the CVS trunk.  At times, the trunk is not open for
random updates, this is the case right now for example because we're in
pretest, so only bug-fix should be installed on the trunk.  Later during
the pretest (probably not much before the actual release), we will
create a branch for the Emacs-23 release, at which point the trunk will
be open again for non-bugfix changes.

The intension of restricting the trunk to bugfixes and to try and focus
people on fixing bugs.

Note that we will likely switch over to Bzr around the time of the
release or around the time when we create the Emacs-23 release branch.


        Stefan

Re: allout update checkin questions

[Stefan Monnier]

> (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

The development always takes place on the trunk (which is often
misnamed "HEAD").


        Stefan