Hi,
any reason to retain the /trunk/ part of the grass-web SVN? Can we move the contents ../ just like the grass-addons repo?
(coordinated with website scripts of course)
Hamish
Hamish wrote:
any reason to retain the /trunk/ part of the grass-web SVN?
How else would you check out the trunk?
Can we move the contents ../
If you did that, checking out https://svn.osgeo.org/grass/grass/ would
check out all of the branches and tags as subdirectories alongside the
code from the trunk.
just like the grass-addons repo?
It's grass-addons which is wrong; AFAICT, there is no way to create
branches or tags for it.
--
Glynn Clements <glynn@gclements.plus.com>
Hi well,
from my point of view would be the best SVN repo structure
grass/
/trunk
/grass
/addons
/web
/branches
/tags
Too late to change layout in this way.
Martin
2008/4/18, Glynn Clements <glynn@gclements.plus.com>:
Hamish wrote:
> any reason to retain the /trunk/ part of the grass-web SVN?
How else would you check out the trunk?
> Can we move the contents ../
If you did that, checking out https://svn.osgeo.org/grass/grass/ would
check out all of the branches and tags as subdirectories alongside the
code from the trunk.> just like the grass-addons repo?
It's grass-addons which is wrong; AFAICT, there is no way to create
branches or tags for it.--
Glynn Clements <glynn@gclements.plus.com>_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *
Hamish wrote:
> any reason to retain the /trunk/ part of the grass-web SVN?
Glynn:
How else would you check out the trunk?
grass-web has no branches or tags, so trunk is redundant.
-svn checkout https://svn.osgeo.org/grass/grass-web/trunk/
+svn checkout https://svn.osgeo.org/grass/grass-web/
> Can we move the contents ../
If you did that, checking out https://svn.osgeo.org/grass/grass/ would
check out all of the branches and tags as subdirectories alongside the
code from the trunk.
I mean https://svn.osgeo.org/grass/grass-web/trunk/,
not /grass/grass/trunk/. they are two different repos.
> just like the grass-addons repo?
It's grass-addons which is wrong; AFAICT, there is no way to create
branches or tags for it.
I suppose it is possible that you might want to tag a snapshot of both
the website and the addons. e.g. when we go to sea for some field
equipment the manufacturer provides a full copy of their website contents
on CD so you can look up FAQs etc even with no internet access. I suppose
the same problem exists for many field researchers.
But would you really need to tag that? why not just burn the latest
checkout with a timestamp in the dir name.
Hamish
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Hamish wrote:
> > any reason to retain the /trunk/ part of the grass-web SVN?
Glynn:
> How else would you check out the trunk?grass-web has no branches or tags, so trunk is redundant.
-svn checkout https://svn.osgeo.org/grass/grass-web/trunk/
+svn checkout https://svn.osgeo.org/grass/grass-web/> > Can we move the contents ../
>
> If you did that, checking out https://svn.osgeo.org/grass/grass/ would
> check out all of the branches and tags as subdirectories alongside the
> code from the trunk.I mean https://svn.osgeo.org/grass/grass-web/trunk/,
not /grass/grass/trunk/. they are two different repos.
Right; I initially overlooked the fact that you were referring to
grass-web rather than grass.
But, if you're bothering to keep the website under version control,
you may as well keep the option to at least create tags (branches
probably wouldn't be useful, although you can never say for sure).
Or, is the only reason for keeping the website in SVN to provide an
easy way for people to edit it?
[That would be mildly ironic, as SVN's remote repositories are
implemented using WebDAV, which was originally designed for editing
websites.]
--
Glynn Clements <glynn@gclements.plus.com>
On Sat, Apr 19, 2008 at 6:35 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:
...
But, if you're bothering to keep the website under version control,
you may as well keep the option to at least create tags (branches
probably wouldn't be useful, although you can never say for sure).
Neither tags nor branches are useful for *GRASS* Web.
Or, is the only reason for keeping the website in SVN to provide an
easy way for people to edit it?
Right.
Unfortunately it doesn't really scale/disctribute. Also our attempts to go for
a CMS do not (yet?): http://grass-dev.osgeo.net/
Contributors sorted by name:
Name #commits percentage
andreas 1 0,04
bernhard 31 1,11
bob 5 0,18
brad 1 0,04
carl 1 0,04
cedric 1 0,04
cho 4 0,14
danielc 1 0,04
hamish 336 12,05
helena 17 0,61
jachym 9 0,32
maciej 2 0,07
markus 1983 71,13
martin 64 2,30
martinl 18 0,65
michael 9 0,32
moritz 20 0,72
neteler 82 2,94
paul 20 0,72
radim 19 0,68
scott 132 4,73
serek 4 0,14
smitch 5 0,18
soeren 1 0,04
stephan 6 0,22
william 12 0,43
wolf 3 0,11
---------------
2787 total (27 contributors)
Anyway...
Markus
On 19/04/08 07:52, Markus Neteler wrote:
On Sat, Apr 19, 2008 at 6:35 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:
...But, if you're bothering to keep the website under version control,
you may as well keep the option to at least create tags (branches
probably wouldn't be useful, although you can never say for sure).Neither tags nor branches are useful for *GRASS* Web.
Or, is the only reason for keeping the website in SVN to provide an
easy way for people to edit it?Right.
Unfortunately it doesn't really scale/disctribute. Also our attempts to go for
a CMS do not (yet?): http://grass-dev.osgeo.net/
I think policy on that is not very clear (at least not for me). Up to now I've understood this site as somethink like a test, nothing more. At this stage we have several sites and it just is a bit confusing to me... Could you remind me of the official strategy and timing ? Once that is clear, maybe we should decide on a "web site party", i.e. a collective and concerted effort during a few days to put everything in place ?
Contributors sorted by name:
Name #commits percentage
[...]
moritz 20 0,72
Funny, I have no memory of committing anything on this site... Any way I can see what I did ? 
Moritz
On Mon, Apr 21, 2008 at 2:53 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
On 19/04/08 07:52, Markus Neteler wrote:
> On Sat, Apr 19, 2008 at 6:35 AM, Glynn Clements
> <glynn@gclements.plus.com> wrote:
...
> a CMS do not (yet?): http://grass-dev.osgeo.net/
>I think policy on that is not very clear (at least not for me). Up to now
I've understood this site as somethink like a test, nothing more.
The idea was to populate it and then switch it over.
At this stage we have several sites and it just is a bit confusing to me... Could
you remind me of the official strategy and timing ?
Apparently there is no (more) timing...
Once that is clear,
maybe we should decide on a "web site party", i.e. a collective and
concerted effort during a few days to put everything in place ?
That would be cool.
> Contributors sorted by name:
> Name #commits percentage
>
[...]> moritz 20 0,72
>Funny, I have no memory of committing anything on this site... Any way I
can see what I did ?
Sure: get svn2cl and run it in GRASS-Web-SVN. See
http://trac.osgeo.org/grass/wiki/WebPagesManagement
Markus
On 22/04/08 10:20, Markus Neteler wrote:
On Mon, Apr 21, 2008 at 2:53 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:On 19/04/08 07:52, Markus Neteler wrote:
On Sat, Apr 19, 2008 at 6:35 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:...
a CMS do not (yet?): http://grass-dev.osgeo.net/
I think policy on that is not very clear (at least not for me). Up to now
I've understood this site as somethink like a test, nothing more.The idea was to populate it and then switch it over.
At this stage we have several sites and it just is a bit confusing to me... Could
you remind me of the official strategy and timing ?Apparently there is no (more) timing...
Once that is clear,
maybe we should decide on a "web site party", i.e. a collective and
concerted effort during a few days to put everything in place ?That would be cool.
Contributors sorted by name:
Name #commits percentage[...]
moritz 20 0,72
Funny, I have no memory of committing anything on this site... Any way I
can see what I did ?Sure: get svn2cl and run it in GRASS-Web-SVN. See
http://trac.osgeo.org/grass/wiki/WebPagesManagement
Ok, I see that your numbers were not about the Drupal site, but about the grass-web repository, which, unless I completely misunderstand the functioning of Drupal, doesn't contain the Drupal site.
Moritz
re. the move to Drupal website:
http://grass-dev.osgeo.net/
(rambling thoughts follow)
> I think policy on that is not very clear (at least not for me). Up
> to now I've understood this site as somethink like a test, nothing
> more.
...
> At this stage we have several sites and it just is a bit confusing to
> me... Could you remind me of the official strategy and timing ?
http://grass.osgeo.org/wiki/Web_Migration_to_Drupal
re official strategy, I am unhappy with a "blog-like" homepage and await
to see a fleshed-out demo of what the homepage, downloads page, and
screenshots page could look like before being able to support a move away
from the current system. What I see now is a RSS feed/blog, not a
structured portal suitable as the first point of contact.
I'm quite happy with the way the current website looks and is structured,
and don't mind working in SVN. I think Markus has done a very nice job
with the PHP, it's very easy to follow and work with (see below). I like
the clear "exactitude" of svn diffs, and prefer to work in my favourite
text editor rather than a web form.
I fully accept the content needs a big cleanup (e.g. the GDP docs -> wiki
merge), and we won't make everyone happy (including me).
Don't get me wrong, I am all for a system which will make it easier for
folks to contribute, easier to edit, more consistent, take less
maintenance, be less of a burden on any one devel, etc..
I wonder what is the real barrier to entry for the current system:
- svn rights (can be fine-grained, learning curve = 1 hr)
- knowing html (not much worse than wiki markup, more google hits,
drupal uses basic html markup as well)
- lack of interest by those with the answers
- lack of users knowing the answer definitively
I suspect it is primarily related to the last idea, and as it happens
Markus happens to know most of the answers better than anyone else. I
worry that changing to drupal can't solve that part of the problem.
Before we start any migration we need to figure out what the homepage is
for and goes where:
- Website content
- Mediawiki content
- Trac wiki content
The main website may reduce down to:
- mainpage with TOC and non-dominating news
- about (drupal page)
- download (drupal page)
- help (-> mediawiki)
- community (-> wiki)
- bugs (-> trac)
- development (-> trac wiki)
the last four there can and should happen now, not need to wait, it just
has to be systematically done.
Some minimum requirements of any system with publicly represents us:
- Modifications restricted to approved users (keep out vandals)
[ok, drupal does that]
- Verifiable & reviewable change history (accountability)
[I am logged into the test site as an author now and just made a
"book page" edit, but I don't see how to find a page's change history.]
Style:
eeek, get rid of the puke-green rectangle at the top, it gives me a
headache.
For comparison, IMHO the qgis homepage is community-friendly but way too
cluttered* and scattered**, while the gdal page has a nice logical
structure but is too aesthetically sparse for an end-user project like
GRASS.
[*] a page needs lots of whitespace! no need to shove everything on one
page, addition pages are free.
[**] a solid hierarchical structure is the key to usable site navigation.
A pile of random node pages with a search tool is a poor substitute in a
front page / portal site.
We already have trac and a wiki sites with User: and Pass: prompts, do we
need a third in the same meme? I don't much like that on a project
homepage, to a new user it might seem elitist. (better: quietly put a
login link at the bottom for editor access) On the other hand, maybe that
gives new recruits more of a sense of belonging to the community? shrug.
(did I mention I hate clutter?)
/me stops complaining and wanders off to learn more about how to use
drupal
Hamish
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ