<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Times New Roman; font-size: 12pt; color: #000000'><br>----- "Sarah Kenny" <skenny@uchicago.edu> wrote:
<br>> was thinking of what justin said, "I propose we have one web site but multiple docs/guides directories,
all accessible from the docs/index.php page. Each of these would be
associated with a branch" <br>> <br>> i was assuming that whatever branch(es) these were associated with, that doc would somehow need to make its way to a main guide that we are pointing users to. <br><br>One way to organize this is that the Documentation page be organized like:<br><br>* Latest stable release<br>* Development trunk<br>* Special development branches<br>* Older stable release<br><br>And each of these is a replica of the current Documentation page, cleaned up to remove obsolete content.<br><br>- Mike<br> <br>> <br>> ?<br>> <br>> <br>> <div class="gmail_quote">>
On Thu, Oct 7, 2010 at 3:17 PM, Mihael Hategan <span dir="ltr"><<a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>></span> wrote:<br>> <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">> On Thu, 2010-10-07 at 14:55 -0500, Sarah Kenny wrote:<br>>
> so, in that case the 'main user doc' would be something *like*<br>>
> <a href="http://www.ci.uchicago.edu/swift/docs10/index.php" target="_blank">http://www.ci.uchicago.edu/swift/docs10/index.php</a> ?<br>>
><br>>
> and THAT would include the updates from all the current branches<br>>
<br>>
</div>define "all current branches". We have:<br>>
1. Release branches<br>>
2. Trunk<br>>
3. Development branches (which are transient entities and only there to<br>>
make trunk's life easier).<br>>
<div><div></div><div class="h5">> <br>>
> merged into it once we do a release?<br>>
><br>>
><br>>
> On Thu, Oct 7, 2010 at 2:42 PM, Mihael Hategan <<a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>><br>>
> wrote:<br>>
> On Thu, 2010-10-07 at 14:39 -0500, Sarah Kenny wrote:<br>>
> > so, in this scenario, the changes to the doc that exist in<br>>
> each branch<br>>
> > are pushed to the main user doc when we do the release or am<br>>
> i missing<br>>
> > a step here?<br>>
><br>>
><br>>
> That or we really have no "main doc" and instead we link from<br>>
> every<br>>
> release. Though I feel odd about that.<br>>
><br>>
> ><br>>
> > On Thu, Oct 7, 2010 at 2:34 PM, Mihael Hategan<br>>
> <<a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>><br>>
> > wrote:<br>>
> ><br>>
> > On Thu, 2010-10-07 at 14:28 -0500, Justin M Wozniak<br>>
> wrote:<br>>
> > > On Thu, 7 Oct 2010, Sarah Kenny wrote:<br>>
> > ><br>>
> > > > On Thu, Oct 7, 2010 at 1:08 PM, Mihael Hategan<br>>
> > <<a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>> wrote:<br>>
> > > ><br>>
> > > >> Right. I think 1.0/4.1.7 should go out soon.<br>>
> > > ><br>>
> > > > ok, so i guess we should decide what 'soon'<br>>
> means ;) i am<br>>
> > currently going<br>>
> > > > thru the old bugs in bugzilla (at least trying<br>>
> to close<br>>
> > out things that have<br>>
> > > > been already fixed or are no-longer applicable,<br>>
> etc), but<br>>
> > perhaps it would<br>>
> > > > be good to determine if there are bigger issues<br>>
> outside of<br>>
> > that that still<br>>
> > > > need to be dealt with before we can put what<br>>
> we've got<br>>
> > into a stable release<br>>
> > > > and determine a time-frame...anything come to<br>>
> mind?<br>>
> > > ><br>>
> > > > as far as documentation...does it make sense for<br>>
> each<br>>
> > branch to have a full<br>>
> > > > copy of /ci/www/projects/swift under it which<br>>
> can then be<br>>
> > merged with the<br>>
> > > > main/live copy whenever the code is merged?<br>>
> admittedly, i<br>>
> > know nothing about<br>>
> > > > docbook, but from the standpoint of updating and<br>>
> merging<br>>
> > this seems to make<br>>
> > > > sense to me (though feel free to suggest another<br>>
> way :)<br>>
> > > ><br>>
> > > > ~sk<br>>
> > ><br>>
> > > I was looking at the update.sh script earlier<br>>
> today- I<br>>
> > propose we have one<br>>
> > > web site but multiple docs/guides directories, all<br>>
> > accessible from the<br>>
> > > docs/index.php page. Each of these would be<br>>
> associated with<br>>
> > a branch.<br>>
> > > So, similar to the existing "Historical" section<br>>
> but for<br>>
> > "future" branches<br>>
> > > as well. That would take a small modification to<br>>
> the<br>>
> > update.sh script and<br>>
> > > manual modification of the docs/index.php page for<br>>
> each<br>>
> > version number.<br>>
> > ><br>>
> > > We may also want to have the feature changes (past<br>>
> and<br>>
> > future version<br>>
> > > numbers) available on that page but I think those<br>>
> can be<br>>
> > plain text.<br>>
> > > These could be pulled directly from SVN as well.<br>>
> > ><br>>
> ><br>>
> ><br>>
> > I agree. I generally believe that documentation<br>>
> should be kept<br>>
> > in sync<br>>
> > with releases (and I also think that the effort of<br>>
> doing so is<br>>
> > minimal).<br>>
> ><br>>
> ><br>>
><br>>
><br>>
><br>>
><br>>
<br>>
<br>>
</div></div></blockquote></div><br>>
<br>> _______________________________________________
Swift-devel mailing list
Swift-devel@ci.uchicago.edu
http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel
<br><br>-- <br>Michael Wilde<br>Computation Institute, University of Chicago<br>Mathematics and Computer Science Division<br>Argonne National Laboratory<br><br></div></body></html>