On Sun, Oct 9, 2022 at 10:36 AM Jody Garnett <jody.garn...@gmail.com> wrote:
> Jody here with some notes for the discussion: > Most of the notes here are diverging from the point at hand, and present no novelty. I'm going to use a GeoServer 2.20.0 release I have locally to show the behavior previous to the one incompatible change pointed out at the beginning of this thread. > > 1. The documentation refers to these as built-in logging configurations. I > think it is good that the built-in logging configurations are available for > use as an example (rather than just hidden in a jar). > > https://docs.geoserver.org/main/en/user/configuration/logging.html > Using 2.20.0, I have removed all the configuration logging files (*.pèroperties), restarted GeoServer, they are all back in the directory. They have always served as example, never been hidden in a jar file. > > 2. The documentation on customization (above) has an example that starts > with copying a built-in configuration and making changes. > The ability to configure a custom profile is not new, I have been creating them for ages. Here is the 2.20.x documentation, showing how to customize a logging profile using property files: https://docs.geoserver.org/2.20.x/en/user/configuration/logging.html#custom-logging-profiles > 3. The blog post has some more details on updating from properties --> > xml; but also updating about the built-in xml definitions updating each > release. Reading the blog post it just has an example using properties and > not an xml file. > Communication is good, thank you for doing that. However, not relevant to the point at hand, let me copy and paste the title of this thread: "Default logging profiles are no longer customizable" . For reference, I edited the 2.20.x DEFAULT_LOGGING.properties to a date format more similar to a ISO date, started GeoServer, pattern holds, stop and restart, still there. As said above, if one wants to recover the built-in tiles, they just have to remove them, and GeoServer 2.20.x would expand them back from the classpath. This is the behavior everyone has been used to, for at least the past 15 years. > If you made any customizations to the built-in profiles, you can recover > your changes from backup bak file. You can use this backup as a reference > when creating a new xml logging profile, or restore this under a > different name which does not conflict with the built-in logging profiles. > That has been your own decision, taken without discussing it in a GSIP or mentioning it during mail discussion. This is the real point of this thread. Change is possible, but it requires public discussion, not single handled bulldozing because you think you know better. If and when the PSC agrees the direction is good, then we communicate to users that the behavior they were used to, it's no longer there. > 4. I do expect these logging configuration to change over time, see bug > https://osgeo-org.atlassian.net/browse/GEOS-10701 for an example. As such > it is nice to treat these as built-in and managed as part of the software. > I expect to own the files just like any other file in the data directory. I has been like that for as long as I can remember. It was not your place to make this decision, you are putting yourself above us all, and the rules/customs that govern this community. To draw a parallel, can you remove the *built-in styles*? Not really, GeoServer will try to re-create them, because it needs them to work. Can you edit them? Yes you can, I do it all the time (it's my own responsibility to keep them semantically in line with their intended usage, and if not, I'll pay the price at every new layer configured). That same goes for the built-in logging profiles, I edit them if I want to get information presented in a different way... e.g., when I'm trying to debug a concurrency issue at a customer site, I have them add the thread id in the log pattern. That does not change the semantics of a "DEFAULT_LOGGING", it's just giving me better information. Unfortunately most of our customers are still on older versions of GeoServer and had not noticed the issue until a few days ago. > aside: Initially I tried writing some code that checked if the built-in > files had been customized; and only update ones that had not had their > checksum change. PR review guidance was to simplify the code. Perhaps > reviewers were thinking it was only applying with updating from properties > --> xml and not an ongoing policy. > Indeed, I could not have expected a PSC member to just go and change the behavior like this. The notion that you're talking about this as a precise decision you made, instead of a simple oversight, is even more shocking. Let me quote a bit of our GSIP process: "Generally you will make a GSIP when you want something major done in GeoServer and need feedback from others. *GSIPs are needed for things that will have an impact on other community members*, and thus should be talked about." Lately you have been waving the "would you like to write a GSIP?" for minor new features, but then sneak into a large PR a change that *does impact on other community members*, without discussion. I believe we need a new GSIP that clarifies, with enumeration and examples, what warrants a GSIP, and what does not. Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://bit.ly/gs-services-us for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions Group phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 https://www.geosolutionsgroup.com/ http://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
