so for new changes to the doc (which will eventually go into release 1.1) i will add them to trunk. am i understanding this correctly in that i should add a copy of the current doc dir (/ci/www/projects/swift/guides) to trunk/docs (<a href="https://trac.ci.uchicago.edu/swift/browser/trunk/docs">https://trac.ci.uchicago.edu/swift/browser/trunk/docs</a>) & then commit my own changes to that?<br>
<br>~sk<br><br><div class="gmail_quote">On Thu, Oct 7, 2010 at 5:05 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 15:26 -0600, Michael Wilde wrote:<br>
> ----- "Justin M Wozniak" <<a href="mailto:wozniak@mcs.anl.gov">wozniak@mcs.anl.gov</a>> wrote:<br>
><br>
> > Yes, but I think that 1.0 is a release candidate- right? New material<br>
> ><br>
> > will go into trunk until we branch for 1.1 .<br>
><br>
> Justin, can you clarify this? I think we want to take most or all of<br>
> whats in the trunk *now*, and branch that for 1.0. That has not been<br>
> done yet, has it?<br>
<br>
</div>It has. For a long time. We have not yet released branches/1.0.<br>
<div><div></div><div class="h5"><br>
><br>
> If not, lets discuss when to make the branch, and especially how to test.<br>
><br>
> If its already been done, lets make sure we have all we want/need from trunk in the release branch.<br>
><br>
> I'm eager to see a 1.0 very soon.<br>
><br>
> - Mike<br>
><br>
> ><br>
> > On Thu, 7 Oct 2010, Sarah Kenny wrote:<br>
> ><br>
> > > sounds good.<br>
> > ><br>
> > > just want to verify (sorry to beat this to death):<br>
> > ><br>
> > > so, we alias the 'main guide' to 0.9 (as suggested) and any changes<br>
> > we make<br>
> > > will go to the doc in branches/1.0 which will then be the new alias<br>
> > for the<br>
> > > 'main guide' once we do the release.<br>
> > ><br>
> > ><br>
> > ><br>
> > > On Thu, Oct 7, 2010 at 3:45 PM, Justin M Wozniak<br>
> > <<a href="mailto:wozniak@mcs.anl.gov">wozniak@mcs.anl.gov</a>>wrote:<br>
> > ><br>
> > >><br>
> > >> Yup.<br>
> > >><br>
> > >><br>
> > >> On Thu, 7 Oct 2010, Mihael Hategan wrote:<br>
> > >><br>
> > >> To summarize:<br>
> > >>><br>
> > >>> There is a 1-1 mapping between branches and docs. One of the<br>
> > branches<br>
> > >>> (corresponding to the current release) gets linked from "main"<br>
> > (i.e.<br>
> > >>> main docs are the docs for the current release). So:<br>
> > >>><br>
> > >>> branches/0.9 <-> 0.9 docs<br>
> > >>> banches/0.8 <-> 0.8 docs<br>
> > >>> trunk <-> trunk docs<br>
> > >>><br>
> > >>> If current release is 0.9, then main docs = 0.9 docs.<br>
> > >>><br>
> > >>> On Thu, 2010-10-07 at 15:30 -0500, Justin M Wozniak wrote:<br>
> > >>><br>
> > >>>> I meant release branch. The valid branches could be hard-coded<br>
> > into the<br>
> > >>>> update.sh script. The main guide would be the doc associated<br>
> > with the<br>
> > >>>> current version. So right now, "main guide" would be aliased to<br>
> > 0.9 .<br>
> > >>>><br>
> > >>>> On Thu, 7 Oct 2010, Sarah Kenny wrote:<br>
> > >>>><br>
> > >>>> was thinking of what justin said, "I propose we have one web<br>
> > site but<br>
> > >>>>> multiple docs/guides directories, all accessible from the<br>
> > docs/index.php<br>
> > >>>>> page. Each of these would be associated with a branch"<br>
> > >>>>><br>
> > >>>>> i was assuming that whatever branch(es) these were associated<br>
> > with, that<br>
> > >>>>> doc<br>
> > >>>>> would somehow need to make its way to a main guide that we are<br>
> > pointing<br>
> > >>>>> users to.<br>
> > >>>>><br>
> > >>>>> ?<br>
> > >>>>><br>
> > >>>>><br>
> > >>>>> On Thu, Oct 7, 2010 at 3:17 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:55 -0500, Sarah Kenny wrote:<br>
> > >>>>>><br>
> > >>>>>>> so, in that case the 'main user doc' would be something<br>
> > *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<br>
> > branches<br>
> > >>>>>>><br>
> > >>>>>><br>
> > >>>>>> define "all current branches". We have:<br>
> > >>>>>> 1. Release branches<br>
> > >>>>>> 2. Trunk<br>
> > >>>>>> 3. Development branches (which are transient entities and only<br>
> > there to<br>
> > >>>>>> make trunk's life easier).<br>
> > >>>>>><br>
> > >>>>>> merged into it once we do a release?<br>
> > >>>>>>><br>
> > >>>>>>><br>
> > >>>>>>> On Thu, Oct 7, 2010 at 2:42 PM, Mihael Hategan<br>
> > <<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<br>
> > in<br>
> > >>>>>>> each branch<br>
> > >>>>>>> > are pushed to the main user doc when we do the release<br>
> > or am<br>
> > >>>>>>> i missing<br>
> > >>>>>>> > a step here?<br>
> > >>>>>>><br>
> > >>>>>>><br>
> > >>>>>>> That or we really have no "main doc" and instead we<br>
> > 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<br>
> > 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<br>
> > 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<br>
> > and<br>
> > >>>>>>> merging<br>
> > >>>>>>> > this seems to make<br>
> > >>>>>>> > >> sense to me (though feel free to suggest<br>
> > 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,<br>
> > 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<br>
> > to<br>
> > >>>>>>> the<br>
> > >>>>>>> > update.sh script and<br>
> > >>>>>>> > > manual modification of the docs/index.php page<br>
> > for<br>
> > >>>>>>> each<br>
> > >>>>>>> > version number.<br>
> > >>>>>>> > ><br>
> > >>>>>>> > > We may also want to have the feature changes<br>
> > (past<br>
> > >>>>>>> and<br>
> > >>>>>>> > future version<br>
> > >>>>>>> > > numbers) available on that page but I think<br>
> > 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<br>
> > of<br>
> > >>>>>>> doing so is<br>
> > >>>>>>> > minimal).<br>
> > >>>>>>> ><br>
> > >>>>>>> ><br>
> > >>>>>>><br>
> > >>>>>>><br>
> > >>>>>>><br>
> > >>>>>>><br>
> > >>>>>>><br>
> > >>>>>><br>
> > >>>>>><br>
> > >>>>>><br>
> > >>>>><br>
> > >>>><br>
> > >>><br>
> > >>><br>
> > >>><br>
> > >> --<br>
> > >> Justin M Wozniak<br>
> > >><br>
> > ><br>
> ><br>
> > --<br>
> > Justin M Wozniak<br>
> > _______________________________________________<br>
> > Swift-devel mailing list<br>
> > <a href="mailto:Swift-devel@ci.uchicago.edu">Swift-devel@ci.uchicago.edu</a><br>
> > <a href="http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel" target="_blank">http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel</a><br>
><br>
<br>
<br>
_______________________________________________<br>
Swift-devel mailing list<br>
<a href="mailto:Swift-devel@ci.uchicago.edu">Swift-devel@ci.uchicago.edu</a><br>
<a href="http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel" target="_blank">http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel</a><br>
</div></div></blockquote></div><br>