Andrea I am really not attached to either behaviour, if you would like to change it so the built-in profiles are not overwritten like before that is fine.
You wanted to bring this to the email list for discussion and we are. Jody On Sun, Oct 9, 2022 at 9:54 AM Andrea Aime < andrea.a...@geosolutionsgroup.com> wrote: > 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 > -- -- Jody Garnett
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
