Thanks for the discussion Andrea. We should also acknowledge the pain in the other direction - there is a category of "small fixes" where our response (although understandable give our limited resources) is viewed as out of line with respect to other open source projects.
It may be simply a difference in scale, although I understand your points about "focused" changes which break a wider story. Still we have examples such as the recent conversation about date representation where this has been handled well. I think we could collect examples like this to use in documentation. While I wish we could somehow lighten up with respect to smaller changes - I feel we are managing a large codebase reasonably well (with respect to requiring a test-case and/or docs). Adding "discussion" to that list would be appropriate. -- Jody Garnett On 26 December 2015 at 10:45, Andrea Aime <andrea.a...@geo-solutions.it> wrote: > Hi, > as you can see, pull requests are going "well", we have quite a bit of > them coming > in all the time, and compared to other projects, relatively small queues > and wait times. > Yet, this continuous flow, coupled with the chronic lack of people > dedicating > time to review them, makes me believe we need to do something to streamline > this further. > > The first choice in a community project would be to throw more "meat" at > the problem, > having more reviewers. This has been brought up before, and some > unsolicited help > (people that we don't need to call up by name to get some opinion) > showed up, but imho we are not nearly enough yet. > > I am wondering, would it help if we added in the wiki a review guide? > Would that > make more people show up to do reviews? If not that, what will? > > Another issue is that some come out of the blue and propose > deep changes, or large refactors, making them very hard to review, as in, > demanding > the reviewer to literally spend several hours of their spare time on a > single pull request > just to handle aestetics/class structure changes, connect the dots and > figure > out if the change is actually an improvement or not. > Shall we just add to the list of pull request criterias "keep changes to a > minimum, be > mindful of those reviewing them"? Other ideas? > > Moving on, there is a number of people making pull request with changes > that are > so focused on their specific issue that it's hard if not impossible to > merge the changes, > because they don't see the big picture and are causing regressions in > other use > cases. > Again, maybe we should just write in docs in a more evident way to discuss > before > proposing changes, in order to avoid the above? Or ask people to consider > all ways the code they are using can be leveraged, and not just their > particular > use case? What else? > > Finally, another source of pain is that the core developer doing the > review is held responsible > for the changes being merged, while the person proposing the pull request > should be instead. > Now, we cannot have these people contributing pull requests be responsible > forever, > but could we setup some policy that if anything goes wrong with the pull > request, they are supposed > to be around and help fixing the mess, for some amount of time (like, > don't know, > 2 to 6 months?). If they are not, the commits just get reverted instead > (assuming > it's possible, sometimes it will not be). > Also, it would be great if we could ask them to sit on the user list to > answer of their > changes to the user base, for the same amount of time (right now it's > pretty much > the core dev that merged the pull doing that, which is also unfair). > This would be mostly for new features/large changes, not for bug fixes, > although > I would really love to have the responsible be grilled by the angry users > when > a so called bug fix causes some important regression. > > That's what I have, any other idea is course more than welcomed :-) > > Cheers > Andrea > > > > -- > == > GeoServer Professional Services from the experts! Visit > http://goo.gl/it488V for more information. > == > > *Geosolutions' Winter Holidays from 24/12 to 6/1* > > Ing. Andrea Aime > @geowolf > Technical Lead > > GeoSolutions S.A.S. > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > phone: +39 0584 962313 > fax: +39 0584 1660272 > mob: +39 339 8844549 > > http://www.geo-solutions.it > http://twitter.com/geosolutions_it > > *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* > > Le informazioni contenute in questo messaggio di posta elettronica e/o > nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il > loro utilizzo è consentito esclusivamente al destinatario del messaggio, > per le finalità indicate nel messaggio stesso. Qualora riceviate questo > messaggio senza esserne il destinatario, Vi preghiamo cortesemente di > darcene notizia via e-mail e di procedere alla distruzione del messaggio > stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, > divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od > utilizzarlo per finalità diverse, costituisce comportamento contrario ai > principi dettati dal D.Lgs. 196/2003. > > > > The information in this message and/or attachments, is intended solely for > the attention and use of the named addressee(s) and may be confidential or > proprietary in nature or covered by the provisions of privacy act > (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection > Code).Any use not in accord with its purpose, any disclosure, reproduction, > copying, distribution, or either dissemination, either whole or partial, is > strictly forbidden except previous formal approval of the named > addressee(s). If you are not the intended recipient, please contact > immediately the sender by telephone, fax or e-mail and delete the > information in this message that has been received in error. The sender > does not give any warranty or accept liability as the content, accuracy or > completeness of sent messages and accepts no responsibility for changes > made after they were sent or for other risks which arise as a result of > e-mail transmission, viruses, etc. > > ------------------------------------------------------- > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > >
------------------------------------------------------------------------------
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
