Opened 16 years ago
Closed 15 years ago
#369 closed task (fixed)
SVN repository for UbuntuGIS
Reported by: | aboudreault | Owned by: | hobu |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | SysAdmin | Keywords: | |
Cc: | dmorissette |
Description
I would like to know if it would be possible to get a SVN repository for the UbuntuGIS project. The goal of UbuntuGIS is to package and maintain the GIS softwares for Ubuntu. The SVN repository is for all the "debian" directories, which is used to build a deb package.
The repository should look like the debianGIS one: http://svn.debian.org/wsvn/pkg-grass/scripts/?rev=0&sc=0
Change History (9)
comment:1 by , 16 years ago
Component: | General → SAC |
---|---|
Owner: | changed from | to
comment:2 by , 16 years ago
Alan,
Following the provided link, I'm left with the impression that complete copies of the packaged software is captured under source control - is that right? I'm concerned this will be quite a large SVN instance, and may stress osgeo1 (svn.osgeo.org) in various painful ways.
comment:3 by , 16 years ago
We'll only keep the "debian" directories. There will be no deb packages at all, and no source packages of the software neither. ie: http://svn.debian.org/wsvn/pkg-grass/packages/gdal/trunk/debian/#_packages_gdal_trunk_debian_
You can see that there is only a few files keep for the gdal package in trunk, and we tag that directory for each gdal version.
comment:4 by , 16 years ago
It would be great for the credibility/visibility of the UbuntuGIS project to have SVN and Trac instances at OSGeo: since the project aims to provide Ubuntu packages for all OSGeo projects, being hosted at OSGeo is where it belongs. That could also help in attracting contributors.
However, if the project is not mature enough yet and that's a problem then we can always host SVN and Trac at maptools.org, but in this case I think both OSGeo and UbuntuGIS are losing in shared credibility/visibility.
comment:5 by , 16 years ago
The 'real' (or however you would name it) DebianGis project managed to gain noticeable credibility without having their stuff hosted at OSGeo, so why would UbuntuGIS have to ? I'm uncertain if OSGeo's resources are well suited to not only host the underlying GIS projects but every individual distribution's branches as well.
The conclusion why to host the stuff at OSGeo feels a bit 'inconsistent' to me.
comment:7 by , 16 years ago
Thanks for volunteering Howard. I'll take care of the motion.
I'll also try to address Martin's concerns since I don't want anyone to think we're abusing OSGeo's resources. We could have done this on maptools.org anyway so you're right that we don't need OSGeo to host or to give credibility to UbuntuGIS... to me it's the contrary, UbuntuGIS is going to provide a service to the OSGeo community that I and others believe is important: up to date binary distributions... Frank already wrote about this goal of OSGeo in the wiki at http://wiki.osgeo.org/wiki/OSGeo_Binary_Distribution
Alan tried to explain the objectives of UbuntuGIS and address the difference with the "real" DebianGIS and why we need both here: http://lists.osgeo.org/pipermail/ubuntu/2009-May/000016.html
Finally, on the size of the stuff hosted in SVN, Alan already explained in comment:3 that only the package definition files are stored in SVN, not the full source tree. For instance, the total size of the GDAL dir for a given Ubuntu distribution is about 150k.
comment:8 by , 15 years ago
Owner: | changed from | to
---|
The motion has passed on the SAC list, so you can go ahead and setup the SVN and Trac when you have a chance Howard. Perhaps include myself and Alan (dmorissette, aboudreault) in the SVN group and we'll take care of adding more userids as needed. Thanks again for your help with this.
comment:9 by , 15 years ago
Cc: | added |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Closing. The motion has passed and the SVN/Trac are in place at http://svn.osgeo.org/ubuntugis/ and http://trac.osgeo.org/ubuntugis/. Thanks Howard!
Reassigning to the Systems committee...