[jira] Commented: (FOR-392) deploy of deleted files
[ http://issues.apache.org/jira/browse/FOR-392?page=comments#action_12358477 ] Dave Brondsema commented on FOR-392: Ant has a sync task, but that's only for local copies. I guess it would be hard to implement for all types of deploys. I had originally thought it would be useful on some situations. But I'm not using forrestbot anymore. deploy of deleted files --- Key: FOR-392 URL: http://issues.apache.org/jira/browse/FOR-392 Project: Forrest Type: Task Components: Forrestbot Versions: 0.7 Reporter: Dave Brondsema Priority: Minor Investigate what happens when you delete a file, and then deploy your site. All deploy implementations should probably delete the remote file, if possible. Maybe make it configurable whether it is to be deleted or not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: problem with docs at forrest.apache.org/docs/dev/
Quoting David Crossley [EMAIL PROTECTED]: Ross Gardler wrote: David Crossley wrote: Ross Gardler wrote: How do people suggest I integrate the plugin docs with the main website docs? If they went under docs/plugins/$plugin-name/ then they will fit better with the versioning system described above. OK, that's where I'll put them then. I assume we want to SVN them into place in the way I've prototyped (see commit above), rather than duplicate the xdocs in the docs-author site. It would be nice to have the docs available locally too, but that sounds hard to achieve. So yes, do what you said. Note, that the point to link into these docs will therefore be docs/plugins/index.html. That page will contain a link to all the individual plugin documents. One more thing that struck me about plugins. We have a potential nightmare with versioning docs. There are two version numbers we can work against, the Forrest one and the plugin one. The idea is that plugins can be release independently of Forrest. So we could have Forrest 0.7 with OK for versions 0.1, 0.2 and 0.3 of plugin X, whilst 0.4 will only work in Forrest 0.8. Do we want to worry about maintaining docs for each version of the plugin as well? For example f.o.a/0.7/docs/plugins/o.a.f.p.PLUGINNAME/0.1 f.o.a/0.7/docs/plugins/o.a.f.p.PLUGINNAME/0.2 f.o.a/0.7/docs/plugins/o.a.f.p.PLUGINNAME/0.3 f.o.a/0.8/docs/plugins/o.a.f.p.PLUGINNAME/0.4 Note that in this case, if 0.4 of the plugin works in 0.7 of Forrest we should also have the 0.4 plugin docs in the 0.7 branch. This starts to get horribly complicated. Erk, the same horrid thought ocurred to me. I hope that we can get away with just having one set of docs for each major version. Let us start with that and change it later if we need to. As i say that, it sounds very unsatisfactory ... i don't know what to do. Yes, lets try to keep it simple for now: release the plugins with each major version. When that becomes insufficient (e.g. if a plugin takes off and makes its own major changes releases within one forrest release), we can tackle it again. I think in that case, the plugin should be documented seperately from the main forrest docs and it can say what versions of forrest it is compatible with. -- Dave Brondsema : [EMAIL PROTECTED] http://www.brondsema.net : personal http://www.splike.com : programming http://csx.calvin.edu : student org
Re: problem with docs at forrest.apache.org/docs/dev/
David Crossley wrote: David Crossley wrote: David Crossley wrote: David Crossley wrote: Dave Brondsema wrote: /docs/dev/ nested below /docs/ seems weird. I think it would be better to host the current stable release at a url like: /docs/0.7/. This would also permit us to keep documentation for all old releases (although we would probably want warnings on them if they are too old). 0.6 docs had to be kept at /docs/ because they didn't have a split docs/site structure so I kept it as-is. I had been thinking we'd move to something like /docs/0.7/ for future releases, but I can't find any discussion about this in particular. We probably jumped to the conclusion that we only would have the current release and the current dev version. I agree with this new approach. So would it be like this ... Assuming that we don't want to version the top-level docs. Is that a legitimate assumption? It would change our layout if we do. I don't know the answer yet either. f.a.o/ ... the top-level docs, from trunk/site-author f.a.o/docs/ ... is .htaccess to redirect to current release docs. f.a.o/docs/0.6/ ... from the forrest_06_branch (*) f.a.o/docs/0.7/ ... from the forrest_07_branch, when it is released f.a.o/docs/0.8/ ... the next development, from future trunk/docs-author/ Let us see what the other solution would be. (Say that current release is 0.7) f.a.o/ ... the top-level docs, .htaccess to redirect to 0.7 top-level f.a.o/docs/ ... .htaccess to redirect to 0.7/docs/ f.a.o/0.6/ ... from the forrest_06_branch f.a.o/0.6/docs/ ... from the forrest_06_branch f.a.o/0.7/ ... from the forrest_07_branch/site-author/ f.a.o/0.7/docs/ ... from the forrest_07_branch/docs-author/ f.a.o/0.8/ ... the next development, from the trunk/site-author/ f.a.o/0.8/docs/ ... from the trunk/docs-author/ I have done local tests with both methods. The second way seems much easier and leaves more scope for the future. To use the first way, would also mean a re-structure of the docs part of forrest_06_branch. --David Furthering this idea, if we are versioning and storing docs-author and site-author, do we really need to store them seperately? As you said, this method would mean we won't have to restructure the forrest_06_branch docs into two parts. -- Dave Brondsema : [EMAIL PROTECTED] http://www.splike.com : programming http://csx.calvin.edu : student org http://www.brondsema.net : personal signature.asc Description: OpenPGP digital signature
Re: better use of Jira for Forrest
Quoting David Crossley [EMAIL PROTECTED]: Done. That clarifies the Roadmap. Do any people out in the Forrest dev community know other things that we can do to improve our use of Jira? Or point to projects that use it well. Many projects periodically do a bug day where everyone spends time investigating, updating and resolving issues. This could be useful for us because it seems that a lot of our issues are very old and/or incomplete. There are also minor issues that very few people care about (maybe nobody anymore) which are not worth spending time on. The problem, of course, would be to coordinate such a day, especially given our geographical spread. It doesn't have to be simultaneous work, though. We could even do a week of bug-squashing. -- Dave Brondsema : [EMAIL PROTECTED] http://www.brondsema.net : personal http://www.splike.com : programming http://csx.calvin.edu : student org
Re: better use of Jira for Forrest
Quoting Ross Gardler [EMAIL PROTECTED]: Dave Brondsema wrote: Quoting David Crossley [EMAIL PROTECTED]: Done. That clarifies the Roadmap. Do any people out in the Forrest dev community know other things that we can do to improve our use of Jira? Or point to projects that use it well. Many projects periodically do a bug day where everyone spends time investigating, updating and resolving issues. This could be useful for us because it seems that a lot of our issues are very old and/or incomplete. There are also minor issues that very few people care about (maybe nobody anymore) which are not worth spending time on. The problem, of course, would be to coordinate such a day, especially given our geographical spread. It doesn't have to be simultaneous work, though. We could even do a week of bug-squashing. I would (time allowing - that's a coordination issue) participate in any such activity. I'd like to propose something slightly different though. My motivation for the slight variation is that we are, as you say, a small number of developers with a wide distribution across the time zones. Lets use the distribution to our advantage and try and use this time to bring in some more developers. There are a number of folk who have recently started to explore the inner workings of Forrest. I doubt that they have much inclination for fixing outstanding bugs - where's the fun in working out how something works to fix a bug that isn't affecting them. I am sure they are more interested in doing cool new things. If we can find a way to coordinate things so that there will be at least one core developer available via some kind of chat mechanism (instant message or even voice, via Skype) then that developer would be available to to guide people in fixing bugs and would be able immediately commit the patches. We might therefore be able to attract some other developers. I'm up for whatever we decide is best. Most groups use an irc channel for communication. For us, we could use irc.freenode.net#forrest Yes, we should involve end-users by asking them to help with their particular bugs of interest. Some more info about bug days: http://www.mozillazine.org/articles/article2151.html http://www.python.org/moin/PythonBugDay http://developer.gnome.org/projects/bugsquad/triage/ -- Dave Brondsema : [EMAIL PROTECTED] http://www.brondsema.net : personal http://www.splike.com : programming http://csx.calvin.edu : student org
Re: problem with docs at forrest.apache.org/docs/dev/
Ross Gardler wrote: David Crossley wrote: Just a quick note, gotta rush out now. Yes there was stacks of discussion on this topic, but its good to be sure that we all understand, and maybe there is a flaw. The docs that are currently at docs/dev/ are 0.7-dev They will move to /docs/ when the next release happens. Then /docs/dev/ will become 0.8-dev and 0.6 (i.e. current /docs/) goes offline. Yes, that's the problem, all the mail archive links will be broken (in the sense they will refer to a different document from that referred to when the question was answered). Ross /docs/dev/ nested below /docs/ seems weird. I think it would be better to host the current stable release at a url like: /docs/0.7/. This would also permit us to keep documentation for all old releases (although we would probably want warnings on them if they are too old). 0.6 docs had to be kept at /docs/ because they didn't have a split docs/site structure so I kept it as-is. I had been thinking we'd move to something like /docs/0.7/ for future releases, but I can't find any discussion about this in particular. We should give links to documentation using a stable release, not /docs/dev (unless of course the issues in question is new to the dev version). That will keep all of our archived links good. -- Dave Brondsema : [EMAIL PROTECTED] http://www.splike.com : programming http://csx.calvin.edu : student org http://www.brondsema.net : personal signature.asc Description: OpenPGP digital signature
Re: merging separate sets of generated docs, default tabs (Was: svn commit: r157791)
Ok. What about href=/docs? I think because it is a 'href' it would keep it from failing the build, and it would still be relative. Regarding the 2nd change: I removed the project-related tabs from docs-author, so that the docs would be completely independent. This lets a user have a local copy of the docs with no broken links; it is also like the way the httpd docs are. Any problem with this? David Crossley wrote: This was deliberate. We will eventually need to find a better way to link separate sets of documentation. Apache Cocoon has this same issue. The full URLs is not a proper solution. Apache websites need to be able to be mirrored. For example, this coming weekend all Apache websites are going to fail-over to eu.apache.org while infrastructure work is being done. --David Author: brondsem Date: Wed Mar 16 11:27:36 2005 New Revision: 157791 URL: http://svn.apache.org/viewcvs?view=revrev=157791 Log: these tab links were breaking; point to the full url of the files created from docs-author Modified: forrest/trunk/site-author/content/xdocs/tabs.xml Modified: forrest/trunk/site-author/content/xdocs/tabs.xml URL: http://svn.apache.org/viewcvs/forrest/trunk/site-author/content/xdocs/tabs.xml?view=diffr1=157790r2=157791 == --- forrest/trunk/site-author/content/xdocs/tabs.xml (original) +++ forrest/trunk/site-author/content/xdocs/tabs.xml Wed Mar 16 11:27:36 2005 @@ -35,7 +35,7 @@ tab id=home label=Welcome dir=/ tab id=project label=Project dir= indexfile=contrib.html/ -tab id=docs label=Documentation dir=docs// -tab id=howto label=How-To dir=howto// +tab id=docs label=Documentation href=http://forrest.apache.org/docs/!-- change to /docs/0.7 after we make the 0.7 release and get rid of 0.6 doc structure -- +tab id=howto label=How-To href=http://forrest.apache.org/howto/!-- change to /docs/0.7/howto -- /tabs - Author: brondsem Date: Wed Mar 16 09:46:03 2005 New Revision: 157779 URL: http://svn.apache.org/viewcvs?view=revrev=157779 Log: documentation stands alone, not integrated with the project site Modified: forrest/trunk/docs-author/content/xdocs/tabs.xml Modified: forrest/trunk/docs-author/content/xdocs/tabs.xml URL: http://svn.apache.org/viewcvs/forrest/trunk/docs-author/content/xdocs/tabs.xml?view=diffr1=157778r2=157779 == --- forrest/trunk/docs-author/content/xdocs/tabs.xml (original) +++ forrest/trunk/docs-author/content/xdocs/tabs.xml Wed Mar 16 09:46:03 2005 @@ -36,8 +36,6 @@ !-- FIXME: FOR-447 tab id=home label=Welcome dir=../..// -- -tab id=home label=Welcome dir= indexfile=../../mail-lists.html/ -tab id=project label=Project dir= indexfile=../../contrib.html/ tab id=docs label=0.7-dev Documentation dir=/ indexfile=index.html tab id=core label=Core indexfile=your-project.html/ tab id=forrestbor label=ForrestBot indexfile=forrestbot.html/ -- Dave Brondsema : [EMAIL PROTECTED] http://www.splike.com : programming http://csx.calvin.edu : student org http://www.brondsema.net : personal signature.asc Description: OpenPGP digital signature
Re: Hugo ? - Open Writer Plugin.
Cyriaque Dupoirieux wrote: Hi, Did you remarked that there is a lot of hugo every where when you generate with Open Writer Plugin ? Can you provide an example file (ok to send to me personally) so I can test this? The OO.o plugin does not properly handle headers, so you may encounter other weird issues too. I think things work best if you have an ordered heirarchy of headings, like this: heading1 heading2 heading2 heading2 heading3 heading2 heading1 heading2 and not jump from 1 to 3 for example because the stylesheet doesn't know how to create proper sections out of that. -- Dave Brondsema : [EMAIL PROTECTED] http://www.splike.com : programming http://csx.calvin.edu : student org http://www.brondsema.net : personal signature.asc Description: OpenPGP digital signature
Re: site: link construct broken in aggragated PDFs?
Claus Bech Rasmussen - TELMORE wrote: Hi all, When creating an aggregated PDF, my site: links are dead - is this a known bug? Is there a way I can fix it? -claus There's several known problems related to linking and image references in aggregate pages, and that's one of them (issue FOR-147). Unfortunately there's no easy fix. -- Dave Brondsema : [EMAIL PROTECTED] http://www.splike.com : programming http://csx.calvin.edu : student org http://www.brondsema.net : personal signature.asc Description: OpenPGP digital signature
