Re: VMWare host for us @apache.org
David Crossley wrote: David Crossley wrote: Upayavira wrote: David Crossley wrote: The docs aspect needs lots of consideration. If Cocoon wants to continue using Forrest, then we would like help to implement our plans for the Forrestbot and staging server for reviewing docs prior to publication. We had a huge discussion on this at infrastructure.at.a.o a few months ago. That needs to be summarised and brought into the open. I think this is the sort of thing I was referring to. If we can clarify what we have in mind, and get a number of us behind it, then I could see it as being possible. But there's a lot to clarify/understand. Would you be willing to explain here what you had in mind for your Forrestbot setup? Presumably this setup would still use CVS/SVN as the versioning system for the actual xdoc files? Yes it does. Well i will try. It is a big task. Did anyone see the infrastructure@ discussion to which i refer. It was not just about "forrestbot", rather the whole situation of publishing of documentation at Apache. There are so many aspects: oversight of content, staging, workflow, recoverability, quick turnaround, secure access, Forrestbot, Lenya, Doco, ... The thread finished with the feeling that we had solutions, just in need of implementation. Anyway, going off to dig through mail archives again ... ... back to the surface. I have summarised that previous discussion from [EMAIL PROTECTED] and built two proposal documents. These are at the Forrest website. Draft: Proposal for ASF-wide documentation staging and publishing http://forrest.apache.org/proposal-asf-publish.html This draws together various past discussions to address the diverse issues with documentation publishing at apache.org With respect to the following "scratch note" in the above document: Noel: We need to accommodate sites that come from a single source, and sites that come from multiple sources, e.g. Jakarta or the XML Federation. A recent plugin for Forrest allows sites to use an IMS Manifest to define their structure, one of the main advantages of using this method over the existing method (which remains the default method) is that it allows a site to include other sites within their own site. That is, each subproject in Jakarta/XML would maintain their site independently of the main Jakarta/XML site. These "sub-sites" can be built independently of the main Jakarta/XML site for local testing purposes. How will this impact the building process described in the above document? Stages A through G will be unaffected. Each individual site would have its own staging area, hence there is no need to build the whole Jakarta or XML site in order to review minor changes in one of the sub sites. The main site can also be staged in the way described in the document. Actions in stages H and I would depend on how the main site was built and the changes that have been made. If the main site simply links to the subsites (as is currently the case) then this site will only need to be rebuilt when such a link is updated, or the contents of the main site are updated. However, using this new plugin it is possible to have the menus for the sub-sites appear as collapsible menus in the main site. In this case the main site will need to be rebuilt whenever the structure of a subsite changes (i.e. a new page is added). If changes to subsites are minor (text changes in a page for example), then only the sub-site need be published. CAVEAT: This forrest plugin is currently in alpha. It is not even in SVN yet (pending a restructure of SVN to accommodate the new plugin functionality of Forrest). As author of the plugin I can assure you that I will assist in any changes required to meet the requirements of the ASF (I need similar functionality in the project this came from anyway). Ross
Re: VMWare host for us @apache.org
David Crossley wrote: > Upayavira wrote: > > David Crossley wrote: > > > > >The docs aspect needs lots of consideration. If Cocoon wants to > > >continue using Forrest, then we would like help to implement > > >our plans for the Forrestbot and staging server for reviewing > > >docs prior to publication. > > > > > >We had a huge discussion on this at infrastructure.at.a.o a few > > >months ago. That needs to be summarised and brought into the open. > > > > I think this is the sort of thing I was referring to. If we can clarify > > what we have in mind, and get a number of us behind it, then I could see > > it as being possible. > > > > But there's a lot to clarify/understand. Would you be willing to explain > > here what you had in mind for your Forrestbot setup? Presumably this > > setup would still use CVS/SVN as the versioning system for the actual > > xdoc files? > > Yes it does. > > Well i will try. It is a big task. Did anyone see the > infrastructure@ discussion to which i refer. It was not > just about "forrestbot", rather the whole situation of > publishing of documentation at Apache. There are > so many aspects: oversight of content, staging, workflow, > recoverability, quick turnaround, secure access, > Forrestbot, Lenya, Doco, ... > > The thread finished with the feeling that we had solutions, > just in need of implementation. > > Anyway, going off to dig through mail archives again ... ... back to the surface. I have summarised that previous discussion from [EMAIL PROTECTED] and built two proposal documents. These are at the Forrest website. Draft: Proposal for ASF-wide documentation staging and publishing http://forrest.apache.org/proposal-asf-publish.html This draws together various past discussions to address the diverse issues with documentation publishing at apache.org Draft: Proposal for ASF-wide Forrestbot http://forrest.apache.org/proposal-asf-forrestbot.html This shows the Forrestbot role. How Forrest can help the Cocoon publishing situation should be evident from those proposals. I am going to continue the previous discussions on the Infrastructure mailing list. Any Apache committers can join in to help. http://www.apache.org/foundation/mailinglists.html#foundation-infrastructure -- David Crossley
Re: VMWare host for us @apache.org
Rogier Peters wrote: Bertrand Delacretaz wrote: Le 22 oct. 04, à 13:29, Rogier Peters a écrit : ...Although I agree completely that it's the accessability, not the quality of the documentation that is lacking, i can't help but hearing echoes of the GT cms-shootout ( bag of docs; heavy on search ). Why use forrest and not daisy or hippo? I wanted to put Forrest as the first option for "loyalty" reasons, as the Forrest team has helped us a lot until now. But there are many options of course. But at this point we should be careful not to fall into the trap of discussing tools before agreing on the problem. -Bertrand You're right, actually I replied before reading oops, and then I pressed send before completing. before reading the whole discussion that is. Rogier
Re: VMWare host for us @apache.org
Bertrand Delacretaz wrote: Le 22 oct. 04, à 13:29, Rogier Peters a écrit : ...Although I agree completely that it's the accessability, not the quality of the documentation that is lacking, i can't help but hearing echoes of the GT cms-shootout ( bag of docs; heavy on search ). Why use forrest and not daisy or hippo? I wanted to put Forrest as the first option for "loyalty" reasons, as the Forrest team has helped us a lot until now. But there are many options of course. But at this point we should be careful not to fall into the trap of discussing tools before agreing on the problem. -Bertrand You're right, actually I replied before reading
Re: VMWare host for us @apache.org
David Crossley wrote: So i gather that you are saying that we, Cocoon, need a group of us who are committed to maintain the operating system and supporting applications. I am keen to help and learn. I'm more than willing to lend a hand -- I have a ton of experience adminning a couple FreeBSD boxes. You haven't lived until you've compiled the native JVM on FreeBSD overnight ;) Tony
Re: VMWare host for us @apache.org
David Crossley wrote: Bertrand Delacretaz wrote: But at this point we should be careful not to fall into the trap of discussing tools before agreing on the problem. Yes, it is a strong magnet. Let's just use the simplest solution for now and see how that works (IMO, Forrest). I think we can get by with committing docs to a "live" svn repository and have them show up immediately -- in fact it could be such an amazing improvement over the current system, we might not care about having anything more. Tony
Re: VMWare host for us @apache.org
Rogier Peters wrote: Bertrand Delacretaz wrote: Le 22 oct. 04, à 12:23, David Crossley a écrit : What's needed IMHO is the "big bag of docs with powerful search functions" that we talked about before (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106586497031048&w=2 for example). I like the idea, but let's make sure we end up with very usable URIs. IMNSHO we *have* to have URIs of words, and not something like /docs/foo/3446521.html. It's just not good. I propose we try to "correctly" reorganize the docs before resorting to BBOD with crazy URIs. I have some decent experience with organizing and reorganizing site docs from previous jobs, so it can't be all that hard, can it? :) If we agree on this, the next step would be to evaluate Forrest against our needs and find out the simplest thing that would work. Maybe Forrest using a live SVN repository, live Lucene indexing and mod_cache in front would be all what we need? Having "live docs" would be a boon to the documentation. The biggest hurdle I face when I work on docs is the fact that I have to edit the original xdocs, commit those, and (re- generating the site and committing a second set. A live Forrest would be awesome. Although I agree completely that it's the accessability, not the quality of the documentation that is lacking, i can't help but hearing echoes of the GT cms-shootout ( bag of docs; heavy on search ). Why use forrest and not daisy or hippo? Rogier Tony
Re: VMWare host for us @apache.org
Bertrand Delacretaz wrote: > Rogier Peters a écrit : > > > ...Although I agree completely that it's the accessability, not the > > quality of the documentation that is lacking, i can't help but hearing > > echoes of the GT cms-shootout ( bag of docs; heavy on search ). > > Why use forrest and not daisy or hippo? > > I wanted to put Forrest as the first option for "loyalty" reasons, as > the Forrest team has helped us a lot until now. But there are many > options of course. Thanks, we are grateful for that loyalty. Don't feel bound by it. > But at this point we should be careful not to fall into the trap of > discussing tools before agreing on the problem. Yes, it is a strong magnet. -- David Crossley
Re: VMWare host for us @apache.org
Upayavira wrote: > David Crossley wrote: > > >The docs aspect needs lots of consideration. If Cocoon wants to > >continue using Forrest, then we would like help to implement > >our plans for the Forrestbot and staging server for reviewing > >docs prior to publication. > > > >We had a huge discussion on this at infrastructure.at.a.o a few > >months ago. That needs to be summarised and brought into the open. > > I think this is the sort of thing I was referring to. If we can clarify > what we have in mind, and get a number of us behind it, then I could see > it as being possible. > > But there's a lot to clarify/understand. Would you be willing to explain > here what you had in mind for your Forrestbot setup? Presumably this > setup would still use CVS/SVN as the versioning system for the actual > xdoc files? Yes it does. Well i will try. It is a big task. Did anyone see the infrastructure@ discussion to which i refer. It was not just about "forrestbot", rather the whole situation of publishing of documentation at Apache. There are so many aspects: oversight of content, staging, workflow, recoverability, quick turnaround, secure access, Forrestbot, Lenya, Doco, ... The thread finished with the feeling that we had solutions, just in need of implementation. Anyway, going off to dig through mail archives again ... -- David Crossley
Re: VMWare host for us @apache.org
Le 22 oct. 04, à 13:29, Rogier Peters a écrit : ...Although I agree completely that it's the accessability, not the quality of the documentation that is lacking, i can't help but hearing echoes of the GT cms-shootout ( bag of docs; heavy on search ). Why use forrest and not daisy or hippo? I wanted to put Forrest as the first option for "loyalty" reasons, as the Forrest team has helped us a lot until now. But there are many options of course. But at this point we should be careful not to fall into the trap of discussing tools before agreing on the problem. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: VMWare host for us @apache.org
Bertrand Delacretaz wrote: Le 22 oct. 04, à 12:23, David Crossley a écrit : What's needed IMHO is the "big bag of docs with powerful search functions" that we talked about before (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106586497031048&w=2 for example). If we agree on this, the next step would be to evaluate Forrest against our needs and find out the simplest thing that would work. Maybe Forrest using a live SVN repository, live Lucene indexing and mod_cache in front would be all what we need? Although I agree completely that it's the accessability, not the quality of the documentation that is lacking, i can't help but hearing echoes of the GT cms-shootout ( bag of docs; heavy on search ). Why use forrest and not daisy or hippo? Rogier
Re: VMWare host for us @apache.org
Le 22 oct. 04, à 12:23, David Crossley a écrit : ...The docs aspect needs lots of consideration. If Cocoon wants to continue using Forrest, then we would like help to implement our plans for the Forrestbot and staging server for reviewing docs prior to publication I think our docs are much better than people generally believe, but their *accessibility* is the big problem. Having dynamic structured queries on their content would make all the difference. Storing the content in a database, or having a structured (meaning using database-like fields) Lucene index would make all the difference in the accessibility of the content, allowing for example queries like "show me documents which talk about sitemap and matchers at the configuration level". Such queries can be hidden behind links so that the docs "auto-organize" provided the appropriate attributes (topic, audience, document role, etc.) are set on the documents, in an iterative process for existing docs. What's needed IMHO is the "big bag of docs with powerful search functions" that we talked about before (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106586497031048&w=2 for example). If we agree on this, the next step would be to evaluate Forrest against our needs and find out the simplest thing that would work. Maybe Forrest using a live SVN repository, live Lucene indexing and mod_cache in front would be all what we need? -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: VMWare host for us @apache.org
David Crossley wrote: [EMAIL PROTECTED] wrote: Upayavira wrote: While we can start thinking about where to host, I think we've first got to clarify what we want to host. As yet, I've only as yet got a vague idea of what we want - "a machine to run Cocoon, possibly doing its docs". What does that actually mean? What would we install? How would we do docs? Is it pure Cocoon, or Forrest? If Forrest, what about Cocoon samples? Will we want additional mini webapps? What sort of things? Etc, etc, etc. I think we should get these things sorted before we mention anything to infrastructure, in order for our case to sound convincing. +1 I'd say: docs and samples and, in future, "administrative" webapps like e.g. a form for link requests. I'm not sure what you mean by "additional mini webapps", but I'd say anything that would go in the "samples" section of Cocoon. I reckon the Cocoon Samples, plus make the new Link Submission part of that. That way developers can have that as a local app too. Yup, that's the easy bit. The docs aspect needs lots of consideration. If Cocoon wants to continue using Forrest, then we would like help to implement our plans for the Forrestbot and staging server for reviewing docs prior to publication. We had a huge discussion on this at infrastructure.at.a.o a few months ago. That needs to be summarised and brought into the open. I think this is the sort of thing I was referring to. If we can clarify what we have in mind, and get a number of us behind it, then I could see it as being possible. But there's a lot to clarify/understand. Would you be willing to explain here what you had in mind for your Forrestbot setup? Presumably this setup would still use CVS/SVN as the versioning system for the actual xdoc files? Regards, Upayavira
RE: VMWare host for us @apache.org
[EMAIL PROTECTED] wrote: > Upayavira wrote: > > While we can start thinking about where to host, I think > > we've first got > > to clarify what we want to host. As yet, I've only as yet got a vague > > idea of what we want - "a machine to run Cocoon, possibly doing its > > docs". What does that actually mean? What would we install? > > How would we > > do docs? Is it pure Cocoon, or Forrest? If Forrest, what about Cocoon > > samples? Will we want additional mini webapps? What sort of > > things? Etc, > > etc, etc. I think we should get these things sorted before we mention > > anything to infrastructure, in order for our case to sound convincing. > > +1 > > I'd say: docs and samples and, in future, "administrative" webapps like e.g. > a form for link requests. > I'm not sure what you mean by "additional mini webapps", but I'd say > anything that would go in the "samples" section of Cocoon. I reckon the Cocoon Samples, plus make the new Link Submission part of that. That way developers can have that as a local app too. The docs aspect needs lots of consideration. If Cocoon wants to continue using Forrest, then we would like help to implement our plans for the Forrestbot and staging server for reviewing docs prior to publication. We had a huge discussion on this at infrastructure.at.a.o a few months ago. That needs to be summarised and brought into the open. -- David Crossley
RE: VMWare host for us @apache.org
> While we can start thinking about where to host, I think > we've first got > to clarify what we want to host. As yet, I've only as yet got a vague > idea of what we want - "a machine to run Cocoon, possibly doing its > docs". What does that actually mean? What would we install? > How would we > do docs? Is it pure Cocoon, or Forrest? If Forrest, what about Cocoon > samples? Will we want additional mini webapps? What sort of > things? Etc, > etc, etc. I think we should get these things sorted before we mention > anything to infrastructure, in order for our case to sound convincing. +1 I'd say: docs and samples and, in future, "administrative" webapps like e.g. a form for link requests. I'm not sure what you mean by "additional mini webapps", but I'd say anything that would go in the "samples" section of Cocoon. Bye, Helma
Re: VMWare host for us @apache.org
David Crossley wrote: Upayavira wrote: Bertrand Delacretaz wrote: Upayavira a écrit : ...If we have needs for running our own stuff, e.g. having the latest Cocoon samples usable from the Cocoon website, we should make a request to the infrastructure team for a VM for ourselves, as soon as they have done the necessary hardware upgrades If it's debian I'm willing to help setup and co-administer such a machine. Could also help with other distros but it's really debian that I know the best, and apt-get is a big plus assuming the admin would be shared between several people. Me too (debian that is). Sounds like the way to me too. So i gather that you are saying that we, Cocoon, need a group of us who are committed to maintain the operating system and supporting applications. I am keen to help and learn. A while ago there was another option discussed: moof.apache.org http://www.apache.org/dev/machines.html#moof Mac OS X 10.3 Server ... AFAIK nobody yet took up the offer of running apps there. There is an old gump there still. http://moof.apache.org:8080/gump/ Also we didn't yet investigate Stefano's suggestion of sharing brutus with Apache Gump. While we can start thinking about where to host, I think we've first got to clarify what we want to host. As yet, I've only as yet got a vague idea of what we want - "a machine to run Cocoon, possibly doing its docs". What does that actually mean? What would we install? How would we do docs? Is it pure Cocoon, or Forrest? If Forrest, what about Cocoon samples? Will we want additional mini webapps? What sort of things? Etc, etc, etc. I think we should get these things sorted before we mention anything to infrastructure, in order for our case to sound convincing. Having our own live Cocoon instance(s) could make all the difference in the way we do our docs, so if there's an opportunity I think we should make it happen. Interesting co-incidence. We just started talking about this again yesterday at Forrest. We had shelved plans for live webapp and forrestbot until infrastructure was more ready. Looking better soon. Interesting. How much access these machines can handle I don't know - i.e. infrastructure maintain minotaur at a level that can handle all of our HTTP access to cocoon.apache.org. Whether a VM could handle hosting cocoon.apache.org, I don't know. But if we stuck Apache with mod_cache in front, who knows? Sounds like part of that discussion should happen over there. I think we need to start here, with a discussion on what we want to host. BTW, where did you learn all this, is there a list that I'm missing? infrastructure@ ? [EMAIL PROTECTED] Sit on there and read. You'll learn a lot! Yeah, it is great. Just like at any other Apache project, one learns heaps just by being there. While we are there, we can do our bit to help out by answering some user questions. You know the drill. Just like any other Apache project, Infrastructure is a group of enthusiastic volunteers. We need help. Only committers and invited guests can join. Anyone can post so that they can report perceived problems. http://www.apache.org/foundation/mailinglists.html#foundation-infrastructure Exactly. Stuff I should have said! Regards, Upayavira
Re: VMWare host for us @apache.org
Upayavira wrote: > Bertrand Delacretaz wrote: > > Upayavira a écrit : > > > >> ...If we have needs for running our own stuff, e.g. having the latest > >> Cocoon samples usable from the Cocoon website, we should make a > >> request to the infrastructure team for a VM for ourselves, as soon as > >> they have done the necessary hardware upgrades > > > > If it's debian I'm willing to help setup and co-administer such a > > machine. Could also help with other distros but it's really debian > > that I know the best, and apt-get is a big plus assuming the admin > > would be shared between several people. > > Me too (debian that is). Sounds like the way to me too. So i gather that you are saying that we, Cocoon, need a group of us who are committed to maintain the operating system and supporting applications. I am keen to help and learn. A while ago there was another option discussed: moof.apache.org http://www.apache.org/dev/machines.html#moof Mac OS X 10.3 Server ... AFAIK nobody yet took up the offer of running apps there. There is an old gump there still. http://moof.apache.org:8080/gump/ Also we didn't yet investigate Stefano's suggestion of sharing brutus with Apache Gump. > > Having our own live Cocoon instance(s) could make all the difference > > in the way we do our docs, so if there's an opportunity I think we > > should make it happen. Interesting co-incidence. We just started talking about this again yesterday at Forrest. We had shelved plans for live webapp and forrestbot until infrastructure was more ready. Looking better soon. > How much access these machines can handle I don't know - i.e. > infrastructure maintain minotaur at a level that can handle all of our > HTTP access to cocoon.apache.org. Whether a VM could handle hosting > cocoon.apache.org, I don't know. But if we stuck Apache with mod_cache > in front, who knows? Sounds like part of that discussion should happen over there. > > BTW, where did you learn all this, is there a list that I'm missing? > > infrastructure@ ? > > [EMAIL PROTECTED] Sit on there and read. You'll learn a lot! Yeah, it is great. Just like at any other Apache project, one learns heaps just by being there. While we are there, we can do our bit to help out by answering some user questions. You know the drill. Just like any other Apache project, Infrastructure is a group of enthusiastic volunteers. We need help. Only committers and invited guests can join. Anyone can post so that they can report perceived problems. http://www.apache.org/foundation/mailinglists.html#foundation-infrastructure -- David Crossley
RE: VMWare host for us @apache.org
[EMAIL PROTECTED] dijo: >> > Having our own live Cocoon instance(s) could make all the difference >> > in the way we do our docs, so if there's an opportunity I think we >> > should make it happen. > > I'd say go for this, although I won't be able to help (I never really got > past the phase where a Red Hat or Suse installation actually finished with > a > working machine). > >> >> ...In the meantime, using our existing mechanisms, we should do as >> >> Antonio suggested - improve the notes on the livesites >> page, stating: >> >> Put an entry entitled [LINK] Blah into bugzilla, and answer these >> >> questions. If you don't answer them, your request will not be >> >> considered. >> > >> > +1 >> >> Helma, what do you think? Could you create a patch for this? > > > Oops, me? Ok, I'll think about it (both content-wise and work-wise). Great ;-) Best Regards, Antonio Gallardo
RE: VMWare host for us @apache.org
> > Having our own live Cocoon instance(s) could make all the difference > > in the way we do our docs, so if there's an opportunity I think we > > should make it happen. I'd say go for this, although I won't be able to help (I never really got past the phase where a Red Hat or Suse installation actually finished with a working machine). > >> ...In the meantime, using our existing mechanisms, we should do as > >> Antonio suggested - improve the notes on the livesites > page, stating: > >> Put an entry entitled [LINK] Blah into bugzilla, and answer these > >> questions. If you don't answer them, your request will not be > >> considered. > > > > +1 > > Helma, what do you think? Could you create a patch for this? Oops, me? Ok, I'll think about it (both content-wise and work-wise). Bye, Helma
Re: VMWare host for us @apache.org
Bertrand Delacretaz wrote: Le 21 oct. 04, à 11:54, Upayavira a écrit : ...If we have needs for running our own stuff, e.g. having the latest Cocoon samples usable from the Cocoon website, we should make a request to the infrastructure team for a VM for ourselves, as soon as they have done the necessary hardware upgrades If it's debian I'm willing to help setup and co-administer such a machine. Could also help with other distros but it's really debian that I know the best, and apt-get is a big plus assuming the admin would be shared between several people. Me too (debian that is). Having our own live Cocoon instance(s) could make all the difference in the way we do our docs, so if there's an opportunity I think we should make it happen. How much access these machines can handle I don't know - i.e. infrastructure maintain minotaur at a level that can handle all of our HTTP access to cocoon.apache.org. Whether a VM could handle hosting cocoon.apache.org, I don't know. But if we stuck Apache with mod_cache in front, who knows? BTW, where did you learn all this, is there a list that I'm missing? infrastructure@ ? [EMAIL PROTECTED] Sit on there and read. You'll learn a lot! ...In the meantime, using our existing mechanisms, we should do as Antonio suggested - improve the notes on the livesites page, stating: Put an entry entitled [LINK] Blah into bugzilla, and answer these questions. If you don't answer them, your request will not be considered. +1 Helma, what do you think? Could you create a patch for this? Regards, Upayavira
VMWare host for us @apache.org (was: Link Livesites: Cocoon 2.1.5)
Le 21 oct. 04, à 11:54, Upayavira a écrit : ...If we have needs for running our own stuff, e.g. having the latest Cocoon samples usable from the Cocoon website, we should make a request to the infrastructure team for a VM for ourselves, as soon as they have done the necessary hardware upgrades If it's debian I'm willing to help setup and co-administer such a machine. Could also help with other distros but it's really debian that I know the best, and apt-get is a big plus assuming the admin would be shared between several people. Having our own live Cocoon instance(s) could make all the difference in the way we do our docs, so if there's an opportunity I think we should make it happen. BTW, where did you learn all this, is there a list that I'm missing? infrastructure@ ? ...In the meantime, using our existing mechanisms, we should do as Antonio suggested - improve the notes on the livesites page, stating: Put an entry entitled [LINK] Blah into bugzilla, and answer these questions. If you don't answer them, your request will not be considered. +1 -Bertrand smime.p7s Description: S/MIME cryptographic signature
