Interesting... but I think Paul is right when he states that this will probably just hold people back who are active. And with our lack of personpower I dont think we want to do this.
As a module maintainer I am ok with having commits going through without my review if I cannot respond within three days. Even if my response is "I will review it when i get a chance..." I think we can stick with trying to enforce this as project policy for now as opposed to restricting version control access. As for inactive module maintainers, when was the last time we went through all the modules and pinged module maintainers. Perhaps it is time for that again. I can volunteer up some time to go through each pom and generate a list of the module maintainers. We can then test our three days grace theory and see which module maintainers respond within three days. Any other comments / complaints / concerns? -Justin Paul Ramsey wrote: > I can provide a programmatic fix to this problem, if you like, and that > is to turn on directory restrictions in SVN, and only provide write > access in modules to the maintainers. That way a true patch-queue would > be enforced. However, it would potentially cause huge bottlenecks where > inactive module maintainers exist/come into being. This is sort of what > PgSQL does, all the patches come through Bruce Momjian who maintains the > patch queue, but he does that full-time, while our module maintainers > disappear regularly and unpredictably. > > P > > On 26-Sep-06, at 11:46 AM, Jesse Eichar wrote: > >> During a talk I had with Justin we decided that a good policy for >> collaboration on a module (assuming all module maintainer agrees to >> this level of collaboration) is: >> >> 1. Create a JIRA (make sure to assign it to Module maintainer) >> 2. Create a patch and attach it to the JIRA >> 3. >> a) Module maintainer says "Go" then you can commit >> b) Module maintainer is silent for 3 days then you can commit >> c) Module maintainer provides a suggestion then make the suggested >> change and start over at step 2 >> >> >> On 25-Sep-06, at 6:37 AM, Justin Deoliveira wrote: >> >>> Sorry for the late reply, but this commit already went through I >>> take it. >>> I was hoping to get a chance to review it first. With Chris >>> bringing up >>> policy, I am having some issues with commit and ask questions later >>> style >>> we seem to have adopted. >>> >>> One thing I would like to ask is that before any more improvements are >>> made the results of my last code review are addressed. I have >>> brought this >>> up but the problem still persists. It is the issue with JDBCDataStore >>> modifying the passed in query object in getFeaturerReader. >> >> This is a small error, the Query should not be changed it place a >> copy should be made and the new copy should be >> modified. Is there a JIRA for this issue? >> >>> >>> As module maintainer I would like to fix this, but since it has to >>> do with >>> the filter splitting changes that were introduced, and I dont >>> really know >>> that code, I dont feel comfortable doing so. Which begs the >>> question why >>> am I the module maintainer if a) I am not he most active developer >>> and b) >>> i am completley unfamiliar with major parts of the code in my module. >>> >>> -Justin >>> >>> On Sun, September 24, 2006 12:07 am, Chris Holmes wrote: >>>> Cool, just did a quick code review, and things look pretty good. >>>> >>>> >>>> One big thing missing though is parallel commits to trunk. We've >>>> been >>>> bad at this, and it wasn't something we talked about in >>>> switzerland - how >>>> to make sure we don't miss all kinds of bugs when we upgrade >>>> stable. We >>>> should get some kind of policy in place, but I thought I'd bring >>>> it up. >>>> >>>> best regards, >>>> >>>> Chris >>>> >>>> >>>> Cory Horner wrote: >>>> >>>>> Howdy, >>>>> >>>>> >>>>> I've been doing a little bit of PostGIS QA this week, as a few >>>>> wriggling bugs still live on. >>>>> >>>>> Changes include: >>>>> - exposing the ConnectionPool (this is mostly so tests may obtain a >>>>> connection and create tables) - PostgisDBInfo object (encapsulated >>>>> version info -- since several methods were asking postgis what >>>>> version >>>>> it was, and it is better to just ask once) - expanded PostgisTests >>>>> utility - GEOT-948: JDBC1DataStore is thread safe >>>>> >>>>> >>>>> Stuff for the not-too-distant future >>>>> - GEOT-950: the connection pool is NOT closed on shutdown -- >>>>> we'll do up >>>>> a quick hack for this in uDig in the meantime, but this needs to be >>>>> addressed. >>>>> >>>>> Jesse and I hope to have a look at the PostGISAutoIncrementFIDMapper >>>>> (partial test case written) on monday, since non-serial primary keys >>>>> don't seem to work. >>>>> >>>>> After that is complete, it would be great if the Geoserver guys >>>>> could >>>>> run some cite tests... >>>>> >>>>> Cheers, >>>>> Cory. >>>>> >>>>> >>>>> >>>>> -------------------------------------------------------------------- >>>>> --- >>>>> -- >>>>> Take Surveys. Earn Cash. Influence the Future of IT >>>>> Join SourceForge.net's Techsay panel and you'll get the chance to >>>>> share >>>>> your opinions on IT & business topics through brief surveys -- >>>>> and earn >>>>> cash >>>>> http://www.techsay.com/default.php? >>>>> page=join.php&p=sourceforge&CID=DEVD >>>>> EV >>>>> _______________________________________________ >>>>> Geotools-devel mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Chris Holmes >>>> The Open Planning Project >>>> http://topp.openplans.org >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> ---- >>>> Take Surveys. Earn Cash. Influence the Future of IT >>>> Join SourceForge.net's Techsay panel and you'll get the chance to >>>> share >>>> your opinions on IT & business topics through brief surveys -- and >>>> earn >>>> cash >>>> http://www.techsay.com/default.php? >>>> page=join.php&p=sourceforge&CID=DEVDEV >>>> >>>> >>>> !DSPAM:1004,451604b4224007731818748! >>>> _______________________________________________ >>>> Geotools-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>>> >>>> >>>> >>>> !DSPAM:1004,451604b4224007731818748! >>>> >>>> >>> >>> >>> ---------------------------------------------------------------------- >>> --- >>> Take Surveys. Earn Cash. Influence the Future of IT >>> Join SourceForge.net's Techsay panel and you'll get the chance to >>> share your >>> opinions on IT & business topics through brief surveys -- and earn >>> cash >>> http://www.techsay.com/default.php? >>> page=join.php&p=sourceforge&CID=DEVDEV >>> _______________________________________________ >>> Geotools-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to >> share your >> opinions on IT & business topics through brief surveys -- and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Geotools-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > !DSPAM:1004,451976cb299781527717022! > -- Justin Deoliveira [EMAIL PROTECTED] The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
