[Live-demo] 2.0.3 testing

[Cameron Shorter]

Hamish wrote:
> Cameron  wrote:
>   
>> Hamish, I think this is a good idea,
>> in particular being able to create a freeze of a build
>> scripts so that it can be reproduced later.
>>
>> I suggest going one step further.
>> Our build process starts by downloading everything from
>> livedvd/gisvm/trunk/ 
>>     
>
> the only change you would have to make is to replace trunk/ with
> $VERSION/.
>   
I suggest not using either "trunk/" or "$VERSION" in the scripts. During 
development, people will want to run the build scripts without creating 
a release tag first.
>   
>> and get we use wget to get files out of svn during the build process.
>>     
>
> right.
>
>   
>> What I suggest is that we:
>> 1. Instead of sourcing files by "wget -c http://svn.osgeo.org/livedvd/gisvm/trunk/dir/file" we
>> should source the file from the version we have already
>> downloaded which is currently at:
>> "~/gisvm/trunk/bin/../dir/file".  We can rename the
>> gisvm svn directory so that it is one below trunk, which
>> will make scripts easier to run.
>>     
>
> I'm not sure if you mean rename the top dir in svn (I'm not a huge fan of
> that) 
-1 No.
> or to save the copy locally at /usr/local/share/gisvm/[bin|doc|...]
> instead of /usr/local/share/gisvm/trunk/[bin|doc|...] (I'm a big fan of
> that idea)
>   
+1 Yes.
> none the less, for this release/tag it is now history and my main
> intention is to archive that, warts and all.
>   
+1 Agreed.
> after tagging 2.0.3, sure go for it in the release branch. but we
> shouldn't start rewriting history any more than necessary in the mean
> time.
>   
+1
>  
>   
>> I suggest that we start making use of the tags directory.
>> So that I can check out the 2.0.3. At times it is important
>> to distinguish between 2.0.3 and 2.0.4 if there are users
>> for both version.
>>     
>
> yup, that's exactly the idea.
>
>   
>> This is more important than using the branch directory. In fact, I
>> suspect that we will avoid the need to use the branch directory for
>> the most part, unless we decide to create an "unstable" build list
>> and a "stable" build list.
>>     
>
> The release branch is needed & useeful, really 2.0.4 should come from
> that not trunk. Otherwise you tend lock up & hold back trunk for any new
> development which necessarily requires divergence and breaking with the
> old ways. It doesn't really cost nuthin to have it but leaves some doors
> open if we need them.
>
> Anyway, the trunk/release branch/tag model is used as standard practice
> everywhere Subversion is used, and is similar in theory as to how CVS
> worked things before it. I can't really comment on what Bzr, Git, and
> Mercurial do to manage these things.
>   
Yes, I agree with all this in the general sense, and only have a minor 
suggestion on semantics.
Namely, I suggest the process should be:
* work on trunk
* create release
* copy release to tags/<release>
* keep working on trunk
* If and only if there is a need to patch a release, then create a 
branch, by copying the release that you have been working on.

But I'm not too fussed, and what you are suggesting works too. (It is 
just a little more effort at the start keeping trunk synced with the 
branch).
> Merging fixes between branches is trivial; I've already added some hints
> on the wiki, and there is lots more on the subject in the SVN book:
>  http://svnbook.red-bean.com/
>
> So sure it is possible to break from traditions, but in general it's well
> worn ground arrived at after years of toil, so I would argue to adopt the
> norms and take advantage of the fundamental benefits of using svn. 
>
> (just my 2c)
>
>
>   
>> 2. I suggest that we store a copy of the /tmp download
>> directory. Some projects are likely to move their download
>> source location, and if they do, then it will be hard for us
>> to reproduce an old release.
>>     
>
> This is a very good idea. SVN is not the place for big binary dataset
> downloads, download.osgeo.org or the like is much better for that.
> I wouldn't bother archiving the Windows and Mac installers, as they
> have such a short shelf life.
>
>
> I'll wait for word from Alex re. README.adjustments to explain what
> happened outside the scripts (if anything) before continuing.
>
>
> regards,
> Hamish
>
>
>
>       
> _______________________________________________
> Live-demo mailing list
> Live-demo at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/live-demo
>   


-- 
Cameron Shorter
Geospatial Systems Architect
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254

Think Globally, Fix Locally
Geospatial Solutions enhanced with Open Standards and Open Source
http://www.lisasoft.com