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>?<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">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">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">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">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>