Re: [GRASS-PSC] motion: commit access for Eric Patton [was: commit access motion - now or once we move to SVN?]
Maciej Sieczka wrote: > OK. This is an official call for votes on granting Eric > Patton commit access to GRASS source code repository. It would be great to have him aboard, "+1" from me. Hamish Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Fwd: Re: [GRASS-PSC] motion: commit access for Eric Patton [was: commit access motion - now or once we move to SVN?]
This is from Helena- apparently misaddressed to me. --HB === From: "Helena Mitasova" Subject:Re: [GRASS-PSC] motion: commit access for Eric Patton [was: commit access motion - now or once we move to SVN?] Date: Thu, 15 Nov 2007 18:32:08 -0500 To: "Hamish" +1 from me, Helena On Nov 15, 2007, at 4:44 PM, Hamish wrote: > Maciej Sieczka wrote: >> OK. This is an official call for votes on granting Eric >> Patton commit access to GRASS source code repository. > > It would be great to have him aboard, "+1" from me. > > > > Hamish > > > ___ > grass-psc mailing list > grass-psc lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-psc ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Fwd: Re: [GRASS-PSC] motion: commit access for Eric Patton [was: commit access motion - now or once we move to SVN?]
[second try from me, AFAICT the first never made it] This is from Helena- apparently misaddressed to me. --HB === Begin forwarded message: From: "Helena Mitasova" Subject:Re: [GRASS-PSC] motion: commit access for Eric Patton [was: commit access motion - now or once we move to SVN?] Date: Thu, 15 Nov 2007 18:32:08 -0500 To: "Hamish" +1 from me, Helena On Nov 15, 2007, at 4:44 PM, Hamish wrote: > Maciej Sieczka wrote: >> OK. This is an official call for votes on granting Eric >> Patton commit access to GRASS source code repository. > > It would be great to have him aboard, "+1" from me. > > > > Hamish > > > ___ > grass-psc mailing list > grass-psc lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-psc ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Re: motion: commit access for Eric Patton [was: commit access motion - now or once we move to SVN?]
> Maciej Sieczka wrote: > > The only document regarding voting proceduure I know of is > > RFC 3 [2], and it does not mention vote closure date issue. > > Should it? Markus: > Yes. For now as good practice, in future coded in the RFC. > > > BTW - the RFC 3 is not accepted yet. > > once the migration is done (next week?), we can work on things > like this. As earlier noted, I feel RFC3 still needs a rewrite before it is ready for a vote. And yes, I still need to dig out my attempt at doing that. (there's a good chance that was lost in my HD crash last month and ideas need to be recompiled from the mailing list threads) Hamish Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how. http://overview.mail.yahoo.com/ ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Re: OSGeo Annual Report - GRASS Activities
Markus Neteler wrote: > please take a look at > http://wiki.osgeo.org/index.php/GRASS_GIS_Report_2007 perhaps mention the status of grass's osgeo "incubation" process? what is it? Hamish Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Motion: Grant SVN write access for Ivan Shmakov
Markus Neteler wrote: > I would like to propose to grant SVN write access to Ivan Shmakov > who got very active to suggest improvements for the core libraries of > GRASS. You will have seen his contributions in the grass-dev mailing > list. Hi, Ivan seems like a decent fellow and I welcome his expertise. So "+1" from me. I would like to informally propose that in future we wait for a contributer to be active on the -dev mailing list for some time (perhaps 6 months?) before raising the question of granting SVN write access. This gives the user a chance to develop a track record, demonstrate an understanding of the codebase*, and get a feel for how our little development team works. In addition it gives PSC voters a chance to be confident in our votes rather than rubber stamping our approval on a mostly unknown entity. [*] I think we are in pretty good shape, but merely due to the age of the codebase we seem to have a large number of undocumented "this is done for historical reasons" spots to watch out for. Whereas the initial reaction of a newcomer is to immediately try and fix something that looks awkward, then get shot down by a long time devel. This bears the potential for bad feelings and lost volunteers. The question is how to mentor + promote an eager and competent helper to full developer status while protecting the codebase from well meaning yet unintentional damage? Hamish Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] GRASS 7 planning
Markus Neteler wrote: > since 6.3.0X is almost settled (remaining bugs can be worked out > later in 6.4.x) Only six more active tickets! Last chance for everyone to have a look. http://trac.osgeo.org/grass/roadmap > I would propose to > > - now release 6.3.0 draft release announcement here: http://trac.osgeo.org/grass/wiki/Release/6.3.0-News (still needs heavy editing; anyone with a osgeo ID can help) > - branch off 6.4.x (where wxgrass and some other development may > continue) > - rename trunk to GRASS 7.0.svn, do heavy renovation there > > We have so many outstanding massive changes to do that we should > not wait any longer. > > See also > http://trac.osgeo.org/grass/wiki/Grass7Planning > > Objections? /me: go go go. Hamish Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
[GRASS-PSC] Re: [GRASS-dev] r30246 - grass/trunk/lib/gis
> Date: Fri, 22 Feb 2008 04:21:54 -0800 (PST) > From: Hamish > Subject: Re: [GRASS-dev] r30246 - grass/trunk/lib/gis > To: grass-dev at lists.osgeo.org > > Glynn Clements wrote: > > If you don't understand copyright, consult a lawyer. > > Ok, > > just added on the wiki site: > http://grass.gdf-hannover.de/wiki/Development#GRASS_License > > a link to the Software Freedom Law Center's "Legal Issues Primer for > Open Source and Free Software Projects": > http://www.softwarefreedom.org/resources/2008/foss-primer.html > > > as for the thread, I think it's important to focus on the purpose of > the --script module switch, ie to create a wrapper script template. > For that I think it's a good idea to set useful defaults and > examples. It is important that any donated addon > script contains sufficient copyright & license info, as without > that it is essentially useless. So anything we can do to encourage > the author to consider that is a good thing. It is easier for the > lay-devel to see & remove the GPL boiler plate than to think to add > it. Make it easy to do the right thing. > > > as for "the grass devel team" not being a legal entity- I wonder how > closely that phrase can be related to the OSGeo Foundation. Now that > GRASS is an official OSGeo project, presumably the GRASS PSC and/or > the "GRASS GIS Project" has some amount of formal identity. > > And so "(c) the grass devel team" is a descriptive term which, in > context, is short for "(c) the authors of the GRASS GIS Project, as > represented by the GRASS PSC - a subsidiary of the OSGeo Foundation". > The devels are the authors, and it is natural for the authors of a > work to hold the copyright. As the exact meaning of "authors" is > controlled via our RFC2 SVN commit access policies it isn't as > vague as it might appear on first reading. > > > Hamish > > ___ > grass-dev mailing list > [EMAIL PROTECTED] > http://lists.osgeo.org/mailman/listinfo/grass-dev > Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] grass manual translations
Helena Mitasova wrote: > I got an interesting question - see below. > I asked for more details, but when looking at the man pages > there is only Copyright by GRASS Development Team and > no license and no email who to contact in case somebody > wants to use/distribute/reprint etc. the material. The contact is the "GRASS Development Team". The email contact (if there should be one) should be the -psc or -dev lists, but that is easy to discover. The GRASS module document license is the same as the rest of the software distribution, ie the GPL >=v2. > In fact the Intro pages don't have anything. fixed in svn. > Should we include Creative commons license for the manual > at each page with a link to explanation of what CC means? > Or should we protect the manual by a stricter license or copyright > and provide contact to person who will handle the request? > ( first option looks much better to me) IMHO we should provide the entire grass .tar.gz release under a single license. To do other wise would be a mess, especially since the header sections of the module help pages are directly derived from the GPL'd module source code. (GPL2 sec. 2b) Other parts of the project can use different licenses as appropriate, although for flexibility it would be nice to promote common licenses and ask that copyright be given to the project so that content can be used and relicensed around the project's deliverable outputs as needed. The MediaWiki content has been licensed under the GNU Free Documentation License 1.2. The website screenshots have been licensed under the CC-Attribution ShareAlike 2.5 license. The website generally asserts copyright without specifying a license. If copyright is asserted, but not license terms, it just means you have to ask the project before you copy/modify/redistribute the content or assume terms. That's not a bug. [the fwd'd message] > A few months ago i started making a translation of the Grass manual > and after a lot of changes I prepared a greek manual according to my > student needs. It is unclear to me which "Grass manual" is being refered to. The module help pages? intro pages? N&M's GRASS book? Programmer's manual? Regardless, this clearly sounds like a derived work. > In the Greek manual I have allready referenced the grass manual but I > didnt print it because i still dont have the right to translate the > english manual. > Is there any way for me to print my book which is about Grass and > Qgis??? > I mean could I somehow take a letter from the Grass team in which > they will say that I have the right to print my book using as > basework their work in the english manual?? If it is the module help pages, then derived works are covered under the terms of the GPL >=v2. Hamish Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] grass manual translations
Helena Mitasova wrote: > If I don't hear more comments I will email Nicolas that he does not > need a letter from us, he can go ahead and print his material and > read the GPL2 for more details on how to handle it. So he (or his publisher) doesn't get a rude shock later, make sure he understands the part in the GPL which states that the derived work must give its recipients the same rights as he was given, ie it must be covered by the GPL as well. If he doesn't want the non-GRASS derived parts of his book to be covered by the GPL he must print it as two separate booklets. A letter could be as simple as "You may redistribute the GRASS manuals, and works derived from them, under the terms of the GPL version 2 or newer." Hamish Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Request for commit access to SVN
> There we go, then, welcome to the suffering! +1 from Scott Mitchell h, we don't talk about that. :) +1 for Maris/SVN from me. Hamish You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] SVN Write Access Request
Marco: > with the present mail I'm asking you the SVN write > access in order to mantain the tasks related to the > experimental WinGRASS project. RFC2? Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] SVN Write Access Request
Marco: > I read and accepted the terms of the RFC 2 document > published here: > http://download.osgeo.org/grass/grass6_progman/rfc/rfc2_psc.html ok, then "+1" from me. > > simple curiosity: where do you expect your initial > WinGRASS commits to be? In a dir in the source code like > macosx/ and debian/, or in the grass-web > grass63/binary/mswin/ area, or ..? > > 1) grass-web/trunk/grass63/binary/mswindows/native > > to maintain the published release documentation > > 2) branches/develbranch_6/win32 > > the folder where i put all the scripts and files needed to > prepare the release installer (as an exe file). why refer to 32bit in the dirname? > Just few questions: all the files (dos batch scripts, the > NSIS script, icons and documents) are made by me, with the > exception of: > > 2.1) the bmp files (4) for the installer GUI, taken from > the standard library of NSIS (that is OS, obviously) it may be "open source", but that means 1001 different things, many of which we can not touch. what is the license exactly? are those 4 files distributed under terms compatible with the GPL? If not GPL is it one of the OSI usual-suspects approved set? > 2.2) a small part of the installer, a function to let > replace parts of strings; I just copied and pasted it, > maintaining the header, where is clear the line > ";Written by [author]" what license terms did the author provide it with? you can not just cut and paste things from the internet or "cook books", even with attribution. is it a simple one- liner that is hard to write any other way, or is it an original work? without a clear license you can not distribute the code. if in doubt try and contact the author of that code, they may give you full permission to use, modify, and redistribute it. > does it match the RFC 2? Without more details I don't know. to be clear, it is explicitly the committer's responsibility to ensure that everything they put in the repo is legally kosher. (this is perhaps a matter that should be cc'd to the -dev list for wider audience + comment) good reading: http://www.softwarefreedom.org/resources/2008/foss-primer.html Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: R: [GRASS-PSC] SVN Write Access Request
Hamish: > > RFC2? Marco: > read :-) "The request has to be send to the GRASS-PSC mailing list, stating that RFC2 was read and accepted." http://trac.osgeo.org/grass/wiki/HowToContribute "read and ..." ? simple curiosity: where do you expect your initial WinGRASS commits to be? In a dir in the source code like macosx/ and debian/, or in the grass-web grass63/binary/mswin/ area, or ..? Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: R: [GRASS-PSC] SVN Write Access Request
Marco: > >> 2) branches/develbranch_6/win32 > >> > >> the folder where i put all the scripts and files > >> needed to prepare the release installer (as an exe file). > > >why refer to 32bit in the dirname? > > Good question; actually I named it as I'm used in my > windows projects, because I build on a 32 system; > BTW, I don't know if MSYS/MinGW + NSIS are available > even for Win64... > For me it's the same... We can call it just > "Windows" too generic- we use X-windows and rastr regions are call "windows" internally. why not just use the same as on the website: mswindows? > >> Just few questions: all the files (dos batch scripts, the > >> NSIS script, icons and documents) are made by me, with the > >> exception of: > >> > >> 2.1) the bmp files (4) for the installer GUI, > >> taken from the standard > >> library of NSIS (that is OS, obviously) > > > it may be "open source", but that means 1001 different things, many > > of which we can not touch. what is the license exactly? are > > those 4 files distributed under terms compatible with the GPL? > > If not GPL is it one of the OSI usual-suspects approved set? > > From the NSIS official web site: > > Applicable licenses > -- > > * All NSIS source code, plug-ins, documentation, examples, > header files and > graphics, with the exception of the compression modules and > where otherwise > noted, are licensed under the zlib/libpng license. > * The zlib compression module for NSIS is licensed under > the zlib/libpng > license. > * The bzip2 compression module for NSIS is licensed under > the bzip2 license. > * The lzma compression module for NSIS is licensed under > the Common Public > License version 1.0. > > zlib/libpng license > -- > > This software is provided 'as-is', without any > express or implied warranty. > In no event will the authors be held liable for any damages > arising from the > use of this software. > > Permission is granted to anyone to use this software for > any purpose, > including commercial applications, and to alter it and > redistribute it > freely, subject to the following restrictions: > > 1. The origin of this software must not be misrepresented; > you must not > claim that you wrote the original software. If you use this > software in a > product, an acknowledgment in the product documentation > would be appreciated > but is not required. > 2. Altered source versions must be plainly marked as such, > and must not be > misrepresented as being the original software. > 3. This notice may not be removed or altered from any > source distribution. > > About the above mentioned terms: > > 1. done: > http://grass.osgeo.org/grass63/binary/mswindows/native/#Install%20GRASS > 2. I didn't altered the source, I'm using only the > binaries > 3. We are not distributing the source code > > >> 2.2) a small part of the installer, a function to let replace > >> parts of strings; I just copied and pasted it, maintaining > >> the header, where is clear the line ";Written by [author]" > > > what license terms did the author provide it with? you can not > > just cut and paste things from the internet or "cook books", > > even with attribution. is it a simple one-liner that is hard > > to write any other way, or is it an original work? > > without a clear license you can not distribute the code. > > I found it on the wiki/examples section of NSIS site > http://nsis.sourceforge.net/StrRep > Since it's an example it lays in the zlib/libpng > license mentioned above. > In particular, as I didn't modified the code, it > respects all the terms in it. as "examples from website" is clearly put in the license statement, it seems like no extra effort is required there. Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] grass-addons access for Martin Pavlovsky (Summer of Code student)
Paul: > > I'd like to propose that Martin Pavlovsky (Google > > summer of code student) be granted write access to the > > grass-addons SVN repository. ... > > (+1 from me on this obviously!) AFAIU for the -addons repo all that is needed is for the contributer to post here saying that they have read, understand, and agree to our RFC2 and supply an OSGeo ID name. Then find a mentor/developer who supports them to enable access. i.e. a vote of the PSC is only needed for write access to the main grass repo, not the addons repo. Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] grass-addons access for Martin Pavlovsky (Summer of Code student)
> Unfortunately we would need to add all GRASS developers > again to group=grass_addons :( Or you just bother those indicated > above to insert people in grass_addons to avoid too much overhead. I don't mind that job, it is pretty quick and has a good result:effort ratio. I can't offer any guarantee of responsiveness for the next couple of months though, probably the opposite. Hamish (first real snow of the year!) ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] grass svn request
Laura Toma wrote: > I wanted to ask for svn write access to the main grass > trunk. +1 from me. [n.b. Laura is the author of r.terraflow] > Also, if access to the main trunk does not imply access to > the addons, I guess officially it does imply that, but technically it is a different box to remember to click. > could I get access to the addons as well. sure, that doesn't have to wait for a vote. what's your osgeo id? Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] SVN write access for Yann
Scott Mitchell wrote: > +1 from me, +1 from me too. Yann had been quite prolific in the GRASS addons and seems to now have a good grasp of the way things work here. > conditional of course on the fact that the agreement re: > reading and agreeing to the RFC conditions has in fact happened / will > be forthcoming (I don't actually see it in the email trail). Note that this has been done already for his access to the -addons SVN, http://trac.osgeo.org/grass/browser/grass-addons/contributors.csv http://lists.osgeo.org/pipermail/grass-psc/2007-December/000421.html but having it explicitly in an email to this list is good practice. Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
[GRASS-PSC] RFC3 voting rules
Paul: > I suppose it just comes down to re-working RFC3 into something that suits > us better. When I get time, I'll do some research to see what other > projects do about this sort of issue. AFAIK RFC3 is purely draft and has no bearing on present votes. I think RFC3 needs a significant rewrite. I had a start on that but some months passed with it fermenting in my drafts folder, and then a hard drive crash took that out and I lost the thought/motivation to redo it. I would consider the current situation as "seeing what naturally works for us" and so a good data collection step for a future RFC3 doc. Once we have it passed it is unlikely that we'll revisit it much. My observations are that support from a majority of PSC'ers is needed to pass something, usually the vote is open for about a week. One or more PSC'ers tend to miss any given vote without ill effect, so 100% consensus to do anything is not required. This issue of what it takes to veto or send something back for further consideration is still unknown. I guess we aren't such a controversially minded bunch. But you have to start somewhere: Consider this email me requesting rfc3 be sent back for further consideration. I'm not happy with it in the current form. Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
[GRASS-PSC] is this license GPL2 compatible?
[sorry for the cross-posting, I'm casting the idea net wide] is this license GPL2 compatible? is this license DFSG compatible? * "There is no warranty whatsoever. Use at your own risk. This code may be freely redistributed under the condition that the copyright notices are not removed. You may distribute modified versions of this code UNDER THE CONDITION THAT THIS CODE AND ANY MODIFICATIONS MADE TO IT IN THE SAME FILE REMAIN UNDER COPYRIGHT OF FOOCORP, BOTH SOURCE AND OBJECT CODE ARE MADE FREELY AVAILABLE WITHOUT CHARGE, AND CLEAR NOTICE IS GIVEN OF THE MODIFICATIONS." the bit I am concerned about is the effect of "all your modifications are copyright us". (which is fine with me, but is it fine with the GPL?) I seem to recall seeing something very similar in the past, is this a known standard BSD/MIT/X variant? [*] http://www.debian.org/social_contract#guidelines My attitude is that if it passes those tests, I/we can integrate it into our project without much worry. ? thanks, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] access to the GRASS-Addons-SVN repository
geonomica wrote: > I've write a GRASS add-on named r.mcda, a suite with /r.mcda.electre, > e.mcda.regime, r.mcda.fuzzy/ and r.roughset modules for geographics > multi-criterio aid and geographics knowledge discovery based on rough > set library. I've posted it in GRASS AddOns page > (http://grass.osgeo.org/wiki/GRASS_AddOns#r.mcda) but I'm gratefuly you > if I can access to the GRASS-Addons-SVN repository (I need help for > improve code, interface and traslate document). If you are agree for > access to, *I've read and abide the document Legal aspects of code > contributions* > <http://download.osgeo.org/grass/grass6_progman/rfc/rfc2_psc.html> > (RFC2), my OSGEO userID is: /gima/ and common Name is /gianluca/. Access is now activated. Welcome! Further details, if needed, can be found on the trac-wiki. If submitting a functional suite of modules I'd suggest adding them in their own directory, i.e. grass-addons/raster/mcda/r.mcda.* ... Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] svn addons access
geonomica: > I've still troubles with svn addon access. > I can't comit my directory because with this command: > > "svn commit -m "multi-criteria geographic tool" raster/mcda --username > gianluca --password my_psw_osgeo" > > > I get this message: > "svn: Commit failed (details follow): > svn: MKACTIVITY of '/grass/!svn/act/a2cb3914-df45-48a4-83a0-458bc6519c4b': > 403 Forbidden > (https://svn.osgeo.org)" > My username and password are correct because I verified on > osgeo web page. did you do the initial checkout using http:// instead of https:// ? Can you try again from zero, creating a new directory then svn checkout, etc...? Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] addons-svn access request
mathieu grelier wrote: > I wrote several GRASS add-ons, mainly focused around postGIS data import > and automatic kriging interpolation. > I've just added them to the grass addons page in the wiki. > You can find their description at http://precisiongis.blogspot.com > > I am requesting through this email access to the GRASS-Addons-SVN > repository, if it is possible and you are interested. > I hope I will be able to improve these addons and rewrite them in python > in the future. > I've read and abide the document 'Legal aspects of code contributions' : > <http://download.osgeo.org/grass/grass6_progman/rfc/rfc2_psc.html> > (RFC2) > > my OSGEO userID is: mathieug Added, welcome! Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] SVN write access request
Colin Nielsen wrote: > I am writing to request write access to the SVN so I can make some > updates to the r.cost, r.walk and r.drain modules. > I have read, and accept, the terms of the "Legal aspects of code > contributions (RFC2)", and have created an osgeo_id (cnielsen). > > Thanks and let me know if there is any more information you > require. Hi Colin, it is rather poorly explained in the trac wiki (well, ok, it's wrong): the typical process for new developers is that for some mentorship period they send patches to the devel list or trac system for other old timers to review and commit for them. full svn access generally happens when the mentor has seen enough patches that they trust the person's code, and get bored reviewing all their patches. at that point the mentor nominates the new dev, and the vote happens. this is all rather murky common-law stuff, we've never got around to working on the second draft of RFC3 and preparing it for ratification. None the less, this is a PSC vote, and from my reading of the current RFC3 & expectations, votes are supposed to be called by a member of the PSC (ie your dev mentor) not by the new dev. the dev/trac wiki should say that, but it doesn't. oops I don't doubt that you have a better understanding of the inner workings of r.drain, r.cost, and r.walk than maybe anyone else here, and that you've been quietly working away on them for months, but the fact of the matter is that I've never seen a proper patch, so have nothing to go on to make a judgment right now. sorry. for what it's worth, you don't have to be god's gift to programming; as far as I can tell most of us here are scientists come self-taught programmers when we needed some tool. luckily there are some real programmers around to keep us in line ;) what I'd suggest is that we stall this vote and apologize for any mis- understandings, you post your improvements to the bug/wish trac system, get them reviewed & committed, etc etc. and then sooner or later we will trust your code and get sick of committing things for you and whoever does most of that committing will make some noises to pick up this vote where we left off. todo for the rest of us: fix the wiki text and finish rfc3. cheers & I look forward to trying out your contributions*, Hamish [*] did you see our (ie Ryan's) r.walk penguin nest site selection project? r.drain did a pretty good job of replicating their well worn paths up the beach and into the cliffs. neat confirmation. there was also a nice viewshed coupling aspect to it. ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] SVN write access request
> todo for the rest of us: fix the wiki text and finish rfc3. wording on the access to SVN wiki page now updated: http://trac.osgeo.org/grass/wiki/HowToContribute Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] request for main SVN write access
Markus Metz wrote: > request main SVN write access +1 Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
[GRASS-PSC] grass code making its way into gdal (+relicense)
Hi, It has come to my attention that some GRASS code has been ported to C++ under the Apache license, and from there is now included in GDAL/trunk as BSD licensed. It is a substantial rewrite, but I have looked through the code and there is IMO a clear lineage of the core. i.e. AFAICT it is a derivative product -- but the the main question is if any GPL'd fixes or enhancements are involved, or just reuse of CERL public domain code & algorithms? http://www.perrygeo.net/wordpress/?p=7 http://perrygeo.googlecode.com/svn/trunk/demtools/slope.cpp http://trac.osgeo.org/gdal/browser/trunk/gdal/apps/gdaldem.cpp specifically this code is derived from r.slope.aspect and r.shaded.relief. (I didn't check the color rules code although the rules format is similar.) Again, these modules are historically derived from really old CERL code, so _originally_ public domain. IMHO at minimum that should be credited. (the oldest version I have on hand to check is GRASS 4.3, 1999/GPL) But it definitely includes some of our GPL-era enhancements. (e.g. 'r.shaded.relief scale=') I'm happy for code to be reused for useful purposes, I'm not happy for GPL licensed code to be laundered into BSD with all copyright and attribution removed; which Will then be reused by someone else in a proprietary product at a rate proportional to its usefulness (and this is very useful code). As this was all done in the open, if there is any problem (& I'm not sure there is), I expect it to stem from a simple oversight. If we do feel there is some non-trivial GPL-derived code in there to claim, all authors of that code would need to agree to a relicense of it as BSD. (my guess/hope is that it is all either CERL-based or trivial changes) according to the headers, these authors have contributed to those modules: r.slope.aspect: Michael Shapiro, Marjorie Larson, and Olga Waupotitsch (original CERL contributors), Markus Neteler, Bernhard Reiter, Brad Douglas, Glynn Clements, Hamish Bowman, Jachym Cepicky, Jan-Oliver Wagner, Radim Blazek r.shaded.relief: CERL Markus Neteler, Michael Barton, Gordon Keith, Andreas Lange, David Finlayson, Glynn Clements, (and me) comments? mine: My feeling is that it is the sole responsibility of the coder to research and clearly spell out the code heritage in the code header comments. Even if it is deemed to be based on public domain CERL code, those authorship and copyright statements shall Never be removed. A port between computer languages is no different than a translation between human languages -- and if you accept that, it follows that you can't retranslate Harry Potter into Klingon and not expect to be sued after your version goes on sale. As a general comment I would not agree to any of my non-trivial GPL code to be relicensed as BSD, as the GPL assures the return on investment for my time. Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] grass code making its way into gdal (+relicense)
[http://trac.osgeo.org/gdal/ticket/2975] Frank wrote: > If the GPL/GRASS derived portions cannot be rewritten we will have to > remove them or the whole utility. It is pretty clear that the core methods of gdaldem were directly derived from a GPL work. As luck would have it (I'm guessing, but it's highly likely) that the GPL work in question was itself derived from a public domain work, so there is a good chance that we have a fairly clean way out of this. It is my hope that we will be able to find old CERL/GRASS public domain versions to go back to which contain the bulk of the code so we can confirm that and gdaldem doesn't have to be removed or relicensed as GPL. But nobody has gone back to do that yet. An audit would have to be done between that original CERL code, the modern GRASS code, and gdaldem to be sure that no GPL additions are included. As gdaldem (seems) based on GPL grass that means following each CVS/SVN log 1999-2006, which luckily we still have. Confirming that some bits of it were in the public domain does not confirm that other bits of it are not. If anything was found we'd have to sort that out, either by permission or by rewrite. We'd have to supervise that to some extent, but the onus is really on the new coder to prove that they have committed clean code. > I appreciate your bringing this to our attention (indirectly). my intention had been to discuss it amongst ourselves here and more fully do our homework on it so to present something robust to gdal from the offset, rather to immediately yell "gpl violation!" and run in circles waving arms about, which helps nobody. so the gdal bug is filed a little sooner than I planned, but I guess that's not a bad thing either as I would not like to see GDAL 1.7.0 published in the mean time without this being known. I'd still like a discussion to take place among the GRASS devels as I think it's healthy and reassuring to put forward a consensus view. best, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] grass code making its way into gdal (+relicense)
Dylan: > I do not think that this act was intentional. Massimiliano: > I also don't think this was intentionally done Nor, I. He was quite up front about the code heritage on his site; I consider this to be simply an oversight in the source code header comments which then caused another problem downstream. He undertook it partly as a learning experience, and I guess that's what it turns out to be. :) We all learn our lessons from time to time. I fully understand that assuming a port from libgrass to libgdal and C to C++ is not a verbatim copy so is ok seems reasonable at first, but if you read the text of the GPL2 license it is rather clear: "2b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License." I do not wish to assign any blame or give anyone a hard time, just to fix the technical problem so this nice tool can be cleanly released to the public. Hamish: > > It is pretty clear that the core methods of gdaldem were directly > > derived from a GPL work. Markus: > Are you really sure, Hamish? Yes, I am, although perhaps I should have thrown in the word "unintentionally". -- but that is irrelevant to the truth of the statement. gdaldem is based on Matt's Apache licensed version. Matt's code was derived from ~ GRASS 5.0.2-6.2.1 (GPL) and (for whatever reason) ended up relicensed without attribution under the Apache license. That is what my above statement refers to. That GRASS 5,6's version itself was based on a public domain work, and that we are able + willing to mention and now help verify that fact, is purely a matter of coincidence and good luck. update: Even, Helena, and myself have now looked through the old CERL version dug up by Markus. Even found one one item in r.slope.aspect but as far as I can tell that's in the CERL version already -- awaiting clarification. As far as r.shaded.relief goes there is a small contribution from Michael and one from Gordon Keith that are probably trivial but as to what constitutes a trivial change isn't for me to say, so I've asked them anyway. Other than that everything seems to be in the clear, thankfully. We've asked GDAL to cite GRASS 4.1 (CERL) in the header comments, and I think it would be nice to cite the Horn 1981 paper as well which contains the original slope algorithm. Once that is done I'll forward the patch to Matt and request he does the same and we can all move on. regards, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Re: Donations for the GRASS project
Markus:
> >>> http://grass.osgeo.org/donation.php
Martin:
> > it would be cool to have possibility to donate money
> > for given task, see [1] for inspiration.
from the donation.php page:
"Also bug fixing may be financed - community polls will identify outstanding
problems which cannot be fixed on a voluntary basis."
I think the individual 'bug bounty' approach qgis is using is a
really good one because it is very directed. We provide people
who need a certain feature fixed a way to make it happen. And it
removes any chance of vocal minorities dominating the task
selection process if the person giving the money decides.
The other side is the poison to a community trust that an overly
vague setup can cause. Debian has still not fully recovered from
their venture into this game last year. ("why should they get
paid and not me?" mentalities killed people's motivation to
volunteer their time...)
The other danger to community spirit is someone directly funding
a core devel to add some new feature, and then their being bad
feelings if that feature is only added to the core because of
money instead of quality/popular need. (as opposed to
bug-bounties) I guess the linux kernel devels deal with this
all the time. anyone follow the LKML enough to know how they
deal with it?
so +1 for directed bug-bounties, but I think anything else needs
us to take much care and pass & publish clear RFCs.
Hamish
___
grass-psc mailing list
grass-psc@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] [GSoC] SVN access to Addons repository
Anne Ghisla wrote: > For my Google Summer of code project [0], mentored by Martin Landa, I > request write access to SVN addons repository. > [0] http://grass.osgeo.org/wiki/V.autokrige_GSoC_2009 Hi Anne, As there is already the shell script version in addons SVN named v.autokrige[1], and as this is for SoC, we should take special care to avoid confusion and so use a different directory name to put yours in. Typically for a next generation rewrite we'd name the dir like vector/v.autokrige2/. http://trac.osgeo.org/grass/browser/grass-addons/vector/ there is already one called v.surf.krige[2] as well, so that name is taken too :) [1] http://grass.osgeo.org/wiki/GRASS_AddOns#v.autokrige http://precisiongis.blogspot.com/2008/11/vautokrige.html [2] http://grass.osgeo.org/wiki/GRASS_AddOns#v.surf.krige ?link? http://www.gfosservices.it/?q=node/61 regards, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] [GSoC] SVN access to Addons repository
> Anne Ghisla wrote: > > For my Google Summer of code project [0], mentored by > > Martin Landa, I > > > [0] http://grass.osgeo.org/wiki/V.autokrige_GSoC_2009 Hamish wrote: > ... also ... > [1] http://grass.osgeo.org/wiki/GRASS_AddOns#v.autokrige > http://precisiongis.blogspot.com/2008/11/vautokrige.html > > [2] http://grass.osgeo.org/wiki/GRASS_AddOns#v.surf.krige > ?link? http://www.gfosservices.it/?q=node/61 almost forgot: [3] http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_5_5/src/sites/s.surf.krig https://trac.osgeo.org/grass/browser/grass/branches/releasebranch_5_5/html/html/s.surf.krig.html Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Re: Donations for the GRASS project
> QGIS has established a nice sponsorship program: > http://qgis.org/en/sponsorship.html one thing that is unclear to me is what different levels of sponsorship buys you? - a logo (advertising) on the main homepage? - preferential access to developers & and expectation that their bugs get fixed first? - nothing in return beyond a better product and a warm feeling? i.e. what's the business case to get it past the accounting dept? what would it take encourage a sponsor to renew the following year? are we willing to do that? keen to watch how this works out for qgis, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Submitting module to add-ons repository
John wrote: > I would like to submit a module (see recent grass-dev post) > to the addons repository. > > I have read and will abide by the document RFC2 - Legal > aspects of code contributions. I have an osgeo_id: stevensj activated, have fun! don't forget to update the wiki addons list too. Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Request for write access to AddOns svn repository
Carlos "Guâno" Grohmann wrote: > Dear members pf the GRASS-PSC, I > would like to have write access to > the GRASS-AddOns SVN repository. > > I have read and I abide by the document Legal aspects of > code contributions (RFC2). > > OSGEO ID: guano Sure thing Carlos. Done. regards, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Re: SVN write access request
Colin Nielsen wrote: > I am writing to request write access to the Main SVN so I > can continue to maintain the standalone native WinGrass > installer, the scripts related to WinGrass packaging, and the > WinGrass release notes on the website (rather than sending > my patches to Markus). "+1" from me. (I half thought he already had it :) Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Re: SVN write access request
Markus wrote: > Suggestion 1: if you have addresses you want to post from > and which you don't want to subscribe, I can add them in > Mailman to not get them dropped. But this offer is valid > only for this grass-psc list. idea: in the mailman subscription page (where you turn off the monthly reminder) there is an option to stop delivering mail, but it isn't unsubscribe. If you stay subscribed but check the "on vacation" button, perhaps you can still send mail to the list anyway. Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] GRASS-addons svn write access request
Damiano wrote: > I would like to have write-right access to the > GRASS-addons svn repository. > I have read the GRASS RFC2 and I accept it. > > Thanks in advance > > -- > > --- > Damiano G. Preatoni, PhD > > Unità di Analisi e Gestione delle Risorse Ambientali > Dipartimento Ambiente-Salute-Sicurezza > Università degli Studi dell'Insubria > Via J.H. Dunant, 3 - 21100 Varese (ITALY) sure thing. what's your osgeo id? what does your new module do? regards, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] GRASS-addons svn write access request
> > what does your new module do? Damiano wrote: > The v.transect.KIA module calculates kilometric abundance > indexes (KIA), a common indirect presence index used in > wildlife monitoring. > Basically user needs to supply a point vector (object > locations) and a line vector (survey transects paths) > to have an abundance index calculated as an attribute in > paths attributes table. Interesting. Can you include distance from transect line, number of individuals as part of the point data, etc., or is it assumed that the point data has already had it's x,y corrected for that sort of thing? (or for this does it not matter) .. I'd expect that your chance of spotting would decay exponentially as the critters moved further away from the transect line so some sort of correction could be determined/applied.. be sure to add it in the wiki addons page and also the wiki Research applications->Wildlife Zoology page. fyi, the addons are a bit more free-form, but the tradition for official modules is to use only lower case letters in module names and parameter names. > My osgeo ID is prea. now activated. cheers, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Re: v.krige moved to trunk and devbr6 - SVN access request
Anne: > > I'd like to ask for extension of write access to main SVN repository, > > as v.krige is now part of trunk and develbranch_6. The module, > > developed during Summer of Code 2009, [...] > > I've agreed with Martin that until the decision of PSC I'll continue > > development by sending him patches. Martin: > I am not member of PSC anyway I support Anne in her request. It's fine with me, Anne is a most welcome contributer, brings much needed QGIS plugin expertise, & is a source of positive energy. Fair warning that due to the holidays & all it may take a week or two to hear back from everyone & before we can act on this. ho ho ho & bbqs on the beach, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Re: v.krige moved to trunk and devbr6 - SVN access request
> Fair warning that due to the holidays & all it may take a week or > two to hear back from everyone & before we can act on this. well, it's been a week. Still haven't heard from a number of folks so I suggest to keep this open until Monday. regards, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Re: v.krige moved to trunk and devbr6 - SVN access request
Anne wrote: > I'd like to ask for extension of write access to main SVN repository Ok, with positive responses from Dylan, Helena, Maciek, Markus, Massimiliano, Michael, Paul, Scott, and myself we can declare this one well & truly passed. Welcome aboard Anne! Your osgeo ID has been added to grass's svn group, so you are ready to go. regards, Hamish --- On Sat, 1/2/10, Massimiliano Cannata wrote: > From: Massimiliano Cannata > Subject: Re: [GRASS-PSC] Re: v.krige moved to trunk and devbr6 - SVN access > request > Date: Saturday, January 2, 2010, 8:16 AM > > +1 > Good work Anne > -- > > Dr. Eng. Massimiliano Cannata > Responsabile Area Geomatica > Istituto Scienze della Terra > Scuola Universitaria Professionale della Svizzera Italiana > Via Trevano, c.p. 72 > CH-6952 Canobbio-Lugano > Tel: +41 (0)58 666 62 14 > Fax +41 (0)58 666 62 09 > > ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Request for SVN-write-access
re. SVN-write-access for Helmut, "+1" from me. Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] svn addons write access request
Margherita Di Leo wrote: > I would like to have write-right access to the GRASS-addons > svn repository. > I wrote a python tool for the morphometric characterization > of the basin, it is called r.basin.py. > I have read the GRASS RFC2 and I accept it. > > Thank you in advance > > -- Eng. Margherita Di Leo > Ph.D. Candidate > Methods and Technologies for Environmental Monitoring > Department of Environmental Engineering and Physics (DIFA) > > University of Basilicata Campus Macchia Romana > 85100 - Potenza Italy > > Office: +39-0971205363 > Fax: +39-0971205160 sure, what's your osgeo ID? Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] svn addons write access request
Margherita Di Leo wrote: > > I would like to have write-right access to the GRASS-addons > > svn repository. > > I wrote a python tool for the morphometric characterization > > of the basin, it is called r.basin.py. > > I have read the GRASS RFC2 and I accept it. ... osgeoid: madi ok, activated. welcome! some svn tips here: https://trac.osgeo.org/grass/wiki/HowToSVN Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Fwd: Apply for write access to the GRASS-Addons-SVN repository
Hi, just in case anyone is needlessly waiting... a reminder that a majority note is not needed for any PSCer to enable access to the addons svn, just to have the rfc2 acceptance posted, the *osgeo id name of the applicant*, and hopefully some established work/mailing list relationship with the applicant. to enable go to the grass trac wiki site main page, then contributing to grass page, then at the bottom there is a link to the addons svn ldap group. Go there, login with your PSC osgeo id, and add the applicants osgeo id name to the list. Also while you are at it add the user to the contributors_extra.csv file in the main grass source tree. Access to the main source tree requires a full vote of course, and it is also nice to hear +1, positive support (or otherwise) comments about people wanting addons. [*] I think we are still waiting for osgeo ids from one of the two recent requests(?) Hamish (currently out of svn range) ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] GRASS-Addons-SVN access request
Jonathan Greenberg wrote: > I would like to apply for SVN access for my GRASS "r.gridengine" set of > scripts -- I've read and accept the RFC2 document. jgrn307 now added to the grass-addons group. enjoy, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Re: Sponsoring the GRASS Community Sprint in Prague
Markus wrote: > ... > >> Please post your suggestions! > > > > unfortunately no response... did you not receive my email? feeding the hungry coders seems like a wonderful use of the funds. regards, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Write access to GRASS-SVN repository
Massimiliano wrote: > Even if do not had the chance to meet her, > I'm fully with you... > +1 same here. +1 Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] access to GRASS-SVN repository
Luca wrote: > Hello, > > my name is Luca Delucchi and I'd like have the write access to > the main GRASS-SVN repository. I ask this because I want > contribute to the GRASS project. I already developed some > modules like r.li.pielou, r.li.renyi, v.pack and v.unpack (in > grass-addons for GRASS 7). I'm also translating to Italian. and don't forget about the r.diversity wrapper script too.. +1, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Re: GRASS Annual report 2010
Michael wrote: > I think that Anna's cartographic composer > was a SOC project, but I'm not sure. nope, that was done as a research project IIRC. 2010 SoC projects were Martin's wxNViz (part II), and Seth's GPU accel of r.sun (shared with gdal). ..added to the wiki page Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Request for write access to the GRASS-Addons-SVN repository
Eric Hardin wrote: > I would like to request write access to the GRASS-Addons-SVN > repository. I have obtained an osgeo_id, which is ejhardi2, > and I have read and accepted the RFC2. Hi Eric, your access is now set up. have fun, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Grass-addons access request
Hi Eric, > Is the Addons SVN a good place to keep a work in progress, while it is > being written during the Google Summer of Code? sure, it's just the place for it. > I could set up an outside repository if need be, but thought having > it in a place where everyone already finds GRASS code could be easier. > Markus Metz is my mentor for the project. having it in our trac system means that when we later merge bits into the main tree all the change history and comments get preserved, plus it's a lot easier. > I have read, and agree to abide by, the PSC2 document. My OSGeo/trac > login is: momsen you're now activated. try making a new directory for yourself in the grass7/imagery/ area. (or raster/ if you & MarkusM think that's a better home of course) https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery I look forward to reading your weekly progress reports. welcome, Hamish (OSGeo GSoC co-admin) ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] PSC management
Hi all, just a short note to ensure my ongoing interest in this conversation and continued interest in serving on the PSC as I haven't said much yet. I'd prepared a longer email earlier, but some quick points to make for now: Markus, were you thinking of RFC4 as a patch or a replacement for RFC1? Anyways it is good to breath new life in every now and then, but we must also be deliberate and follow the RFCs already passed. Also I think it's incredibly valuable to keep still interested but no longer actively contributing devs around as they provide a strong sense of perspective sometimes not able to be seen by those actively "amongst the trees". It helps stop a lot of reinventing the wheel as well. :-) So I hope they stick around, the guidance and experience of elders is near impossible to replace. As for non-communicative (in years) formerly active contributers, what else can we do but wish them the best and nominate some new blood to replace them? Any move to do that though has to come through a formal proposal and vote by the PSC though. As others have mentioned, many of us travel into the field for many weeks at a time, far from internet access, and so short-term automatic timeouts are problematic. We should revisit the proposed RFC3 to tighten up voting procedures if there is concern of important decisions languishing. A week is perhaps too short a period, and a month too long to wait, so I'm happy with Michael's proposal of two weeks before possible voting closes. For the role of the PSC, I see it as a bit of a mark of success that it has not been called up very much! It means that our dev team is self- regulating well and taking on the leadership role -- & this is a Very Good Thing. I have deep reservations about instituting a system where an elite cabal is seen to (even if it is just a mis-perception) be running the show, and new devs have little chance to contribute. And so I have been very happy to see GRASS lead by the developers not by PSC dictates, as we explicitly specified in RFC1: "For controversial or complicated changes consensus must be obtained on the developers' mailing list as far as reasonably practicable. It is recognised that the ultimate arbitration on technical issues should always lie with consensus on the developers' mailing list. Specifically, it is not the role of the PSC to impose technical solutions. Its role is in general limited to enforcing the quality control mechanisms outlined above." (i.e. maintaining and enforcing submitting guidelines and licensing rules, and granting write access) Open for minor tweaks, sure, but I don't think that RFC1 is excessively broken and that major edits to it are needed to revitalize the PSC. more thoughts later, best, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] GRASS-SVN access
Markus wrote: > I motion to grant write access already now since Vaclav has > a notable record of contributions in the core GRASS system. While I can't admit to knowing Vaclav's work well, based on the recommendations of the other dev's I'd be happy to give my support to it. > If there are no objections in the next days, I'll set up his > account to the main GRASS SVN repository. fwiw, even if non-controversial, granting access requires us to record a formal vote, RFC1: "The following issue(s) must have a vote called before a decision is reached: - Granting source code repository write access for new developers ... " cheers, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] PSC management
> Quoth Markus N.: >> "The PSC members are requested to annually confirm (via email to the >> PSC mailing list) the continuation of their active involvement in the PSC. >> This confirmation is expected by 1 June of each year. In case of lack >> of this confirmation the member will be replaced." Dylan: > That sounds just about right. Here is a slightly altered > version: > > Members are requested to annually confirm (via email to the > PSC mailing list) the continuation of their active > involvement in the PSC. This confirmation is expected annually, > by June 1st. In the absence of such confirmation, nominations > will open for a replacement by XXX (June 15th?). I would simplify as much as possible, add the reasoning, and leave off the the fine-detail procedural stuff: "In order to keep the PSC fresh, members will annually confirm their continued involvement. This should happen by June 1st of each year, afterwhich nominations for their replacement may commence at the discretion of the chair. They are not replaced, and retain voting rights, until such point as their replacement member is formally accepted." Overly-automatic timeouts are poor management IMO, it puts the burden onto the ruleset instead of the humans. Maybe that avoids some personal confrontation, but is a bit of a cop-out of our responsibilities IMO. best, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] GRASS-SVN access
Markus: > > > If there are no objections in the next days, I'll set up his > > > account to the main GRASS SVN repository. Hamish: > > fwiw, even if non-controversial, granting access requires us to > > record a formal vote, Markus: > Sure. > See my other mail for non-active members, so I believe that > a quorum is sufficient. Yes, as we've been doing it for a long time now, a quorum is fine. My small point of order was that it sounded a bit like "if we don't hear from you we'll consider it a tacit 'yes' vote", and that is not much of a vote at all. anyway, moving on.. Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Access to upload python addon/skript
Johannes wrote: > Following the in "How to contribute..." (http://trac.osgeo.org > /grass/wiki/HowToContribute#WriteaccesstotheGRASS-Addons- > SVNrepository), I'd like to sent an official request for > writing access to the GRASS AddOn SVN repository. I read and > agree with the "Legal aspects of code contribution" (RFC 2). > > Furthermore my osgeoid is: jradinger Hi Johannes, your svn access to the grass-addons repository is now active. happy coding. Helena: > I am not sure whether my vote is needed on this for the addons repo, all it takes is for one of us to confirm (perhaps "champion") the request and then act on it. for access to the core repo there must be a formal vote. regards, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] request access to the core svn
Pietro wrote: > > Dear all, > > > > I'm Pietro Zambelli a phD. student of University of Trento, during > > this summer I have done the Google Summer of Code to add "High level > > map interaction" [0] called: "pygrass" [1] into GRASS. > > Mentor of the project was: Sören Gebbert, supported by: Markus Metz, > > Martin Landa and Luca Delucchi. Sören wrote: > Hi, > well i am not a member of the PSC, but as a mentor of the GSoC project > would like to say that Pietro is a great developer. He has my full > support. Hi, sorry for the delay in reply (I'm away and just about to jump on a train); Pietro has my support too and is most welcome! Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Vice PSC chair selection
Hi all, I'm still mostly-off-the-grid here for a while yet, but popping my head in for a moment, I would support Helena for the role, since along with Markus she has the longest view and track record in the project and (deserved) wide respect both in and out of our community. all the best(!), Hamish ps- as earlier, if I'm being unresponsive and you need to reach me, try my work/personal email address, as I'm checking in on that one more frequently than this list one. ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] request access to the core svn
Martin wrote: > I would like to nominate Stepan Turek to have write access > also to the core SVN (he has already write access to add-ons). I'd be glad for it. Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] winGRASS6/7 and python - funding to improve the actual situation?
Madi wrote: > http://www.pledgebank.com/postgistopology Hi, I'm not really familar with pledge bank, so I won't comment on it directly but since the issue seems to be coming up a lot lately & I thought I'd previously written about this, but can't seem to find it in the archives :), I'll mention it again. It's a bad idea for any of us to personally open a bank account to accept funds. $YOU can be held liable for income taxes and contract issues arising from those funds. It is much better that OSGeo (as our Umbrella org) or an incorporated chapter like gfoss.it (who have done this for us before) handles it on our behalf. This sort of thing is _exactly_ what we joined the OSGeo Foundation for, since they as the legal entity can accept the money on our behalf in an account especially earmarked to our project. If such infrastructure does not currently exist at OSGeo, the best thing we can do IMHO is work towards making it exist. I suggest everyone read this legal primer for FOSS project managers which was put together by the SFLC, who along with the FSF, is our best/only hope of legal council if things go badly wrong: http://www.softwarefreedom.org/resources/2008/foss-primer.html As a general governance thing, please do take the time to print it out and read it :). It explains a lot about the how and why of our Foundation & responsibilities. further light reading of possible interest: http://www.softwarefreedom.org/resources/ There are a number of conference talks by staff lawyers at the software freedom conservancy, the FSF, and the EFF at various FOSS conferences on youtube which are worth checking out too. (See also the dozens of FOSS projects left in limbo by using PayPal to collect funds without filing legal proof of not being a business. It's actually not PayPal's fault [entirely], they are legally obliged to do so) best, Hamish ps- read the primer :) ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] winGRASS6/7 and python - funding to improve the actual situation?
I wrote: > There are a number of conference talks by staff lawyers at > the software freedom conservancy, the FSF, and the EFF at > various FOSS conferences on youtube which are worth > checking > out too. maybe some youtube leads here: http://sfconservancy.org/news/ see also http://wiki.osgeo.org/wiki/501c3_Application:_Questions_from_IRS,_September_2012 (if we do get 501(c)(3) status it will be a /Very Good Thing/ for our funding and sponsorship; any board members reading would do well to chat with Brad Kuhn, he knows about our 501 situation, and more generally that of about a dozen different foss.orgs all in the same situation) Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Write access to Add-Ons
Dmitrij wrote: > I have written a python script (i.jmdist - Jeffries-Matusita > distance) and I would like contribute it in GRASS Add-Ons. Currently > the code of the script hosted at > https://github.com/KolesovDmitry/i.jmdist I have read, understand, and > agree to RFC2 and already have an OSGeo ID name: DmitryKolesov. you are all set, it's enabled. welcome and happy mapping, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Fwd: [GRASS-web] authorization reproduction
MarkusN wrote: > The statement in the letter is: > > "I wish integrate screenshots of results obtained with Grass Gis software." > > If he refers to *his own* screenshots, then there is obviously no need > to obtain any permission. That's what it sounds like to me too. The author is the creator, not the manufacturer of the tool the author used. As long as the screenshots do not include GRASS artwork or e.g. GUI layout, and is only his own "pixels" then he doesn't need our permission. If it does include those things I guess we'd need to see what he is talking about before commenting on it. For the record, term (0.) of the GPLv2 covers this: """ GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you". Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. """ A personal cropped screenshot would not contain the GRASS "program or portion of it", and specifically "the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program)." [See the Bison license for a case where the program output is itself + includes code & so a case which needs a special exemption.] > If he refers to screenshots from the Web site: [...] > ... then I would say that we should apply a CC license for the > screenshots I'm not sure why a book on plant biodiversity would want to provide screenshots of the GRASS GUI or one of our provided screenshot images. (if so, which ones?) So I wouldn't worry too much about GPL vs. CC vs. GNU FDL (wiki) vs. CERL public domain licenses + trademark issues unless we actually have to. It's an endless discussion easily bypassed since most of the original authors are still around to relicense as CC or whatever as needed. > (GPL is for software...). it may not be ideal for artwork, but FWIW the artwork is still protected by it under "... or other work". Of course the copyright holder can dual-license as CC or whatever as they like. Of course in the interest of reproducible results it is always helpful to the reader for the author to state what software (+ version) was used to produce those results, but that's another matter. regards, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] New add-ons modules v.civil
Jesús wrote: > My name is Jesús Fernández-Capel, I have written a add-ons > modules for GRASS GIS 7. > >- v.civil.road.py - Desing roads, channels, ports... [...] > I have read and will abide by the document RFC2 - Legal > aspects of code contributions. I have an osgeo_id: jfc ... > A presentation video can be seen on http://www.youtube.com/watch?v=miLBMfkHVDs >and some examples in http://www.youtube.com/channel/UCBz3UHfW_d7y9rea26oZeHQ > > I would be grateful if those modules could be added to the GRASS-Addons-SVN > repository and therefore get write access to it, for continue with the > developenment. Hi, great, welcome. Your osgeo account is now activated for grass addons svn. I leave the module upload for you so the authorship history is clear. regards, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] applying for svn writing access
Margherita wrote: > in Vienna I've been working on manual pages cleanup on addons for their > moving to trunk. Since the manual pages in trunk > still need a good deal of clean up work, I would like > to apply for SVN writing access. My OSGeo ID is madi. I thought you'd already had it. :) guess not. You have my full support conditional on the statement-for-the-archives agreeing to RFC2 as it pertains to the main repository. regards,Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] applying for svn writing access
>> P.S. Do we really have to wait for a vote by all PSC members >> for granting write access ? AFAIK it is technically undefined, but my understanding/remembering was that the working practice could be the preponderance of PSC members, with no vetos. i.e. for granting core-codebase write access one or two missing votes after a week or so was acceptable, and an absolute +1 vote from all members not strictly required. Keep in mind that some of us head into the field / digs / to sea for many weeks at a time with little or no internet access, so won't always be immediately available to give our rubber stamp. best, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] too many branches => retirement GRASS6.5.svn (=develbranch6)
Hi, I wrote - and thought, sent - a long email about this some days ago, but yahoo or something seems to have eaten it as I don't see it in the list archive. frustrating as I already cleared my local copy! First of all, I believe this discussion belongs on the grass-dev list, not PSC. See RFC1. it's late on Sunday night so I won't restart the whole thing right now, but long story short, and not stated nearly as clearly or well- releasebranch70 should not have been branched until 7.0RC1. Until RC1 it is just wasted effort to keep the two of them as a 1:1 mirror, so what's the point? If anyone wants to talk about unnecessary developer burden, start there. (fwiw it is possible to add a hook to auto-merge in svn server-side) Also, I was rather surprised to see beta1 released at all as AFAIK we had only discussed a "technology preview", ie a tag direct from trunk. Sorry if I missed some email, otherwise I would have raised this earlier. GRASS 6.x is already far along into bugfix maintenance mode. *Please, just leave it to naturally and quietly make its way into history.* Note that for copyright and critical bug reasons relbr64 must be release-ready within a few hours (or days) at all times. There are various debug codes and experiments in devbr6 which are not suitable for backport but none the less useful to have around. Right now with 6.4.4 deeply frozen there are things for some future 6.4.5 in devbr6 which are not critical enough to push in for 6.4.4 this late in the cycle. Maintaining a local patch set for those instead is lossy and frankly, dumb. tbh I cringe every time I see a commit go into both relbr64 and devbr6 at the same time, as it pretty much guarantees the changes were only lightly tested by only one or a few people, which is not how it should be done, especially when we are so close to release. Minor innocent looking last minute changes have resulted in embarrassing major problems multiple times in the past, time and discipline is the only way to deal with it. This will only get more risky as 6 and 7's libraries diverge. Direct backports are personally frustrating as they undermine and short-circuit hours of other careful merging and checking, and generally treating the relbr64 codebase like a delicate and valuable antique vase. In grass-addon/tools/ svn repo you will find a number of svnXXmerge scripts for porting between branches which makes maintaining multiple branches completely trivial. The difficult and risky park is porting between 6 and 7. Between 6.4 and 6.5, and 7.0 and 7.1 is trivial to merge with those scripts given a svn rev number, and little risk. Porting 7.x direct to 6.4 is high risk and a threat to our reputation as uber-stable software, which we have fought very hard to obtain and should protect at all costs. I don't think I can be part of the ruin of that. As mentioned before, I wish to use the bulk of my grass dev time maintaining the grass 6 line. To do that properly I need a staging area, and devbr6 is it. Hosting a clone on github for that is too ridiculous and broken a situation to begin to contemplate. If devbr6 is removed I simply can not do the stable grass 6 maintenance job properly. So without that there is really very little for me to contribute in future. It will not translate to me spending more time working on grass 7, only drive me away from the project. I've thought long and hard about this, and it has caused me much upset and anguish, since I enjoy working on GRASS and do not want to have that taken away. Having the stable release getting only better with time takes discipline, procedure, and yes, work. There is simply no two ways around that. regards, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] #2031: G_legal_filename() cleanup patch for GRASS 6
Mortiz wrote: > How about my proposal from a few weeks ago: Nobody commits to > grass64release, only to grass6dev, and Hamish is the official > maintainer of grass64release and decides what can be backported ? > > This obviously can only work if Hamish has the time, so that 6.4.4 > is not stalled for lack of manpower. Well, I don't like being the sole gatekeeper, both for community and logistical reasons. I am happy and pleased for everyone to backport, as long as we can all be working from the same ideas about where we are in a freeze and what our expectations for it are. Which is primarily (and luckily) a solvable communication problem, and not a structural, technical, or personality one. Having said that, if people find backporting to 6 is too much of a pain, simply leave a ticket open with the next release as the target version and a request to backport and I'll try to take of it for them, in $unknown time. Through bitter experience and brown bags I'm now really strict with myself about committing anything, no matter how innocent looking, to the release branch. What has been driving me nuts is spending all these hours carefully testing and trying to spend a lot of energy on attention to detail, and to then observe other developers just come through with a bulldozer and commit stuff haphazard all over the garden I'd just spent so many hours cleaning up. If all that time ends up in a hole, why bother? I note a revert needed in devbr6 where a number of features-in-testing (64 bit support, stat() checks in libgis, ...) recently got blown away by a mass backwards-sync with relbr64. I can't tell you how demotivating it is to have all those hours of work ignored and removed. Now I have to spend even more hours putting them back by hand, because I doubt any one else would care enough about devbr6 to fix it. This is not fun, and if it is not fun I have to remind myself what I'm doing here. So in the last weeks instead of working or even thinking about that stuff I have concentrated on what I really do enjoy, the creative outlet aspect of coding. Having to be the guy who says "no" all the time really eats into my enjoyment of working in a team, I hate it, it's not a healthy way to be. For sure I play it a bit too conservatively some times, and unadvertised devil's advocate others, and it is noted that this slows down releases, which frustrates and drops motivation in others too. But I'm ok with not having to be right all the time about where the right balance is since I can relax knowing everyone is doing what they consider to be best and positive, and they are really smart and often right about it. And it is frustrating to me too for the releases to take so long, especially since I know some of it is me saying "no" but not having the extra time to do the review and edits to help solve the issues, many of which are of my own making. It's a classic question I don't have an answer to: we can use the time just before a release as a huge community motivator to get all the last minute bugs fixed and all the last minute things people wanted to see in before the next release. But at the same time it's the absolute worst time to make changes which can't have time for testing. So how to harness all that energy without breaking anything by accident? My personal strategy has been to divert non-critical things in to release+1, then soon after release go through the devbr and backport it all. Yes it slips a release which may be many months apart, but I treat it like AGU meetings: you can't be everywhere and do everything at once, so it's ok, do what you can and enjoy it guilt free. Then there are things like the parallelized shell scripts in devbr6 which are wonderful and seem to be working fine, but I've not backported them because I don't know the answer to allow SIGINT to also kill the subprocesses. From the command line with `top` and maybe gkrellm running as a cpu/process monitor it's pretty obvious they are still going. But from my testing of the msys/bash background& a series of jobs + `wait` strategy with the wxGUI on MS Windows (it works!) that if you forget to change the computational region away from 1 meter, as is easy to do there, the r.univar job is going to take hours. So after a while on 1% done you press the "stop" button in the module's gui window but the children keep going in the background. Probably most Windows users wouldn't notice that, only that the machine got slow. So I don't have an answer to that problem and thus the new code remains waiting in devbr6. (I'd note parallelized python scripts in grass7, which by structural necessity of python only support multi-processes not multi-thread, have the same exact problem..) Martin: > from my personal experience I would say that than we will probably > never release any new
Re: [GRASS-PSC] GRASS6.4.4 release [was: Re: [GRASS-dev] GRASS 7 release planning]
Hi, >>> To be honest I think we will have to accept shipping OSGEOLive with >>> 6.4.4... The focus there is a split between being a showcase for new features and super-stable introduction for new users. (power users might see past small transient bugs, but if a new user finds rough edges in the first 5-15 minutes, or before they get past the initial learning curve, the window of opportunity is lost and they'll give up) So far the balance on the disc has been to more favour stable over new. Feature freeze is in just a couple weeks, QGIS plugin would need to be 100% ready and rebuilt, and we'd not have a sample dataset included, would need to have a GRASS_BATCH_FILE import script to set one up from the data already on the disc. fyi I plan to write a script which will be on the disc which will automatically add the appropriate ppa repos and download+install the latest grass7 snapshot and sample data. What version does the foss4g workshop want to use? Note the NC dataset only ships in geotiff+shapefile form so it can be used by all the other projects too, due to disc space limitations the workshop setup will have to download that too. (spearfish is small enough to include for G6 though) There is a link on the live disc desktop to this URL: http://trac.osgeo.org/osgeo/wiki/Live_GIS_Workshop_Install fwiw I will also be writing a G6 script for pre-installing some G6 addon modules. If you have any you want included, place your orders in a osgeo trac ticket please (LiveDVD component), cc 'hamish'. >> Right, as far as I know Markus is off-line since 27/6. So let's start >> with idea to mark RC2 as a final and release it _this_week_! I don't >> know about any blockers. Any opinion? If you know about blockers let >> us know about that ASAP! I have been very busy with work recently, and will be for the next weeks too. In the past I've been able to review all commits to the stable branch, right now I am rather behind in that task. So if it goes out now just be warned that I might be asking for a small-change 6.4.5 release after a month as some sort of 6.4.4.1, since there are always some bugs to find. :-) I would also be a bit slow on the Debian packaging this time and not sure if I could write the release announcement. Work and GSoC has all my time right now, sorry. fwiw the debian rule for packages being accepted into the stable branch is not that they are perfect, only that they are less buggy than the old version. For the spatialite export bug I think that's fair advice to follow: it is not fixed, but no more broken than the previous release. Since v.out.ogr is such a critical module, and the fix requires the module to be improved with a bunch of 2D vs 3D export logic, my vote would be to release 6.4.4 without it, but then try hard soon after release to get it fixed, so maximum pre-release testing time. -- Even though it's pretty crazy/embarrassing that GRASS isn't supporting export to Spatialite currently. My thoughts on r.li are very similar, chances are that the big backport still has some maturing to do, but the earlier version was wrong so perhaps-problems-but-improving beats known-bad. best regards, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] removal of RFC documents from SVN [was: releases schedule]
Martin wrote: >> I agree, if no objection I will remove `rfc` directory from SVN in the >> next days. Martin > > done in all active branches. Hi, Voted-on RFCs are completed published documents and never changed, only superseded/replaced by a new RFC. Only in-draft RFCs should be held in a wiki, and even then edits should be restricted to only the core commit group (which is why we put them in svn). In addition svn has stronger and more robust changelog history and wider backup-copy dissemination, which for legal foundation documents ensures the copy you are looking at is verifiable all over the world as the version that the PSC voted on. If the only copy is on the wiki server you're at the whim of anyone who manages to get write access to the backend DB. Completed RFCs do not belong in a wiki. For bomb-proof full changelog disclosure, draft revisions probably belong in the main SVN too. regards, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] RFC3: New voting rules
Hi all, sorry for my long absence, I've hardly been on email at all for many weeks now. (and enjoying the break from distractions! :) I certainly haven't caught up with all the messages in my inbox, there's a good chance I've missed things. But since people want to get moving, here are my comments on the text of RFC3 as it appears on the trac wiki today. (I guess that makes it version 10 according to trac) In general it just codifies what we're already doing, so no big surprises. Devil is in the details, and we are detail oriented people, so let's get this right. :) Proposals (2): make it clear that the Chair is the to to decide that "no more progress is being made", and close the vote in that case. The last sentence of (2) seems to indicate that, but the wording is a bit muddy. Voting (3): Strike the invalid veto text. I will not support passing RFC3 with that in place. Who is to judge that the reasons given are clear? What if we know something is definitely not the right solution but don't know the correct answer? In yacht racing we used to have a saying: "even if you do not know what the right thing to do is, especially then, never knowingly do the wrong thing." If nothing else it is IMHO quite disrespectful to our fellow PSCers. Voting (4): "... but has no effect" -- "other than to formally indicate the voter's position." (which should hold community weight even if it doesn't count in the calculus of the vote, so should be given a nod in the text) [new] Voting (9): The Chair is responsible for validating the final result. (or some text like that, we don't seem to explicitly say it elsewhere) some other points to consider: - lesser threshold for granting commit rights? (100% PSC members answering not req'd, just a quorum of 51% and no vetos. moreover maybe a shorter timeout of 3-4 days for these. Voting (8) mentions "active voters" but AFAICT elsewhere we don't formally discuss absentees vs. abstainers) - passing rfc by simple majority, or require a higher threshold? - overriding a veto by simple majority, or require a higher threshold? in both the above cases it seems to me the healthiness of the overall project would benefit by forcing us to work very very hard to come to a real consensus rather than expedite a quick decision. FOSS runs on good interpersonal relationships; any chance of unresolved bad feelings being left in the wake of a decision can be quite toxic to the long term heath of the project and avoided at all costs. As I catch up on my email I'll reply to the RFC3 threads on the PSC list inline, probably there are many fine points made by others already that I missed. :) regards, Hamish ps- I still strongly believe that a wiki is not the place to house approved RFCs, it should be in a more formal and secure VCS, such as Subversion. It is not necessary to keep it in the source code tarball, but that does have the benefit of widely disseminating copies. For historical changelog + diff interest, developing the RFC text in the final VCS would be preferable. (culturally, commit log messages tend to be much better in SVN than in a wiki, and the "why" of a change is quite important in this context. also the wiki is open to anyone on the internet who cares to create an account. will our RFCs get spammed or vandalized? even if approved motions are converted to locked pages, that doesn't work for working documents. these aren't some simple help page.) ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] GRASS-Addons-SVN repository write access request
Giuseppe wrote: > But than only lower case was accepted This is a publicly archived mailing list. You should change your login details immediately! thanks & welcome, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] [GRASS-user] [GRASS-dev] GRASS-GIS PSC-2016 Nominations
Nikos wrote: > though the list of candidates should be officially fixed by now, as we > crossed the 12:OO UTC deadline, an extension for 2 more days > is given (till Tuesday, 12:00 UTC). The reason is to give a little more > time for last decisions. Hi PSCers, I feel a bit bad that other responsibilities have taken away the time and enjoyment I used to spend working on GRASS and helping others on the mailing lists. It is still my favorite software to work on and I am frustrated when I have to deal with anything less. I still care deeply for the future of GRASS but at this point I don't think it is fair to other active + new devs for me to tie up a leadership position when I can't keep up with the day to day issues on the -dev list. I could only offer opinions without current context which won't be healthy for the project. If serious issues arrive you are most welcome to call on my emeritus advice of course, privately or otherwise, as deep in the back of my brain is still a pretty good remembrance of much legal history and code context. :o) I do hope to get back at some point, it's just that I can't promise when. So until that time I'm happy to drop back to an occasional developer and bug fixer. best, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] GRASS Development team as a legal entity
Markus wrote: >> in the incubator list the question came up if GRASS Development team >> is legal entity to which the copyright can be assigned. While not a legal entity per se (that's a big reason why we joined OSGeo) it's a clear moral entity with RFC rules & regs, history, etc. if a community dispute ever arose. I always added the ", and the GRASS Development Team" to the copyright statement on stuff I wrote so that it was clear that in my absence I was cool with the rest of the collective dev team's wishes, but that also if I wanted to (re)use some of my own code somewhere else one day, that I hadn't fully ceded my own rights to it. (not that I ever planned to, but at least this way I never have to worry about reusing my own work/ideas/techniques in other personal projects) >> At time the GRASS Development team is not an incorporated entity >> usually the first copyright holder name in the source code files is >> the initial author followed by the GRASS Development team. >> If that's legally sufficient I cannot sat nor what the implications are. I guess the practical question is without a separate author listed do we have full standing to sue/pursue someone violating/abusing the GPL? (but since we have full CVS/SVN history going back to the introduction of GPL GRASS c.'99, tracking down the actual contributor isn't a real problem) Is there any code outside of the addons repo that *only* lists the GRASS dev team as the author and no one else? And if so, wouldn't the main COPYING and GPL.TXT files already blanket cover anything within a release tarball anyway? i.e. is this actually an issue? My understanding of why individual code files had (c) statements was to make it easy to avoid mistakes where individual files on file systems getting copied over and the GPL providence forgotten. With it there it takes a positive physical action to 'forget' the authorship. But even if it weren't, the code (or icon image for example) would still be blanked covered by the COPYING file. And thus we should perhaps put forward that OSGeo should have all member projects' COPYING files reviewed by a FOSS lawyer for validity &/or common mistakes. Michael wrote: > Also, since OSGeo is in the US, does that mean that all GRASS has to comply > with Us copyright laws? Many authors are not from the US. How does this work > in an international Open Source project. I think GRASS has to comply with US copyright law as long as we distribute creative works to anyone with the US*. Regarding other countries I'd suspect that the number of countries we'd have to deal with that are not party to the Berne Convention is beyond our worry. So we can just consider the international case. [*] in practice anyway. Authors with a physical presence, authors traveling there, and OSGeo being 501c4 registered there makes the jurisdiction question rather moot. But I'm not a lawyer. The fine folks at the SFLC are though, if this was a matter we were ever really worried about or had to deal with. best regards, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] Card or Flowers for Markus?
Hi everyone, I would certainly be interested in conveying my best wishes, warm regards, and support, in whatever way is most suitable and practical. many thanks, Hamish ___ grass-psc mailing list grass-psc@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-psc
[GRASS-PSC] Registered on Codeberg.org?
Hi folks, I noticed that last week someone registered "Grass-Development-Team" as a project org on Codeberg*. I was wondering if you were aware of this and if it might have been one of you. [*] https://codeberg.org/Grass-Development-Team Codeberg is shall we say "not at all dissimilar" to GitHub, but run by a non-profit and all FOSS. best regards & have fun in Vienna, Hamish (who is all for supporting FOSS backend infrastructure) ___ grass-psc mailing list grass-psc@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-psc
