Hi All, I discussed this a little with Andrea and I believe that, and here is my feedback.
Baseline is, we should strive to keep quality high. When I talk to end users in the real world, none of them is happy about the release early, release often thing they are happier "this works without issues" thing. So, IMHO: -1- we should account for reviews in the GSIP process, although we don't want that for each individual fix but for larger, new functionalities, yes we should. -2- accounting for reviews should not lead to delays for who is proposing the change. So there should be a fixed windows for reviews So I am fine with something along what Ben proposes: - I can say I'd like to review - I have to do it within 1W at most, that time passed the proposer can hit the merge button (or someone con do it for him) Feedback? Regards, Simone Giannecchini == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Simone Giannecchini @simogeo Founder/Director GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 333 8128928 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. On Wed, Aug 10, 2016 at 3:31 AM, Andrea Aime <andrea.a...@geo-solutions.it> wrote: > On Tue, Aug 9, 2016 at 10:48 PM, Ben Caradoc-Davies <b...@transient.nz> > wrote: >> >> Andrea, >> >> we raised this problem in the committee meeting. Rather than a mandatory >> delay, we could add an "interested parties" section to each GSIP so that >> those wanting to do so could advertise their desire to review pull requests >> for the GSIP. We could add a rule to the GSIP procedure that all subscribers >> listed in the "interested parties" section must be given a week (or two if >> requested?) to review pull requests, even after the pull request is >> accepted. This would allow clearer communication of interest and >> availability. > > > Hi Ben, > it's interesting that you name it a "mandatory delay", given my experience > with pull requests related to GSIPs and new functionality > in general that sounds more like a mandatory speedup, I hardly see any pull > request of significance being handled within the week (normally > because we allow others to have a look at it before merging). > Indeed, to make a parallel, the week long rules about voting on the > proposals were meant to avoid long delays, not to force a slowdown. > > The particular context here spins it as a delay because we have just > experience something novel, a GSIP related > pull request being merged so quickly that "interested parties" did not even > have time to check their availability, let alone do a review. > > Allowing a bit of time to review a GSIP related pull request is important, > for a number of good reasons: > > If the proposal was high level, details that might spun acceptance one way > or the other can only be seen in code. The PSC should be allowed to check > what actually happened code wise in this case. > If the the proposal was detailed and low level, actual implementation could > have diverged from it in some respect, normally because hitting the actual > code brings insight not available when writing the proposal. While it would > be too much to go back, change the proposal, and vote again based on > implementation results, the PSC should be allowed to check the divergence is > not so significant as to make the proposal invalid. > If something is proposal worthy, it's likely touching highly visible > portions of the user experience, or core code, so it's only natural that we > should check whether it's affecting backwards compatibility, performance and > stability. > > Generally speaking, it should be natural that if a pull request is related > to GSIP, it should go though more scrutiny, instead here we have some party > claiming that "it was voted on", so it can go in even as fast, if not > faster, than the average pull request. But as I said, if you check the pull > request queue, you'll find that changes of any significant often take more > than a week to be reviewed. > What I'm trying to push for is actually a process that's quicker than our > "tradition", disallowing "flash merges" but also setting up some > fairness/level playing field. > > Give the above, having to explicitly specify "interested parties" does not > seem like a good way to go, as the PSC is the "interested party" by > definition of GSIP. > > Taking GSIP-149 as an example, the pull request is not small (40 files > changed) and diverges from the GSIP by downgrading to "not implemented nice > to haves" some bits that were official part of the proposal (see description > at https://github.com/geoserver/geoserver/pull/1748 and compare to > https://github.com/geoserver/geoserver/wiki/GSIP-149) . > Personally I don't think the latter is a problem (but it's just me, others > might have a different opinion), although I'm surprised to see that the CSS > editor pages are still there (the proposal states "the CSS Styles page would > be deleted from the CSS Styling extension") and that no documentation has > been updated (but the style editor works in a significantly different way > now, so doc updates are actually mandatory). > Tomorrow (well, actually later today, it's Wednesday already here) I'll try > to check the actual code changes, but now that the pull request has been > merged, will there be any incentive to address the review? > > Cheers > Andrea > > > > > > -- > == > GeoServer Professional Services from the experts! Visit > http://goo.gl/it488V for more information. > == > > Ing. Andrea Aime > @geowolf > Technical Lead > > GeoSolutions S.A.S. > Via di Montramito 3/A > 55054 Massarosa (LU) > 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. > > > ------------------------------------------------------- > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning reports. http://sdm.link/zohodev2dev > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
