You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by André Malo <nd...@perlig.de> on 2003/05/30 02:34:12 UTC
Re: cvs commit: httpd-2.0/docs/manual/vhosts details.html.en details.html.ko.euc-kr examples.html.en examples.html.ko.euc-kr fd-limits.html.en fd-limi
* Aaron Bannert wrote:
> On Thursday, May 29, 2003, at 12:30 PM, nd@apache.org wrote:
>
>> Modified: docs/manual Tag: APACHE_2_0_BRANCH bind.html.en
>> bind.html.ja.jis bind.html.ko.euc-kr
>> cgi_path.html.en cgi_path.html.ja.jis
>> cgi_path.html.ko.euc-kr configuring.html.en
> [...]
>
> I've been trying to hold my tongue on this, but I can't any longer.
> Is there something we can do about gigantic commits like this? This
> commit generated a 660KB email! Nobody is reading these emails. I'm
> already opposed to having automatically generated content committed
> to CVS, but when I'm receiving gigantic emails like this it's too much.
Hmmmmm, sorry.
I'd see some alternatives
- split the commit (e.g. by language)
- create a new docs-cvs-mailinglist
- drop the generated files and build the stuff online and for every release
(RM job, resp. the tarball roller's) - would need some MBs of Java stuff
installed everywhere
- ?
The first item seems to me currently the best... Other suggestions are
welcome :-)
nd
--
my @japh = (sub{q~Just~},sub{q~Another~},sub{q~Perl~},sub{q~Hacker~});
my $japh = q[sub japh { }]; print join #########################
[ $japh =~ /{(.)}/] -> [0] => map $_ -> () # André Malo #
=> @japh; # http://www.perlig.de/ #
Re: cvs commit: httpd-2.0/docs/manual/vhosts details.html.en details.html.ko.euc-kr
examples.html.en examples.html.ko.euc-kr fd-limits.html.en fd-limi
Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz wrote:
> I think once we exceed a threshold, it makes sense to go from a push
> notification to a pull notification. That's my take. -- justin
Yes, I like the viewcvs URL idea.
Re: cvs commit: httpd-2.0/docs/manual/vhosts details.html.en
details.html.ko.euc-kr examples.html.en examples.html.ko.euc-kr
fd-limits.html.en fd-limi
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, May 30, 2003 18:39:53 +0200 Astrid Keßler <ke...@kess-net.de>
wrote:
>> What about simply splitting the mails automatically at some threshold
>> byte count (of course, between single diffs)? Would that help? Would it
>> be better to receive, say, 6 x 100 KB, rather than 1 x 600KB?
>
> I can't figure out a real advantage. It doesn't matter if I get one big
> or many small mails. The effect is the same.
Indeed.
I think once we exceed a threshold, it makes sense to go from a push
notification to a pull notification. That's my take. -- justin
Re: cvs commit: httpd-2.0/docs/manual/vhosts details.html.en details.html.ko.euc-kr examples.html.en examples.html.ko.euc-kr fd-limits.html.en fd-limi
Posted by Astrid Keßler <ke...@kess-net.de>.
> What about simply splitting the mails automatically at some threshold byte
> count (of course, between single diffs)? Would that help? Would it be better
> to receive, say, 6 x 100 KB, rather than 1 x 600KB?
I can't figure out a real advantage. It doesn't matter if I get one big
or many small mails. The effect is the same.
Kess
Re: cvs commit: httpd-2.0/docs/manual/vhosts details.html.en
details.html.ko.euc-kr examples.html.en examples.html.ko.euc-kr fd-limits.html.en
fd-limi
Posted by Brian Behlendorf <br...@collab.net>.
On Fri, 30 May 2003, Thom May wrote:
> * Andr? Malo (nd@perlig.de) wrote :
> > * Justin Erenkrantz wrote:
> >
> > > Even if we don't drop the generated files in the repository (which I won't
> > > really comment on, other than that Java on FreeBSD isn't very stable - which
> > > matters because daedalus is on FreeBSD - someone may want to try to generate
> > > the docs on daedalus itself),
> >
> > uuh, bad. That was the final intention.
> >
> I thought Brian had this working rather better than it used to - he's got
> the native JDK working I believe? (CCing Brian in the hopes he can clear
> this up or at least jog my memory :-) )
On daedalus, the native JDK 1.3.1p7 as well as the blackdown 1.4.1 jdk are
both installed. Look in /usr/local.
On icarus, we have both the native 1.3.1p8 and 1.4.1p3 installed.
For batch processes like generating files, they should be fine. For
high-demand and long-running daemon processes, I don't know if I'd
recommend them yet, but no harm is done in trying them out.
Brian
Re: cvs commit: httpd-2.0/docs/manual/vhosts details.html.en details.html.ko.euc-kr examples.html.en examples.html.ko.euc-kr fd-limits.html.en fd-limi
Posted by Thom May <th...@planetarytramp.net>.
* Andr? Malo (nd@perlig.de) wrote :
> * Justin Erenkrantz wrote:
>
> > Even if we don't drop the generated files in the repository (which I won't
> > really comment on, other than that Java on FreeBSD isn't very stable - which
> > matters because daedalus is on FreeBSD - someone may want to try to generate
> > the docs on daedalus itself),
>
> uuh, bad. That was the final intention.
>
I thought Brian had this working rather better than it used to - he's got
the native JDK working I believe? (CCing Brian in the hopes he can clear
this up or at least jog my memory :-) )
Cheers
-Thom
Re: cvs commit: httpd-2.0/docs/manual/vhosts details.html.en details.html.ko.euc-kr examples.html.en examples.html.ko.euc-kr fd-limits.html.en fd-limi
Posted by André Malo <nd...@perlig.de>.
* Justin Erenkrantz wrote:
> Even if we don't drop the generated files in the repository (which I won't
> really comment on, other than that Java on FreeBSD isn't very stable - which
> matters because daedalus is on FreeBSD - someone may want to try to generate
> the docs on daedalus itself),
uuh, bad. That was the final intention.
> I think the best overall solution would be to
> alter the CVS mailer script to send ViewCVS URLs to all of the files that
> changed when the entire diff exceeds a certain limit. Commits that exceed the
> mailing list threshold are dropped and that's not good *ever*.
>
> I imagine some Perl hacker could tweak logaccum.pl to do this
> (/home/cvs/CVSROOT/log_accum.pl). If not, well, it might be time to rewrite
> logaccum.pl into Python. =) -- justin
What about simply splitting the mails automatically at some threshold byte
count (of course, between single diffs)? Would that help? Would it be better
to receive, say, 6 x 100 KB, rather than 1 x 600KB?
nd
--
>>> Muschelflucht-Zusatzeinrichtung.
>> Shell-Escape ist ja noch klar, aber `Zusatzeinrichtung'?
> extension?
Feature. -- gefunden in de.org.ccc
RE: cvs commit: httpd-2.0/docs/manual/vhosts details.html.en details.html.ko.euc-kr examples.html.en examples.html.ko.euc-kr fd-limits.html.en fd-limi
Posted by Sander Striker <st...@apache.org>.
> From: Astrid Keßler [mailto:kess@kess-net.de]
> Sent: Friday, May 30, 2003 1:52 PM
[...]
> Of course, the RM could generate them while creating the release,
Eek! This RM no like. It would be an extra burden I am not looking
forward to. It also introduces more room for error on part of the RM.
Pruning the commit logs is IMHO the best (short term) solution.
Sander
Re: cvs commit: httpd-2.0/docs/manual/vhosts details.html.en details.html.ko.euc-kr examples.html.en examples.html.ko.euc-kr fd-limits.html.en fd-limi
Posted by Astrid Keßler <ke...@kess-net.de>.
Hallo Thom,
Nachricht vom Friday, May 30, 2003, 1:05:12 PM:
> * Astrid Ke?ler (kess@kess-net.de) wrote :
>> >> Hmmmmm, sorry.
>> >> I'd see some alternatives
>> >> - split the commit (e.g. by language)
>> >> - create a new docs-cvs-mailinglist
>> >> - drop the generated files and build the stuff online and for every release
>> >> (RM job, resp. the tarball roller's) - would need some MBs of Java stuff
>> >> installed everywhere
>> >> - ?
>> >>
>> > I'd go with dropping the generated files out of CVS altogether - I don't see
>> > that there's much reason to keep them there, and a teeny wodge of java is
>> > not exactly an odious proposition for most of us these days I'd think?
>> > Cheers
>> > -Thom
>>
>> Don't drop them. It's usefull to know, whether they are up to date or
>> not. But we do not need the commit mails. Only those mails need to be
>> omitted. This should be possible.
> I don't quite follow this I'm afraid - it's useful to know *where*? because
> surely we can just have a check out and rebuild procedure on daedalus and
> where ever else needs to have those files.
The current workflow is to generate them locally and have the latest
version in cvs (also the change management). Creating a release or
updating the online docs, the generated html files are taken from the
cvs.
Of course, the RM could generate them while creating the release, or we
could do the build process on deadalus, but what about generating
content for languages with non ascii characters like japanese, chinese,
etc.? As I understood, this depends partially on the local character
set.
May someone correct me, if I'm wrong.
So if we need locally generation, we also need a place at the server to
store the lastest version.
Kess
Re: cvs commit: httpd-2.0/docs/manual/vhosts details.html.en details.html.ko.euc-kr examples.html.en examples.html.ko.euc-kr fd-limits.html.en fd-limi
Posted by André Malo <nd...@perlig.de>.
* Thom May wrote:
>> If we drop the html files from CVS we need more eyes on the online docs and
>> more docco eyes on (pre-)releases. And of course, tons of java code
>> installed on every system that builds from CVS. (need to mention that
>> somewhere in /dev/?)
>>
> Well, having more eyes sounds like a win rather than a problem, to be
> honest.
Ideally, yes. But traditionally the docco eyes aren't focussed very well on
the releases :-) We'd have to change that. (should change that anyway.)
> The requirements for the building the docs would definitely need to be
> better documented - it took me quite a while to find out how to build the
> docs when I was doing my changes to htpasswd recently.
That's probably true...
>> Said that, I'm trusting the build system now and give a +-0 on dropping the
>> generated files - except the generated manpages (these would change their
>> last-modification-data everytime otherwise).
>>
> Hrm, can't we base last-modification-date off the cvs $Id$ string?
There's currently no $Id$ in any httpd file (except STATUS or so). But for
better diffs in generated file it would be considerable (for the *.xml files
in the manual/programs folder), IMHO.
Although ... the generated files depend on various source files: .xml, .xsl
and $lang.xml. Darn.
nd
--
Gefunden auf einer "Webdesigner"-Seite:
> Programmierung in HTML, XML, WML, CGI, FLASH <
# André Malo # http://www.perlig.de/ #
Re: cvs commit: httpd-2.0/docs/manual/vhosts details.html.en details.html.ko.euc-kr examples.html.en examples.html.ko.euc-kr fd-limits.html.en fd-limi
Posted by Thom May <th...@planetarytramp.net>.
* Andr? Malo (nd@perlig.de) wrote :
> Not so long time ago the build process wasn't stable enough (produced
> different results in different environments). After some tricks to work
> around the problems we could consider this point resolved now.
>
OK, so this sounds like a reasonable thing to do now.
> The last important thing for me is: We lose control. For example, when
> committing changes in Korean or Japanese I treat them as opaque binary data
> and handle them very carefully (double checking the diffs before the
> commit).
Well, this is true. But if the data we have in the xml docs is incorrect
then we're in trouble anyway, no? (And, similarily, if the transform doesn't
work correctly we're equally in trouble)
> If we drop the html files from CVS we need more eyes on the online docs and
> more docco eyes on (pre-)releases. And of course, tons of java code
> installed on every system that builds from CVS. (need to mention that
> somewhere in /dev/?)
>
Well, having more eyes sounds like a win rather than a problem, to be
honest.
The requirements for the building the docs would definitely need to be
better documented - it took me quite a while to find out how to build the
docs when I was doing my changes to htpasswd recently.
> Said that, I'm trusting the build system now and give a +-0 on dropping the
> generated files - except the generated manpages (these would change their
> last-modification-data everytime otherwise).
>
Hrm, can't we base last-modification-date off the cvs $Id$ string?
-Thom
Re: cvs commit: httpd-2.0/docs/manual/vhosts details.html.en details.html.ko.euc-kr examples.html.en examples.html.ko.euc-kr fd-limits.html.en fd-limi
Posted by André Malo <nd...@perlig.de>.
* Thom May wrote:
> I don't quite follow this I'm afraid - it's useful to know *where*? because
> surely we can just have a check out and rebuild procedure on daedalus and
> where ever else needs to have those files.
> I don't get why having this stuff in cvs actually helps us at all - we're
> not making any changes to it directly, so it doesn't need to be under change
> management. Same as the configure scripts, and all the other generated code.
Not so long time ago the build process wasn't stable enough (produced
different results in different environments). After some tricks to work
around the problems we could consider this point resolved now.
The last important thing for me is: We lose control. For example, when
committing changes in Korean or Japanese I treat them as opaque binary data
and handle them very carefully (double checking the diffs before the
commit).
If we drop the html files from CVS we need more eyes on the online docs and
more docco eyes on (pre-)releases. And of course, tons of java code
installed on every system that builds from CVS. (need to mention that
somewhere in /dev/?)
Said that, I'm trusting the build system now and give a +-0 on dropping the
generated files - except the generated manpages (these would change their
last-modification-data everytime otherwise).
nd
--
"Eine Eieruhr", erklärt ihr Hermann, "besteht aus einem Ei. Du nimmst
das Ei und kochst es. Wenn es hart ist, sind fünf Minuten um. Dann weißt
du, daß die Zeit vergangen ist."
-- Hannes Hüttner in "Das Blaue vom Himmel"
Re: cvs commit: httpd-2.0/docs/manual/vhosts details.html.en details.html.ko.euc-kr examples.html.en examples.html.ko.euc-kr fd-limits.html.en fd-limi
Posted by Thom May <th...@planetarytramp.net>.
* Astrid Ke?ler (kess@kess-net.de) wrote :
> >> Hmmmmm, sorry.
> >> I'd see some alternatives
> >> - split the commit (e.g. by language)
> >> - create a new docs-cvs-mailinglist
> >> - drop the generated files and build the stuff online and for every release
> >> (RM job, resp. the tarball roller's) - would need some MBs of Java stuff
> >> installed everywhere
> >> - ?
> >>
> > I'd go with dropping the generated files out of CVS altogether - I don't see
> > that there's much reason to keep them there, and a teeny wodge of java is
> > not exactly an odious proposition for most of us these days I'd think?
> > Cheers
> > -Thom
>
> Don't drop them. It's usefull to know, whether they are up to date or
> not. But we do not need the commit mails. Only those mails need to be
> omitted. This should be possible.
I don't quite follow this I'm afraid - it's useful to know *where*? because
surely we can just have a check out and rebuild procedure on daedalus and
where ever else needs to have those files.
I don't get why having this stuff in cvs actually helps us at all - we're
not making any changes to it directly, so it doesn't need to be under change
management. Same as the configure scripts, and all the other generated code.
Cheers
-Thom
Re: cvs commit: httpd-2.0/docs/manual/vhosts details.html.en details.html.ko.euc-kr examples.html.en examples.html.ko.euc-kr fd-limits.html.en fd-limi
Posted by Astrid Keßler <ke...@kess-net.de>.
>> Hmmmmm, sorry.
>> I'd see some alternatives
>> - split the commit (e.g. by language)
>> - create a new docs-cvs-mailinglist
>> - drop the generated files and build the stuff online and for every release
>> (RM job, resp. the tarball roller's) - would need some MBs of Java stuff
>> installed everywhere
>> - ?
>>
> I'd go with dropping the generated files out of CVS altogether - I don't see
> that there's much reason to keep them there, and a teeny wodge of java is
> not exactly an odious proposition for most of us these days I'd think?
> Cheers
> -Thom
Don't drop them. It's usefull to know, whether they are up to date or
not. But we do not need the commit mails. Only those mails need to be
omitted. This should be possible.
Kess
Re: cvs commit: httpd-2.0/docs/manual/vhosts details.html.en details.html.ko.euc-kr
examples.html.en examples.html.ko.euc-kr fd-limits.html.en fd-limi
Posted by Erik Abele <er...@codefaktor.de>.
Justin Erenkrantz wrote:
> Even if we don't drop the generated files in the repository (which I
> won't really comment on, other than that Java on FreeBSD isn't very
> stable - which matters because daedalus is on FreeBSD - someone may want
> to try to generate the docs on daedalus itself), I think the best
> overall solution would be to alter the CVS mailer script to send ViewCVS
> URLs to all of the files that changed when the entire diff exceeds a
> certain limit. Commits that exceed the mailing list threshold are
> dropped and that's not good *ever*.
>
> I imagine some Perl hacker could tweak logaccum.pl to do this
> (/home/cvs/CVSROOT/log_accum.pl). If not, well, it might be time to
> rewrite logaccum.pl into Python. =) -- justin
>
I just submitted a patch for log_accum.pl to infrastructure@, which does
exactly this.
Resulting mail msg exceeds predefined size limit -> ViewCVS URLs
Resulting mail msg doesn't exceed predefined size limit -> full-featured
diff as normal
No dropped commit mails, all fine :)
Cheers,
Erik
BTW, AFAICT somebody recently had the same problem on Xerces-C, so this
is not only an issue with our we-store-all-and-everything docs tree :-)
Re: cvs commit: httpd-2.0/docs/manual/vhosts details.html.en
details.html.ko.euc-kr examples.html.en examples.html.ko.euc-kr
fd-limits.html.en fd-limi
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, May 30, 2003 2:34 AM +0200 André Malo <nd...@perlig.de> wrote:
>> I've been trying to hold my tongue on this, but I can't any longer.
>> Is there something we can do about gigantic commits like this? This
>> commit generated a 660KB email! Nobody is reading these emails. I'm
>> already opposed to having automatically generated content committed
>> to CVS, but when I'm receiving gigantic emails like this it's too much.
>
> Hmmmmm, sorry.
> I'd see some alternatives
> - split the commit (e.g. by language)
> - create a new docs-cvs-mailinglist
> - drop the generated files and build the stuff online and for every release
> (RM job, resp. the tarball roller's) - would need some MBs of Java stuff
> installed everywhere
> - ?
Even if we don't drop the generated files in the repository (which I won't
really comment on, other than that Java on FreeBSD isn't very stable - which
matters because daedalus is on FreeBSD - someone may want to try to generate
the docs on daedalus itself), I think the best overall solution would be to
alter the CVS mailer script to send ViewCVS URLs to all of the files that
changed when the entire diff exceeds a certain limit. Commits that exceed the
mailing list threshold are dropped and that's not good *ever*.
I imagine some Perl hacker could tweak logaccum.pl to do this
(/home/cvs/CVSROOT/log_accum.pl). If not, well, it might be time to rewrite
logaccum.pl into Python. =) -- justin
Re: cvs commit: httpd-2.0/docs/manual/vhosts details.html.en details.html.ko.euc-kr examples.html.en examples.html.ko.euc-kr fd-limits.html.en fd-limi
Posted by Thom May <th...@planetarytramp.net>.
* Andr? Malo (nd@perlig.de) wrote :
> * Aaron Bannert wrote:
>
> > On Thursday, May 29, 2003, at 12:30 PM, nd@apache.org wrote:
> >
> >> Modified: docs/manual Tag: APACHE_2_0_BRANCH bind.html.en
> >> bind.html.ja.jis bind.html.ko.euc-kr
> >> cgi_path.html.en cgi_path.html.ja.jis
> >> cgi_path.html.ko.euc-kr configuring.html.en
> > [...]
> >
> > I've been trying to hold my tongue on this, but I can't any longer.
> > Is there something we can do about gigantic commits like this? This
> > commit generated a 660KB email! Nobody is reading these emails. I'm
> > already opposed to having automatically generated content committed
> > to CVS, but when I'm receiving gigantic emails like this it's too much.
+1
>
> Hmmmmm, sorry.
> I'd see some alternatives
> - split the commit (e.g. by language)
> - create a new docs-cvs-mailinglist
> - drop the generated files and build the stuff online and for every release
> (RM job, resp. the tarball roller's) - would need some MBs of Java stuff
> installed everywhere
> - ?
>
I'd go with dropping the generated files out of CVS altogether - I don't see
that there's much reason to keep them there, and a teeny wodge of java is
not exactly an odious proposition for most of us these days I'd think?
Cheers
-Thom