Module idea to help developers

Module idea to help developers

[Bart Schaefer]

I don't have time to do this myself right now, but:

It would be great if zsh could report something about what patches it has
applied to it.  We could make a little module that implements a special
array parameter `patches', and stick a line in that module to identify each
patch, so that you could "print $patches" to see what was up.

We'd need a convention of some kind -- either it could be up to the patch-
applier to insert the article number by hand, or (better) the patch-maker
should supply a hunk for that module that adds a string he's made up.  Such
a hunk would be likely to fail if some prerequisite patch was not present
(I suppose it would also be likely to fail in some cases of simultaneous
unrelated patching by two developers, but that would be easily resolved),
thus giving a clue about mistakes.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Module idea to help developers

[Clint Adams]

> It would be great if zsh could report something about what patches it has
> applied to it.  We could make a little module that implements a special
> array parameter `patches', and stick a line in that module to identify each
> patch, so that you could "print $patches" to see what was up.

Assuming all these packages will end up in the source, increasing
release frequency or providing CVS snapshots (with the date
automatically appended to the version number) would help a bit.

What you're proposing seems more suited for patches that won't be
incorporated.

Re: Module idea to help developers

[Bart Schaefer]

On Oct 13,  2:42pm, Clint Adams wrote:
} Subject: Re: Module idea to help developers
}
} > We could make a little module that implements a special array
} > parameter `patches', and stick a line in that module to identify
} > each patch
} 
} Assuming all these packages will end up in the source, increasing
} release frequency or providing CVS snapshots (with the date
} automatically appended to the version number) would help a bit.

I agree, but that presupposes a CVS archive, which we've made no progress
on establishing over the last two or three months that it's been under
serious consideration.  The Sunsite Denmark folks are completely silent
(I don't think they're even looking at the zsh-*-owner mail right now)
and PWS is apparently offline for an indeterminate time.  I was hoping
for something quick but effective in the meantime.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Module idea to help developers

[Oliver Kiddle]

Bart Schaefer wrote:

> We could make a little module that implements a special array
> parameter `patches', and stick a line in that module to identify
> each patch

I'm not sure that it would be best implemented as a module - an
increasing amount of zsh seems to be written in shell code and you
wouldn't want to have to recompile the binary just to account for those
patches. It would be just as convenient if you used a simple text file
in the source area to list the patches.

> We'd need a convention of some kind -- either it could be up to the patch-
> applier to insert the article number by hand, or (better) the patch-maker
> should supply a hunk for that module that adds a string he's made up.  Such
> a hunk would be likely to fail if some prerequisite patch was not present

I think it would be rather awkward if the patch-maker had to include a
suitable hunk. Also, the patch-maker wouldn't know the message number so
the patch numbers couldn't correspond to message numbers.

How do you extract patches from e-mails - I'd be inclined to write a
filter which takes the message header to grab the message number and
puts it in a file. It can then also cut out the patch. It'd work quite
conveniently if you used z-mail or mush and their scripting.

> and PWS is apparently offline for an indeterminate time.  I was hoping
> for something quick but effective in the meantime.

If PWS is going to be away for a while then it might help a lot if
someone else releases an intermediate release. I rarely apply c-code
patches because it's not normally a long wait to the next pws release
but I had wanted to apply a couple of Sven's recent patches. I had
little success with this so I'll either have to get all the patches from
the archive or wait.

Oliver Kiddle

CVS again (Re: Module idea to help developers)

[Adam Spiers]

Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
> I agree, but that presupposes a CVS archive, which we've made no progress
> on establishing over the last two or three months that it's been under
> serious consideration.  The Sunsite Denmark folks are completely silent
> (I don't think they're even looking at the zsh-*-owner mail right now)
> and PWS is apparently offline for an indeterminate time.  I was hoping
> for something quick but effective in the meantime.

I have access to a well-specced and reliable RedHat box with a
high-bandwidth connection in the UK, use of which as a temporary
zsh-workers CVS facility would be welcome.  Then when the Sunsite
people re-emerge, it could be moved there if so desired.

Oliver Kiddle (opk@u.genie.co.uk) wrote:
> How do you extract patches from e-mails - I'd be inclined to write a
> filter which takes the message header to grab the message number and
> puts it in a file.

I already did that:

-------- 8< -------- 8< --------
#!/usr/bin/perl -w

use strict;

use Mail::Util qw(read_mbox);
use Mail::Internet;

my $tmp_file = "/tmp/zsh.patch.delivery.$$";
my $dest_dir = '/home/localadams/IN/zsh-patches';

open(TMP, ">$tmp_file") or die $!;
print TMP <>;
close(TMP) or die $!;

my @msgs = read_mbox($tmp_file);

foreach my $msg (@msgs) {
  my $mail = new Mail::Internet $msg;
  if ($mail->head->get('From ') =~ /^zsh-workers-return-(\d+)/) {
    my $id = $1;
    my $dest = "$dest_dir/$id";
    if (-e $dest) {
      warn "File $dest already existed!  Skipping ...\n";
    }
    else {
      open(OUT, ">$dest_dir/$id") or die $!;
      $mail->print(\*OUT);
      close(OUT) or die $!;
    }
  }
  else {
    my $subject = $mail->head->get('Subject');
    warn "Couldn't get id from message `$subject'; discarding.\n";
  }  
}

unlink $tmp_file;

exit 0;
-------- 8< -------- 8< --------

(Temp file security risk ignored 'cos I wrote it for my laptop.)

I also automated the rpm-building process.

> It can then also cut out the patch.

Why bother?  It's nice to keep the text, and patch extracts the patch
automatically anyway.

> > and PWS is apparently offline for an indeterminate time.  I was hoping
> > for something quick but effective in the meantime.

Eek, I hadn't realised.

> If PWS is going to be away for a while then it might help a lot if
> someone else releases an intermediate release. 

Agreed.  Bart? :-)

> I rarely apply c-code patches because it's not normally a long wait
> to the next pws release but I had wanted to apply a couple of Sven's
> recent patches. I had little success with this so I'll either have
> to get all the patches from the archive or wait.

This should be a good kickstart excuse for getting a CVS repository
into action.

Re: CVS again (Re: Module idea to help developers)

[Clint Adams]

> I have access to a well-specced and reliable RedHat box with a
> high-bandwidth connection in the UK, use of which as a temporary
> zsh-workers CVS facility would be welcome.  Then when the Sunsite
> people re-emerge, it could be moved there if so desired.

Since this doesn't seem to be going anywhere..
Maybe you could start by maintaining a unofficial anonymous read-only
repository so people can get a "current" snapshot.

RE: CVS again (Re: Module idea to help developers)

[Andrej Borsenkow]

>
> > I have access to a well-specced and reliable RedHat box with a
> > high-bandwidth connection in the UK, use of which as a temporary
> > zsh-workers CVS facility would be welcome.  Then when the Sunsite
> > people re-emerge, it could be moved there if so desired.
>
> Since this doesn't seem to be going anywhere..
> Maybe you could start by maintaining a unofficial anonymous read-only
> repository so people can get a "current" snapshot.
>

For this to work we need

 ... somebody, who will collect patches and keep CVS in sync

or (better yet)

 ... the key ZSH developers should have write access to repository and do direct
updates there. There is no point in sending patches to list then. Some
announcement/notification is still welcome - e.g. SAMBA has CVS list with commit
messages. But setting up yet another list needs cooperation form Sunsite as well
... sigh.

I opt for the latter. We just need some common framework (branches/tag names
etc). And commit messages may probably go to the zsh-workers (with some special
subject. I believe, it can be setup in CVS).

/andrej

Re: CVS again (Re: Module idea to help developers)

[Clint Adams]

>  ... somebody, who will collect patches and keep CVS in sync

This requires the operation of one person.

>  ... the key ZSH developers should have write access to repository and do direct

This requires the cooperation of many people.

I might be able to get zsh space on cvs.debian.org if that helps
in any way, but it it was my impression that the reason the ball
wasn't rolling was unrelated to system resources.