These are great points, Ralph. I think we’ve done a good job of separating the parts we wish to support long term from the more experimental pieces, and retiring experiments is fine. — Matt Sicker
> On Sep 29, 2023, at 17:52, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > I’m sorry, I can’t really agree with much of any of this. Following the > thoughts being proposed in this thread much of Log4j 2 and even the initial > work I did to create it would not have seen the light of day. Almost 100% of > the stuff Matt has done would never have happened. > > It is a fact that people come and go from projects. Some stay longer than > others. We have had PMC members who disappeared the day after they were > elected to the PMC. Remko arguably made two of the most significant > contributions in the GC-Free and Async work. Yet he has largely gone > inactive. It happens. Even after accepting the JsonTemplateLayout and Volkan > as a committer we had no guarantee he would stick around. We hoped he would > and he did. Gary and I have each contributed a large number of components > because they met some need we have/had and we continue to support them. > > Requiring hoops that must be jumped through before stuff can be accepted is > just a terrible idea. It does nothing but create a perception that we are not > open to new contributions and new contributors. > > Yes, we can retire things. I don’t think anyone is arguing against retiring > log4j-cassandra. I haven’t seen any arguments against log4j-kafka. That is > primarily because they are woefully out of date. However, there is nothing > wrong with a module that hasn’t had any updates in a long while if it is > meeting user’s needs. You are never going to know for certain home many users > there are of a given module. That data is impossible to get. Any company that > has their own repository manager (which should be most) will download a > release of an artifact from Maven Central once and it will be hard for you to > know when they did it. The metrics Sonatype provided came from their security > product, which not everyone purchases. Yes, you can make guesses from those > numbers but you can’t actually know how good those guesses are. > > In short, I am in favor of retiring things when they are no longer > maintainable. I am completely in favor of adding new components when they > make sense. IOW, every contribution needs to be considered on its own merits. > > Ralph > > > >> On Sep 29, 2023, at 11:32 AM, Gary Gregory <garydgreg...@gmail.com> wrote: >> >> I think Jira is good enough for that, since there is transition from state >> to state that can be used to shepherd issues through. RFC, JEP, all way too >> heavy handed for us IMO. >> >> Gary >> >> >> On Fri, Sep 29, 2023, 2:05 PM Matt Sicker <m...@musigma.org> wrote: >> >>> I think it could be valuable for us to establish some form of an RFC >>> process for proposing and developing major new features. I also want to >>> avoid being too process-heavy here as that would also disincentivize >>> contributions. I agree that we should try to be more data-driven to >>> determine what features and products should have the most attention. >>> >>> I do like the idea of having “sample” plugins which are not distributed as >>> binaries, though, which can be used in documentation for examples of how to >>> integrate your own systems. With the flexibility of the plugin system here, >>> we can defer the implementation of more obscure integrations to the end >>> user. >>> >>> I will note that we do already have some level of filtering to what we >>> include. I’ve proposed numerous features in the past that I didn’t pursue >>> due to reasons raised by others or lack of interest. >>> >>>> On Sep 29, 2023, at 2:59 AM, Volkan Yazıcı <vol...@yazi.ci> wrote: >>>> >>>> I want to challenge the current way of PMC determining the product >>> feature >>>> set and work towards a more sustainable alternative. >>>> >>>> Logging Services team... >>>> >>>> - delivers mission-critical products that are deployed at the core of >>>> the world-wide infrastructure (actually, in Mars too) >>>> - is short on development resources compared to its wide range of >>>> offerings >>>> - deals with substantial amount of legacy >>>> - suffers from knowledge silo >>>> >>>> Any IT team in this state would be really conservative on accepting new >>>> features and try hard to get rid of the bloat. They would react to this >>>> challenge by first discovering the user base, pinpointing the core >>> values, >>>> and then lazer-focusing the limited development resources on to the >>> crucial >>>> deliverables. Though we do something totally different, one can even say >>>> the opposite. Below I share excerpts from recent mailing list posts. >>>> >>>> *"I had added [X] ... to show how to write plugins and for some >>>> consulting-related use cases"* – PMC member explaining how feature X was >>>> released >>>> >>>> *"... stuff seems like it could be useful"* – PMC member asking to keep >>>> feature X >>>> >>>> *"my employer used [X] ... for anyone implementing ... this would be very >>>> relevant. By archiving this we are basically telling users that they >>>> cannot use it any more since it will no longer be supported. For that >>>> reason I am not in favor of [retiring]"* – PMC member asking to keep >>>> feature X >>>> >>>> *"We [the employer] ... use [X]"* – PMC member asking to keep feature X >>>> >>>> *"User base [is] ... very low to non-existent."* – PMC member asking to >>>> keep product X >>>> >>>> *"[PMC member] has steadfastly [reacted] ... and until he positively says >>>> he will no longer maintain it I am not willing to override that"* – PMC >>>> member asking to keep product X because another (one and only) PMC member >>>> reacted on product retirement inquiry >>>> >>>> *"Our employers are ... paying customers."* – a PMC member explaining why >>>> we should keep feature X used by an organization employing another PMC >>>> member >>>> >>>> >>>> I see a pattern in the way we decide to maintain a feature/product: >>>> >>>> - It is not data-driven. It is disconnected from its user base. No >>> usage >>>> statistics, etc. is shared or used. >>>> - We serve individuals' and employers' agendas. >>>> - We underestimate the cost of adding/keeping a feature. >>>> >>>> I think this diet is "unhealthy" because: >>>> >>>> - It adds up to the bloat. It is yet another component developers need >>>> to maintain its dependencies, documentation, website, integration with >>> the >>>> build system, etc. This bizarrely slows down the development >>> experience. >>>> (Ever wondered how much `log4j-osgi` takes during `./mvnw verify`?) >>>> - It adds up to the attack surface. >>>> - Features that are supposed to be optional get shipped to users >>> without >>>> their consent. (Consider the percentage of the Log4Shell victims that >>> used >>>> the JNDI functionality at all.) >>>> - Scarce development resources get wasted on chores due to the >>>> excessive landscape. >>>> - It gives users the wrong impression that the feature/product is >>>> maintained, though under the hood it is just kept there because a >>>> privileged group wants so. >>>> >>>> I want to refine this approach with your help. To start the discussion, I >>>> propose the following strategy instead: >>>> >>>> *"We only accept a feature with data-driven justification."* – Have a >>> brand >>>> new idea? Grab yourself a GitHub/GitLab repository that belongs to either >>>> you or your employer, knock yourself out without any ASF/PMC burdens, and >>>> amaze your users. Once the user attraction gets enough gravity, let's >>>> discuss blessing it as a part of the official Logging Services offering. >>>> Official support channels are always open to assist the developers of >>> such >>>> external efforts. >>>> >>>> *"We only keep a feature with data-driven justification."* – Do you >>> think a >>>> feature needs to be retired? Bring it up for discussion. PMC should >>>> evaluate the request based on numbers and this process should be >>>> independent of the individuals'/employers' agendas. If PMC decides to >>>> retire a feature/product *and* there are people who volunteer to continue >>>> the development on a successor fork outside of ASF, PMC should do their >>> due >>>> diligence to point existing users to this fork without any endorsement. >>>> >>>> >>>> I look forward to hearing your thoughts. >>> >>> >
