dear SAC group,
Victor Olaya, responsible for the Spanish GIS book, made an osgeo account (volaya) and tried to commit to SVN dir [1] I've made a while ago.
I have no problems to commit with my user name.
Would it be possible to create a group for Spanish book and manage it from the ldap_group script [2]?
thanks
Lorenzo
Lorenzo Becchi wrote:
dear SAC group,
Victor Olaya, responsible for the Spanish GIS book, made an osgeo account (volaya) and tried to commit to SVN dir [1] I've made a while ago.
I have no problems to commit with my user name.Would it be possible to create a group for Spanish book and manage it from the ldap_group script [2]?
Lorenzo,
I'd like to suggest that this book just live in the same subversion
repository used for the journal and the web site. Creating and managing
new subversion repositories has some overhead, and I'd like to avoid
doing it if we can just keep a bunch of related osgeo efforts all in one
place.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
On 26-Jun-07, at 10:27 AM, Frank Warmerdam wrote:
Lorenzo Becchi wrote:
dear SAC group,
Victor Olaya, responsible for the Spanish GIS book, made an osgeo account (volaya) and tried to commit to SVN dir [1] I've made a while ago.
I have no problems to commit with my user name.
Would it be possible to create a group for Spanish book and manage it from the ldap_group script [2]?Lorenzo,
I'd like to suggest that this book just live in the same subversion
repository used for the journal and the web site. Creating and managing
new subversion repositories has some overhead, and I'd like to avoid
doing it if we can just keep a bunch of related osgeo efforts all in one
place.
I agree that a single repository is fine, but is there a way to integrate fine-grained group-level access within the repository? I'm not familiar with how group permissions work in SVN, but can we set up separate groups for journal, web site, book subdirectories?
Tyler
Tyler Mitchell (OSGeo) wrote:
On 26-Jun-07, at 10:27 AM, Frank Warmerdam wrote:
Lorenzo Becchi wrote:
dear SAC group,
Victor Olaya, responsible for the Spanish GIS book, made an osgeo account (volaya) and tried to commit to SVN dir [1] I've made a while ago.
I have no problems to commit with my user name.
Would it be possible to create a group for Spanish book and manage it from the ldap_group script [2]?Lorenzo,
I'd like to suggest that this book just live in the same subversion
repository used for the journal and the web site. Creating and managing
new subversion repositories has some overhead, and I'd like to avoid
doing it if we can just keep a bunch of related osgeo efforts all in one
place.I agree that a single repository is fine, but is there a way to integrate fine-grained group-level access within the repository? I'm not familiar with how group permissions work in SVN, but can we set up separate groups for journal, web site, book subdirectories?
Tyler,
I don't think this is trivial, though I'm sure it is possible. Perhaps
Howard will be interested in pursuing this, but I'm not.
I have already learned the lesson that fine grained access control is
a recipe for management complexity, and contributor frustration. So it
really isn't an avenue I care to be involved in.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
Tyler wrote:
-------------------
I agree that a single repository is fine, but is there a way to
integrate fine-grained group-level access within the repository? I'm
not familiar with how group permissions work in SVN, but can we set up
separate groups for journal, web site, book subdirectories?
-------------------
I personally really don't want to see this kind of complex permissions
structure in place. We need to start from a position of trust. If this
system is abused:
- We can re-evaluate our approach
- We always have SVN history to go back to
Jason
We use this scenario all the time in the qgis repository. Its a few lines of acl and a regex.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Gary Sherman
Chair, QGIS Project Steering Committee
Micro Resources: http://mrcc.com
*Geospatial Hosting
*Web Site Hosting
"We work virtually everywhere"
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
-----Original Message-----
From: "Jason Birch" <Jason.Birch@nanaimo.ca>
Date: Tue, 26 Jun 2007 10:56:45
To:"System Administration Committee Discussion/OSGeo" <sac@lists.osgeo.org>
Subject: RE: [SAC] SVN group for Spanish Book
Tyler wrote:
-------------------
I agree that a single repository is fine, but is there a way to
integrate fine-grained group-level access within the repository? I'm
not familiar with how group permissions work in SVN, but can we set up
separate groups for journal, web site, book subdirectories?
-------------------
I personally really don't want to see this kind of complex permissions
structure in place. We need to start from a position of trust. If this
system is abused:
- We can re-evaluate our approach
- We always have SVN history to go back to
Jason
_______________________________________________
Sac mailing list
Sac@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/sac
On 26-Jun-07, at 10:56 AM, Jason Birch wrote:
I personally really don't want to see this kind of complex permissions
structure in place. We need to start from a position of trust. If this
system is abused:- We can re-evaluate our approach
- We always have SVN history to go back to
Two issues are being mixed up here...
1 - Administrative overhead - it seems that from a systems admin perspective it is prohibitive to implement or maintain. If this is the case, then SAC can say no, or we can find the methods or tools we need to get it done. What we have right now are some administrators of parts of the osgeo svn that want to partition access control. At present there are only 3 or 4 projects that really need this. I can't see it growing much more than that.
2 - Management need - This isn't about trust, it's about managing a logical organisation between several projects that are largely unrelated. It's more about empowering management groups of these projects to care for their areas and not be responsible for others.
In my mind, leaving it is as strange as having mapguide, fdo, geodata, openlayers, journal and gdal all in the same repository. Will future software projects be put into the osgeo repository? Who administers these permissions across all projects? I think you get the point. Having spanish book authors with full access to the web site theme subfolder (and vice-versa) doesn't make sense to me.
At this point there are very few people actually using this repository, but I believe it is better to think ahead than to deal with consequences later.
Gary - do you have any tips you can share? Can we look at how you have been doing this with QGIS - has it been a burden?
The group permissions tool we've had so far has been working great, but as far as I can tell we just need a couple more groups.
I won't belabour the point, but just wanted to lay out my thought process 
Tyler
On Jun 26, 2007, at 10:40 AM, Tyler Mitchell (OSGeo) wrote:
Gary - do you have any tips you can share? Can we look at how you have been doing this with QGIS - has it been a burden?
Here is an example of one entry in our hooks/commit-access-control.cfg file:
[Raster transparency branch]
match = ^(branches)/raster_transparency_branch
users = gsherman timlinux rblazek mhugent telwertowski mcoletti shalasz pbrewer morb_au tylerm g_j_m wonder homann larsl mloskot ersts
access = read-write
This gives permissions to the listed users for anything branches/raster_transparency_branch.
There are other examples in the stock commit-access-control.cfg file...
-gary
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Gary Sherman
Chair, QGIS Project Steering Committee
Micro Resources: http://mrcc.com
*Geospatial Hosting
*Web Site Hosting
"We work virtually everywhere"
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Hi all, thank for opening up this debate.
I'll tell you some informations as a snapshot of the Spanish book situation/activity.
I've finally received by zip the work of Victor Olaya.
I've personally uploaded it to OSGeo SVN:
http://svn.osgeo.org/osgeo/book/es/libro_sig/
as CIA report I've uploaded 314 file:
CIA-31: osgeo: ominiverdi * r369 /book/ (314 files in 36 dirs): Spanish Book. Submitting Volaya's work
the cool part is the quality of his work. if you have time you can have a look to the PDF version:
http://svn.osgeo.org/osgeo/book/es/libro_sig/PDF/
there are actually 6-7 persons that can now start to add their contributions to this book.
we will work ofline until we will not solve the User Group for SVN issue.
We will naturally stick to any decision SAC would choose about this issue.
In my opinion, I still think that book writing will call many editors in the future; or at least we all should hope this.
That's why I would like to create a different group of users for book writing.
I have not a clear idea about allowing editors to be automatically working in book and journal.
As I've nominated Victor I would like to make a brief introduction to him:
He's the one who's leadering the Spanish Book initiative from the beginning and he's the man who created most of Sextante and integrated it to gvSIG the last week. Sextante integration add a lots of raster functions to gvSIG. A massive update.
I had the pleasure to meet in in Girona at the first Spanish FOSS4G meeting. He's been actively involved starting up the Spanish Chapter and the Spanish Book.
ciao
Lorenzo
On 26-Jun-07, at 7:47 PM, Gary Sherman wrote:
On Jun 26, 2007, at 10:40 AM, Tyler Mitchell (OSGeo) wrote:
Gary - do you have any tips you can share? Can we look at how you have been doing this with QGIS - has it been a burden?
Here is an example of one entry in our hooks/commit-access-control.cfg file:
...
Do you find this is burdensome to maintain?
Tyler