Wow, I go home for the night and next morning there's a tsunami of
email. I'm not objecting - it's good to see it all happening. Rather
than replying to several threads individually, I'm going to put
everything I want to say into a single message. I hope that's OK.
* My immediate manager is quite happy for the PCRE project to use
sesame.csx.cam.ac.uk in the same way as the Exim project does. The
higher management will be asked to rubber stamp this next Tuesday, but
I think we can proceed on the assumption that there will be no
objection.
My choice would be to go for sesame over code.google (sorry Craig) on
the basis that it's something that I'm familiar with, and we have at
least one volunteer (thanks Nigel!) to do some of the set up.
Anybody want to shout against that?
* There seems to be a definite feeling that SVN is an acceptable and
good way to go, and Nigel has volunteered to set it up. So let's go
for that, shall we? I agree that we should arrange anonymous read
access if we can, with SSH accounts needed for developers.
* I agree with Daniel (and disagree with Bob) that the PCRE project is
not big enough to need heavyweight formal arrangements, either for
"who may commit what" or for licensing. The Exim project is much
bigger, and hasn't gone down either of those roads.
PCRE development has been very sporadic. Unlike Exim, where people are
sending in patches and suggestions for new functionality all the time,
PCRE has gone for long periods where nothing has happened. There may
be the occasional bug, but nothing more. Then there's a burst of new
ideas and functionality (like the 7.0 additions) and I work on it for
a couple of weeks, after which it all goes quiet again for months. I
think lightweight arrangements are appropriate for this kind of
project.
* Web site: Andrew Ho, manager of the existing web site, is here.
Andrew, you didn't express any opinion about moving the web site onto
the same box as everything else. Do you have a view?
* autogen.sh: Daniel has a good point about accessing options for the
separate tools, and that people may expect to find autogen.sh. So
let's keep it for now.
* FreeBSD has printf(1) and its man page says it originated in
4.3BSD-Reno, so it looks as though using it is OK.
* Bob asked about test failures: certainly the tests will fail if you
set the ebcdic option on an ascii host. I have no way of testing that
option. As for the others, I'm not sure. I promise to check them all
out when I get control of the source back.
* The progression: patch 6 (Bob) -> patch 7 (Daniel) -> 7.1-RC1 (me)
seems the right way to go. It looks as though it's happening. I will
experiment with both patch 6 and patch 7 later today and see if I come
up with any issues. I get the feeling that Bob and Daniel have mostly
done what they wanted by now - maybe it is now time for me to take it
all back, apply it to my master sources, and then see if there's
anything I don't like. Say when...
* The fact that Daniel's patch didn't apply cleanly for me may have been
because it got mangled in some way in transit. It's not a big issue in
any case because I sorted things out. We are not going to make any of
these patches public.
* Dates: I can see Craig's objection to 2006-Dec-22. I suppose people
will not be confused by 2007-02-04 but, for myself, I would have to
spend just an ounce of brainpower doublechecking that I hadn't
misunderstood it. Whereas with 2007-Feb-04 or my original 04-Feb-2007
I would not. Or even Feb-04-2007. But standards are standards, so I
won't object to 2007-02-04.
* Daniel wrote this:
* Changed --disable-stack-for-recursion to
--enable-stack-for-recursion, as this is "no" by default.
NO! The default must be to enable the use of the stack for recursion.
Otherwise the performace degrades by 30% or so. Please reverse this
change.
* I don't think we should change the --enable-newline settings, for
compatibility reasons. It may be tidier, but it seems gratuitous.
Philip
--
Philip Hazel, University of Cambridge Computing Service.
