Publishing the docs nightly, from my experience, would be a bad idea. We don't see the problem now, when we're just tweaking things here and there. The problem comes in when you're getting ready to release JMeter 1.9 - then, wholesale changes will be needed, by multiple people, over a period of a couple weeks most likely. If an automatic process is publishing the site at that point, it won't work.
Do you all have accounts on jakarta.apache.org? You should check it out. I usually ssh to cvs.apache.org, and then ssh to jakarta.apache.org from there. Make sure you can do that - if you can't, we need to get your account set up over there. Having the docs in CVS makes it convenient, because all you need to do is log in to jakarta.apache.org, cd to the right directory, and type "cvs update -d", and you're done publishing the docs. I would not want to have to scp a tarball and unzip it there - that's a pain. It's bad enough I have to do that to make a release. If I had to do that everytime I updated the web site, it wouldn't get updated very often. I don't see a problem with the docs in CVS. But then, I use WinCVS, which is very handy and quicker than using command-line cvs. I could hardly "miss" or forget to update the docs, because WinCVS makes it obvious when I have modified files that I haven't checked in. I'm also wary of pulling JUnit from the distribution. How sure are you this won't be a problem? Have you tested all of JMeter's functionality without it? -Mike On 10 Jan 2003 at 19:12, Jordi Salvat i Alabart wrote: > Hi. > > As you may be aware of, I broke the way the JMeter site used to be > published :-( > > I still believe the approach of keeping in CVS only things that can't be > obtained from source is cleaner, and better in the long term; but I need > to reinstate a practical way to publish the docs. > > Possible ways: > a/ Undo my change and add back the generated docs to CVS > b/ Have the nightly build republish the docs every day > c/ Have the nightly build create a docs distribution, which someone > would need to pull and publish (just as we did when they were in CVS). > d/ �Other ideas? > > a/ Has three problems: > 1/ As said, needs "redundant" stuff to be kept in CVS. I don't like this > -- although I admit it's a matter of taste. > 2/ Requires developers to check-in produced docs in addition to the > source xdocs whenever they make a change. Not a big deal, but it's easy > to forget and may cause conflicts from time to time > 3/ It's difficult to verify the content before publishing > > b/ is great because it keeps things up-to-date and requires no > invervention, but of course we may occasionally find our site totally > broken. > > c/ looks great, but I'm not sure how confortable it will be for whoever > has to do the work -- and we'll make him responsible for the checking, > which is probably unfair. > > Anyone can think of a d/ or an e/? Arguments for or against each of the > aproaches? > > FYI, most --but not all-- jakarta projects use a/. I don't know exactly > what the others (e.g. jakarta-oro) do. > > Salut, > > Jordi. > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Michael Stover [EMAIL PROTECTED] Yahoo IM: mstover_ya ICQ: 152975688 AIM: mstover777 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
