cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: machine name for cocondev.org
Date Mon, 04 Nov 2002 17:52:20 GMT
Robert Koberg wrote:

> Hi,
>
>
> >-----Original Message-----
> >From: Stefano Mazzocchi [mailto:stefano@apache.org]
> >Sent: Monday, November 04, 2002 7:55 AM
>
>
> >Robert Koberg wrote:
>
>
>
>
> >>I would suggest somoething like the following for all projects:
> >>
> >>dev.projectx.cocoon.apache.org -- for development purposes
> >>
> >>Then when ready to go to QA, create a branch/tag and promote the 
> site to:
> >>
> >>qa.projectx.cocoon.apache.org
> >>
> >>If something is broken, fix it in the branch and keep QAing until it
> >>can be
> >>promoted to something like:
> >>
> >>cert.projectx.cocoon.apache.org
> >
> >Rob, it took me two years to come close enough to be able to get *one*
> >virtual host. One step at the time, please.
>
>
> OK, I understand. But let me proceed anyway :)

I knew it. :/

>
> The virtual hosts would be set up on the new server so you can do 
> whatever you want.

Yeah, I know that.

> The problem, of course is the DNS entries. 

No, not only that. It's 'breaking the rule'. Apache is *EXTREMELY* 
conservative from an infrastructural point of view.

Moreover, I don't think that we need more than one virtualhost per project.

> I can't see it being too difficult
> for some infrastructure person to create the entries upon request. 

No, this is not a problem.

> Perhaps an interface could be made like register.com that allows 
> authorized users to add/remove at will.

Are you volunteering to write that?

> Or it could be virtual hosts off of cocoondev.org (i.e. 
> dev.projectx.cocoondev.org).

We are not discussing cocoondev.org (the site) here.

> I was trying to get the point across that staging environments should 
> be thought of upfront.

Oh, but you are definately mixing concerns here:

  - one concern is: we should have a multiple-stage publishing system

  - another concern is: each subproject should have its own subdomain

  - yet another concern is: each stage should have its own sub-subdomain

So let me ask each concern separately:

  1) each subproject should be kept inside cocoon. Cocoon will make all 
possible efforts to keep the number of subprojects small and promote 
them at top-level as soon as they are ready to stand that pressure 
(forrest could be next, in that vision) so, even if we managed our own 
DNS entries, I would be against having forrest.cocoon.apache.org.

  2) I don't think we need a multiple stage publishing system. All we 
need is a cache-aware CVSSource (where the cache can be implemented on a 
scripted trigger placed on cvs.apache.org and connected to our CVS modules).

  3) this rules out the last concern.

I know you won't like the above anyway, but I ask you: publishing docs 
is already hard enough, why in hell do you want to make it harder with 
staging? we are not the kind of environment that benefits from having 
two stages since as soon as we have something to show (even if broken or 
imcomplete) we want to publish it anyway to gather feedback.

Delaying publishing of documents will *harm* us, not help us.

-- 
Stefano Mazzocchi                               <stefano@apache.org>
--------------------------------------------------------------------




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message