next release

next release

[Zefram]

Just to let you know, I will be releasing zsh-3.1.5 sometime this week.
I think it's long enough overdue.  I still have a couple of pending
patches to merge, but if I can't find the time in the next couple of
days I'll release it without them.

Those people that have been having problems with ut_xtime on HP-UX:
I've added a new autoconf test that should detect whether the ut_xtime
member is actually available.  A couple of people have posted indicating
that the actual struct member to use is ut_tv.tv_sec.  Can someone tell
me whether this is the *only* name for the correct member, or is there
a definition for ut_time in the system header?

-zefram

Re: next release

[Peter Stephenson]

"Zefram" wrote:
> Those people that have been having problems with ut_xtime on HP-UX:
> I've added a new autoconf test that should detect whether the ut_xtime
> member is actually available.  A couple of people have posted indicating
> that the actual struct member to use is ut_tv.tv_sec.  Can someone tell
> me whether this is the *only* name for the correct member, or is there
> a definition for ut_time in the system header?

Here's the definition of struct utmpx from utmpx.h on a HP-UX B.10.20
machine (dunno if the B. is important).  There's a lot of conditional
compilation but there's no sign of ut_time, only ut_tv; same elsewhere
in utmpx.h. ut_time is present in struct utmp defined in utmp.h,
however.


struct utmpx
  {
        char ut_user[24] ;              /* User login name */
        char ut_id[4] ;                 /* /etc/lines id(usually line #) */
        char ut_line[12] ;              /* device name (console, lnxx) */
        pid_t ut_pid ;                  /* process id */
        short ut_type ;                 /* type of entry */

        struct __exit_status
#ifndef _STRUCT___EXIT_STATUS
#  define _STRUCT___EXIT_STATUS
          {
            short __e_termination ;
            short __e_exit ;
          }
#endif /* _STRUCT___EXIT_STATUS */
        ut_exit;

        unsigned short ut_reserved1 ;   /* Reserved for future use */
        struct timeval
#ifndef _STRUCT_TIMEVAL
#  define _STRUCT_TIMEVAL
        {
          time_t                         tv_sec;                /* seconds */
          long          tv_usec;        /* and microseconds */
        }
#endif /* _STRUCT_TIMEVAL */
        ut_tv;                  /* time entry was made */

        char ut_host[64] ;              /* host name, if remote; 
                                           NOT SUPPORTED */
        unsigned long ut_addr ;         /* Internet addr of host, if remote */
        char ut_reserved2[12] ; /* Reserved for future use */
  } ;

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarotti 2, 56100 Pisa, Italy

Re: next release

[Geoff Wing]

Peter Stephenson <pws@ibmth.df.unipi.it> typed:
:> I've added a new autoconf test that should detect whether the ut_xtime
:> member is actually available.  A couple of people have posted indicating
:> that the actual struct member to use is ut_tv.tv_sec.  Can someone tell
:> me whether this is the *only* name for the correct member, or is there
:> a definition for ut_time in the system header?
:Here's the definition of struct utmpx from utmpx.h on a HP-UX B.10.20
:machine (dunno if the B. is important).  There's a lot of conditional
:compilation but there's no sign of ut_time, only ut_tv; same elsewhere
:in utmpx.h. ut_time is present in struct utmp defined in utmp.h,
:however.

utmpx on:
  Digital Unix 4.0D: ut_tv.tv_sec
  Solaris 2.5: ut_xtime (is defined as ut_tv.tv_sec)
-- 
Geoff Wing   <gcw@pobox.com>            Mobile : 0412 162 441
Work URL: http://www.primenet.com.au/   Ego URL: http://pobox.com/~gcw/

Next release

[Peter Stephenson]

As 4.3 seems to be pretty stable I'd like to release 5.0 shortly without
any further major changes.  The release number won't change until I
actually do that --- the policy is that version numbers always
increment, so 5.0_mumble comes after 5.0 --- although nearer the time
when everything looks ready I may bump the number to 4.99-test-X for the
final test releases just to indicate the intention.

The only significant thing to do for this is rework the source
documentation (NEWS, release notes, etc.) to show changes since 4.2
rather than within 4.3.  If anyone thinks they can make a good attempt
at this, they're welcome.  Otherwise, I will try to make a start on
that.

It would also be useful to document any bugs or major unexpected
restrictions that aren't already documented.  I'm aware of a couple of
weak areas in completion: correspondence classes don't handle multibyte
characters, and nested quoted completion where the contents of the
quotes are interpreted non-trivial (e.g. as a command line by a call to
another shell) are buggy.  This is *not* a call for feature requests.
Any undocumented derogations from POSIX behaviour can be added to the
FAQ.

If you think there's anything significant left to do, it would be a good
time either to do it or try to persuade someone else (good luck with
that).

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

Re: Next release

[Bart Schaefer]

On Dec 9,  2:11pm, Peter Stephenson wrote:
}
} If you think there's anything significant left to do, it would be a good
} time either to do it or try to persuade someone else (good luck with
} that).

I still have uncommitted the change to add $state_descr to _arguments
and _values and reference it in _zle (workers/29766).  Do we want?

I also have workers/29049 (attempt to restore command line when canceling
out of menu-select) but I don't think it's actually correct.

Re: Next release

[Peter Stephenson]

On Fri, 9 Dec 2011 08:37:14 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> I still have uncommitted the change to add $state_descr to _arguments
> and _values and reference it in _zle (workers/29766).  Do we want?

Seems reasonable to include it, given that the shell probably isn't
going to be come object-orientated any time soon.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

Re: Next release

[Frank Terbeck]

Peter Stephenson wrote:
> As 4.3 seems to be pretty stable I'd like to release 5.0 shortly without
> any further major changes.
[...]

While this is coming up, I'd like to bring up the following from a mail from
Peter in January of the year¹:

[...]
| CVS is still down.  It sounds like it's probably time to move to git
| after the next stable release, nobody's suggested replacing it with an
| even more trendy system yet...
[...]

I don't know if that's still something people want. But I thought I'd bring
it up again anyway. FWIW, the FVWM folks were planning a similar move and
one of their developers (Thomas Adam) wrote a lengthy mail describing how
it could work:

  <http://www.mail-archive.com/fvwm-workers@fvwm.org/msg02470.html>

They had a similar starting point as zsh has. One major development branch
in CVS and a working git mirror in place.

Thomas later followed up on himself with the following mail regarding the
ChangeLog file:

  <http://www.mail-archive.com/fvwm-workers@fvwm.org/msg02471.html>

...and I couldn't agree more.

I don't know if dropping the stable- vs development versions, is something
that would work for zsh (although I think it could - everybody uses 4.3.x
anyway) and I also don't know if there would be as much use of public topic
branches as Thomas suggests, because that probably only makes sense when
big features are being added. But all in all, I think he makes a lot of
relevant points that might be transferable to zsh development as well.

If there is someone who doesn't know zsh has a working git mirror, yet,
the browsable gitweb is here:

  <http://zsh.git.sourceforge.net/git/gitweb.cgi?p=zsh/zsh>

and the clone address is this:

  <git://zsh.git.sf.net/gitroot/zsh/zsh>

Regards, Frank

¹ <http://www.zsh.org/mla/workers//2011/msg00109.html>

Re: Next release

[Peter Stephenson]

On Fri, 09 Dec 2011 20:50:27 +0100
Frank Terbeck <ft@bewatermyfriend.org> wrote:
> I don't know if that's still something people want. But I thought I'd bring
> it up again anyway. FWIW, the FVWM folks were planning a similar move and
> one of their developers (Thomas Adam) wrote a lengthy mail describing how
> it could work:
> 
>   <http://www.mail-archive.com/fvwm-workers@fvwm.org/msg02470.html>
> 
> They had a similar starting point as zsh has. One major development branch
> in CVS and a working git mirror in place.

I think it's generally felt moving to git would be sensible and wouldn't
be too much work, given what's already been done with the mirror.

That message seems to be mostly about branch structure which isn't
really relevant to us; our case is much simpler.  Obviously the ease of
people having their own private areas without reference to the main
repository is a big gain, but that's up to them.
 
> Thomas later followed up on himself with the following mail regarding the
> ChangeLog file:
> 
>   <http://www.mail-archive.com/fvwm-workers@fvwm.org/msg02471.html>
> 
> ...and I couldn't agree more.

I'd prefer to have the ChangeLog, at least to begin with.  I find it
much more visible; I'm planning to spend as little time as I can playing
with source control, whose job is to stay in the background while I look
at the files (and I find git infuriatingly geeky).  If we get rid of it
on a day-to-day basis, we would need to get into the habit of including
all the same information in commits --- which is a perfectly reasonable
aim, particularly when the notion of changesets becomes meaningful.
Generating it at the time of a release rather than immediately might be
something to aim at.  If we get to the point where we have a simple
utility (i.e. doesn't demand detailed knowledge of git) that can
generate a readable one, that becomes possible.

> I don't know if dropping the stable- vs development versions, is something
> that would work for zsh (although I think it could - everybody uses 4.3.x
> anyway)

We've only had separate development branches when needed for long term
work on particular features, first ZLE widgets and then multibyte
characters.  I don't think there's any call for a separate branch after
the next stable release is made --- though it would be good to get test
releases spread a bit further than at present.  I wonder if it would be
sensible to use the Sourceforge zsh-dev area for those.

> and I also don't know if there would be as much use of public topic
> branches as Thomas suggests, because that probably only makes sense when
> big features are being added. But all in all, I think he makes a lot of
> relevant points that might be transferable to zsh development as well.

Feel free to bring up anything you think is relevant --- other than the
basic move I didn't see much that seemed to affect our much simpler case
--- but obviously anything that makes administration more complicated is
out (there's no reason moving to git should generally have that effect,
though).

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: Next release

[Frank Terbeck]

Peter Stephenson wrote:
> Frank Terbeck <ft@bewatermyfriend.org> wrote:
[...]
> That message seems to be mostly about branch structure which isn't
> really relevant to us; our case is much simpler.  Obviously the ease of
> people having their own private areas without reference to the main
> repository is a big gain, but that's up to them.

FVWM is pretty much in maintenance-only mode for a while now, so that
mail was merely to show possible development models, which might be a
helpful insight given that not everybody uses git regularly.

>> Thomas later followed up on himself with the following mail regarding the
>> ChangeLog file:
>> 
>>   <http://www.mail-archive.com/fvwm-workers@fvwm.org/msg02471.html>
>> 
>> ...and I couldn't agree more.
>
> I'd prefer to have the ChangeLog, at least to begin with.  I find it
> much more visible;

Really? I find manual ChangeLog updates (even with the help of emacs'
`add-change-log-entry') to be the single most annoying thing about CVS
from a mere user's perspective, because it doesn't work with changesets.

It also makes merging different changes virtually impossible, because
there will always be a conflict at the top of the ChangeLog file
(although I hear people have automatic merge drivers for that now¹).

> I'm planning to spend as little time as I can playing
> with source control, whose job is to stay in the background while I look
> at the files (and I find git infuriatingly geeky).  If we get rid of it
> on a day-to-day basis, we would need to get into the habit of including
> all the same information in commits --- which is a perfectly reasonable
> aim, particularly when the notion of changesets becomes meaningful.
> Generating it at the time of a release rather than immediately might be
> something to aim at.  If we get to the point where we have a simple
> utility (i.e. doesn't demand detailed knowledge of git) that can
> generate a readable one, that becomes possible.

Yes, ChangeLog conversion could be automated from the output of "git
log". A one line approach might be as "easy" as this:

 git --no-pager log --format="%ai %aN %n%n%x09* %s%d%n" $(git describe --abbrev=0)..

...which would make for a nice alias in ~/.gitconfig. But the result
could be better. And people have done better. That's not rocket science.
Either we use an existing script from someone else, or we cook up one of
our own.

>> I don't know if dropping the stable- vs development versions, is something
>> that would work for zsh (although I think it could - everybody uses 4.3.x
>> anyway)
>
> We've only had separate development branches when needed for long term
> work on particular features, first ZLE widgets and then multibyte
> characters.
[...]

Agreed. And even if we'd need a feature branch for stuff like that, it's
extremely easy to one such branch in git (as Thomas from FVWM outlined
in his mail).

[...]
> Feel free to bring up anything you think is relevant --- other than the
> basic move I didn't see much that seemed to affect our much simpler case
> --- but obviously anything that makes administration more complicated is
> out (there's no reason moving to git should generally have that effect,
> though).

Yes. Git can be used with an CVS-like workflow to a central server just
fine. And almost exactly the same way as with CVS (except that you make
a commit locally first and push the complete commit over to the server
after that).

It's absolutely up to the individual developer to decide how much of
git's feature-set he/she wants to use locally.

I also think that there are quite a number of apt git users on -workers,
who should be able to assist if something odd comes up (which may or may
not happen).


As for the actual move to git: Wayne is keeping the CVS repository in
sync pretty darn well and I guess it's just a setting somewhere in the
sourceforge configuration to turn off CVS commits and enable commit
pushing into the git repository. I don't know the sourceforge admin
interface, but I'm sure Wayne will have a pretty good idea on how to do
that final switch-over.


Regards, Frank

¹ <http://gcc.gnu.org/wiki/GitMirror#git-merge-changelog> (I didn't try
  that one)

Re: Next release

[Peter Stephenson]

On Sat, 10 Dec 2011 20:20:10 +0100
Frank Terbeck <ft@bewatermyfriend.org> wrote:
> Yes, ChangeLog conversion could be automated from the output of "git
> log". A one line approach might be as "easy" as this:
> 
>  git --no-pager log --format="%ai %aN %n%n%x09* %s%d%n" $(git describe --abbrev=0)..
> 
> ...which would make for a nice alias in ~/.gitconfig. But the result
> could be better. And people have done better. That's not rocket science.
> Either we use an existing script from someone else, or we cook up one of
> our own.

I think when we can get to the point where I can type
"Util/changelog.sh", or whatever, and recreate the ChangeLog since the
last release, or the release label/change specified as an argument, I
will be entirely happy.  However, that's a prerequisite, rather than a
reason, for abandoning it.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: Next release

[Frank Terbeck]

Peter Stephenson wrote:
> I think when we can get to the point where I can type
> "Util/changelog.sh", or whatever, and recreate the ChangeLog since the
> last release, or the release label/change specified as an argument, I
> will be entirely happy.  However, that's a prerequisite, rather than a
> reason, for abandoning it.

That should not be a problem. And obviously, if you'd still like to keep
a manual ChangeLog after all, I won't complain. That way I'll get to try
that merge-driver. ;)

Regards, Frank

Re: Next release

[Phil Pennock]

On 2011-12-09 at 14:11 +0000, Peter Stephenson wrote:
> It would also be useful to document any bugs or major unexpected
> restrictions that aren't already documented.

I only implemented metafy/unmetafy for the zsh/pcre module, not the
zsh/regex module which provides the system extended regexp support.

% [[ → =~ ^(.) ]] && print $match
→
% unsetopt rematchpcre
% [[ → =~ ^(.) ]] && print $match
?
%

On the same box, bash (not using PCRE):
$ [[ → =~ ^(.) ]] && echo $BASH_REMATCH
→
$

So clearly the system regex library can handle UTF-8 just fine on this
box, so I have a place to test and might get around to it sometime soon.

-Phil