I don't think that any of the subprojects publish their sites directly to people.apache.org. The standard workflow is as follows:
1. Generate the site locally. 2. Commit the site to SVN. 3. Do an svn update on people.apache.org. 4. Wait for the find+rsync stuff to synchronize the live site. This can take several hours. SvnPubSub would simplify this process a lot because it eliminates items 3 and 4. I think that in order to use SvnPubSub, the only requirement for us would be consolidate the different parts of the site into a single tree in SVN (right now, different subdirectories on people.apache.org:/www/ws.apache.org are working directories checked out from different locations in SVN) [1]. Since there are still a couple of pending todo items from the Axis TLP migration (there is still some Axis stuff on ws.apache.org), this would be a good occasion to work on this consolidation. Anyway, for the SvnPubSub vs. find+rsync question, I fully agree with the point of view of the infrastructure team. Therefore I think it's best to include SvnPubSub in the scope of the Web site changes as soon as possible, and not to wait for 2012. However, that would mean that your export tool must be able to commit changes to SVN. Do you think that it's feasible to include that requirement into the scope? Andreas [1] Looking at the source code of the commit hook for SvnPubSub, I don't see anything that would be able to handle SVN externals, so we really need to move the different parts of the site into a single location. On Mon, Feb 14, 2011 at 16:22, Daniel Kulp <[email protected]> wrote: > On Sunday 13 February 2011 5:02:26 PM Andreas Veithen wrote: >> The very same idea of using an external tool instead of the export >> plugin also came to my mind, but I didn't have the time to explore >> this idea further. I'm +1 for this provided that the following >> conditions are met: >> >> 1. We have volunteers to implement the Confluence solution. That seems >> to be the case. > > Yep. :-) > >> 2. We can make sure that this solution doesn't cause us troubles with >> [email protected]. > > Well, I cannot guarantee that. infra seems to not like anything written in > java, builds with java, has anything remotely to do with java, or even has the > letters 'J', 'A', and 'V' in the name. :-( > >> 3. We have no strong proponents of the Markdown solution who would >> also volunteer to do it with their solution. (If there are volunteers, >> then we should evaluate more thoroughly the pros and cons of the two >> solutions) >> 4. There is no impact on subprojects that want to continue using >> (Maven) generated sites. > > This is something that will need to be re-investigated longer term. The > external confluence exporter certainly will allow that short term. The CMS > WOULD have an issue as the entire site needs to be committed into svn in a > single tree. Thus, the projects would all need to be reconfigured to stick > them into a particular area of the svn checkout. > > Longer term (like in 2012), we WILL need to re-look at this. infra wants all > sites to go through svnpubsub which will require all site to be in svn. That > said, I would expect the maven folks to have something figured out by then > since the entire maven site is built that way. Thus, it may or may not be > something we'll need to worry about. > > > Dan > > >> >> Andreas >> >> On Fri, Feb 11, 2011 at 13:15, Benson Margulies <[email protected]> > wrote: >> > Currently, the deployed site is a 'forrest' antique. >> > >> > We have some pretty reasonable content sitting in Confluence. As you >> > may know, in general, intrastructure@apache is pushing projects from >> > Confluence to their new Markdown+svn CMS. The reason is their problems >> > with the generic export technology used historically with Confluence. >> > >> > Some of us are not really thrilled at editing Markdown in a text >> > editor or web browser. >> > >> > Dan Kulp has gone and created an alternative Confluence export device. >> > It meets the strictures of infrastructure@ and it allows site >> > maintenance in Confluence. >> > >> > I'd like to make ws.apache.org use Confluence (with some maven site >> > output as appropriate), using Dan's technology. Anybody object? >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] > > -- > Daniel Kulp > [email protected] > http://dankulp.com/blog > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
