+1 to what Ralph said On Sat, Sep 30, 2023 at 0:56 Scott Deboy <scott.de...@gmail.com> wrote:
> +1 to everything Ralph said. > > On Fri, Sep 29, 2023, 3:53 PM 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. > > >> > > >> > > > > >
