On 18/03/13 23:04, Markus Neteler wrote:
On Fri, Jan 11, 2013 at 9:53 AM, Rainer M Krug<r.m.k...@gmail.com> wrote:
...
Following the discussion, I would like to install GRASS 7 weekly snapshot. I relized the
"Binary"
link (http://grass.osgeo.org/download/software/) but it points back to the
Linux Download page,
but I could not find any binaries there for GRASS 7? Maybe this link should be
removed?
Just wondering, but not a problem, as I am going to install from source anyway.
In the past days I have cleaned up several of the Web pages.
I hope they are much clearer now. GRASS 7 downloads are now properly
mentioned as well.
Much clearer now !
I would like to take this debate as an opportunity to touch upon the
question of a possible tech-preview release of GRASS7.
Several reasons for that:
- More and more people are using it (and we are pushing more and more
people toward using it). Binaries are available for windows and mac, but
not for most Linux distributions. A preview release might make it easier
for these distributions to package grass7 and make it available to a
larger audience.
- In many institutions it is (understandably) not easy to convince
IT-managers to install development snapshots instead of released
software. Having an official release (even if it is only a tech-preview
release) should make it easier to install grass7 in institutional settings.
- I think that grass7 is in a form where we can start advertising it
more widely and more officially. In terms of timing, it would be great
to be able to get this out before FOSS4G.
- From my own egotistical viewpoint, I would love to be able to use
grass7 in my classes next school year, and having a release would make
it much easier for me to do that.
Concretely, I see the following type of procedure to make it possible:
- Freeze the svn repository for any direct new commits for a short
period (I'd say max 1-2 weeks). Only a few "release managers" should
still have direct commit access at this point. (Another way to do it
would be to keep commit rights open to anyone, and the role of the
release managers would be to control all commits and revert those that
aren't simple bug fixes during the freeze).
- Publish the state of the code at the beginning of the freeze as RC1
with a wide call for testing.
- Only bug fix* commits.
- Publish RC2 after some bug fixing (possibly after one week).
- Continue bug fixing*.
- Release tech-preview (possibly at the end of week 2) with a huge
disclaimer that this is a tech-preview release and not considered final
and stable.
- Open repository again for more general development.
I don't think we should create a release branch as this would just be a
tech-preview snaphot of the ongoing development.
This obviously implies that we plan ahead and that all developers know
when this freeze will happen, thus avoiding to commit any large and
fundamental changes just before the freeze. And that we all put aside
time during that freeze for testing and bug fixing.
What do you think ?
Moritz
_______________________________________________
grass-psc mailing list
grass-psc@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-psc
