<div dir="ltr"><div>Eric,</div>
<div>good proposal. a few minor things for consideration:</div>
<div>1) under phase 2 where you list the directyory structure for SVN repository, in addition to www and apps you might want to consider a 3rd type called libs or utilities, where libs or utilities refers to code or scripts or whatever that can be used by apps and www, for example code that converts UTC date time to epoch seconds, etc. i'm not suggesting you create anything currently (unless it exists) just suggesting mentioning it in the proposal as an option.</div>
<div>2)under release cycles item II.B.3 i recommend planning to merge these level of fixes out to development branches as well</div>
<div>3) under release cycles item III and IV may want to add a final step to each of these release processes to run a validation check to confirm that the release worked (i.e hit the public website), this might be obvious, but good to list out all the steps in the process just to be clear.</div>
<div>4) under critical and time-dependent modifications similar to item 2 i mentioned above, i recommend mergin these kind of fixes out to development branches as well. i recommend merging out to development sooner rather than waiting for development to complete and then trying the merge as the longer the files have to diverge the more potential for merging conflicts. but this can also be assessed on a case by case basis. however merging these fixes out to development branches may also prevent duplicate debugging from occuring on dev branches when the problem has already been fixed on the trunk. </div>
<div> </div>
<div>this last item leads me to a very minor thought relative to what is on the trunk versus what is on a branch, and maybe comes down to just a terminology issues. but just to share a different perspective, we made the trunk of our respository be the development code, such that if you get the "head" of the trunk you always get the latest and greatest code (which may or may not work because it is development). and then we create tags on the trunk for releases. and then if a release needs a fix made to a file that has already been modified for future development tasks (thus cannot be released) then we create a branch from that tag and make the mod's for the release on the branch. and then merge the release fix into the trunk (development) code. our theory is that development is on going and is dynamic (always changing) and is the core of what we do as, thus the trunk. releases become static and are not changing, and eventually become historical and thus "end" (so to speak), so they are the branches. </div>
<div> </div>
<div>hope that helps. oh and regarding seeing our dev tools (repository, wiki, bug tracking, etc), i don't have an office this week so i am working out of our dev lab, which is also moving by the end of this week, so it's rather touch and go for me this week. would it still be helpful to show you our stuff next week say maybe on tuesday afternoon? </div>
<div> </div>
<div>michelle <br><br></div>
<div class="gmail_quote">On Tue, Aug 5, 2008 at 2:21 PM, Eric Martinez <span dir="ltr"><<a href="mailto:emartinez@usgs.gov">emartinez@usgs.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"> We've been trying to come up with a set of procedures for developing and maintaining new and existing web content and applications. Attached is a draft proposal for this. Please read and let me know what you think. It necessarily adds overhead to development, but gains robustness, stability, and integrity. This is a very rough draft so please feel free to contact me with comments, questions, concerns, or suggestions.<br>
<br><br><br><br><br>Thanks,<br> ~Eric.<br><br><br></blockquote></div><br></div>