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 <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
