On 2018-12-19 20:55, Farhan Nasim wrote:
1. Thanks for informing about the 'next generation' RollingFileAppender. I
have been going through your feature branch and it seems to be the right
futuristic path. I'd like to contribute to it.
Awesome! Let me know if I can help you in any way.
2. However, I have queries regarding the faster way to make my appender to
productio. Putting together the subset of RollingFileAppender
functionalities in its NG counterpart will take some time and the NG
appender will take some time to be popular too.
The NG counterpart should explicitly provide only a very small subset of
the original functionality. Less is more. To provide people a migration
path, it should support custom rolling strategies. The coupling between
the rolling strategy and the appender should be as small as possible.
On the other hand, the appender I am proposing (derived from
RollingFileAppender) is nearly complete. RollingFileAppender has many
issues, but still it is the most popular I think and is quite acceptable in
low-strain conditions. How about reusing RollingFileAppender for now and
working on the NG at the same time, for future releases? Or is it the
resolution across log4net that "no more extensions to RollingFileAppender"?
:D
The RollingFileAppender has a long history and survived several futile
attempts to improve it. Some of those attempts even caused collateral
damage for the many use cases that it has grown to be used for. It
should be touched with outermost care.
3. In order to contribute, shall I create a new branch from the NG feature
branch, make changes, and send pull requests into the NG branch? Or can I
commit directly to NG branch?
That's up to you.
1. If you want to help writing the next generation RFA, the branch to
base your contribution on is probably feature/RollingFileAppender-NG.
You should merge develop into that branch to avoid these branches drift
apart.
2. If you are going to contribute to the existing RollingFileAppender,
the branch feature/rfa-configurable-rolling-mutex is probably the right
place. That branch however needs proper testing to be merged into
develop. It would be great if you could help us with testing, too. :-)
3. You probably also noticed that there's a release branch, tracking
what changes are going to be part of the next release 2.1.0. That branch
also needs proper testing, possibly by using the binaries that jenkins
builds for us. The plan is to use those binaries in the release process
but the lack of testing is a blocker for the release process of 2.1.0. I
feel uncomfortable with publishing binaries built by jenkins for the
first time without a basic test for every published binary. I thought of
pushing several sample projects to github that both serve as templates
but also as testing sandboxes of more realistic environments. Help from
the community is of course greatly appreciated.
Cheers,
Dominik
