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
