On Mon, Oct 2, 2023, at 17:38, Ralph Goers wrote:
>>> Agreed. Sandbox could be open even for all ASF committers, entry barriers
>>> could be low. Dormant components could go back to sandbox as well, if new
>>> people want to work on it.
>>
>> Can we create a repo open to all Apache committer
The JDBC appender is a mission critical component for me. I maintain it
whenever something pops up. I even think there is a fix in git 2.x for the
next release.
There is no way to know reliably who uses what, by design of the whole FOSS
ecosystem. Querying the user's mailing list for this type of
> On Oct 2, 2023, at 12:04 AM, Volkan Yazıcı wrote:
>
> I give up. Gut-feeling-driven development FTW.
>
> Ralph, quoting your own words, "async and gc-free stuff exploded the
> complexity of the code base".
Yes it did. Matt has refactored the Plugin support at least 3 times and each
time i
I agree with most everything you said. Minor quibbles below.
> On Oct 2, 2023, at 7:19 AM, Piotr P. Karwasz wrote:
>
> Hi Christian,
>
> On Mon, 2 Oct 2023 at 13:13, Christian Grobmeier wrote:
>> Sandbox, dormant and stable are not hoops but communication about the health
>> of a component.
>
Hi Christian,
On Mon, 2 Oct 2023 at 13:13, Christian Grobmeier wrote:
> Sandbox, dormant and stable are not hoops but communication about the health
> of a component.
I like this idea.
I think that the main problem we have been debating on this mailing
list since September is how to communicat
Hi
On Sat, Sep 30, 2023, at 00:52, Ralph Goers wrote:
> 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.
I am also against hoops, but a
I wasn't implying a formal paper work people need to follow. I just wanted
to establish a consensus on the discussions of which features to keep/drop
should be driven by data.
On Fri, Sep 29, 2023 at 8:05 PM Matt Sicker wrote:
> I think it could be valuable for us to establish some form of an RF
I give up. Gut-feeling-driven development FTW.
Ralph, quoting your own words, "async and gc-free stuff exploded the
complexity of the code base". Plus, we are yet to reproduce Remko's "log4j
is faster than logback" results on a modern stack, where all of our earlier
attempts failed. Now I find it
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 wrote:
>
> I’m sorry, I can’t really agree with much of
+1 to what Ralph said
On Sat, Sep 30, 2023 at 0:56 Scott Deboy wrote:
> +1 to everything Ralph said.
>
> On Fri, Sep 29, 2023, 3:53 PM Ralph Goers
> 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 an
+1 to everything Ralph said.
On Fri, Sep 29, 2023, 3:53 PM Ralph Goers
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. Al
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 p
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 wrote:
> I think it could be valuable for us to establish some form of
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 fea
I see your point and agree with many things. I suggest we are not (only) making
"data-driven" decisions. Most of us do this for fun, not for money. It is
perfectly OK to decide just because we like it and enjoy ourselves.
You are raising an excellent point: maintenance.
We have a lot of stuff t
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
16 matches
Mail list logo
