[
https://issues.apache.org/jira/browse/LOG4J2-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14723372#comment-14723372
]
Bart S. commented on LOG4J2-1093:
---------------------------------
You act as if you are someone doing me a huge favour by accepting a patch.
That's the other way around, I'm doing you a favour and if you don't like that
then you can't have that. That's simply a truth. I'm not supposed to go
crawling for you just to get something accepted; if something is unwelcome;
then it's unwanted, and I'm not going to go out of my way for you to make it
wanted.
It is either a welcome thing or it is not a welcome thing; I do not have to go
out of my way for you in order to "prove" a thing.
I asked a few questions in my initial message; they were not aswered. Then,
Gary, when pushed (twice) gave some feedback, noting that there had been other
changes THAT I ALREADY WROTE ABOUT. So here I am writing to explain myself, the
person doesn't read it, and then asks a question (almost) (it was almost a
question) that had already been answered.
You are wasting my time continuously by doing things this way.
Of course the patch will not be accepted without unit tests. I DID NOT ASK FOR
THE PATCH TO BE ACCEPTED. You people are rotten to the core.
1. I ask whether the patch is going to be welcome in any measure or degree.
2. I ask whether the changes I have made violated some user styles standards.
3. I ask whether moving the santity checks out of the create method was a good
idea.
I get no answers to those questions.
Then Gary, when pushed, nice man as he is, skips over my text, reads the
changes in the patch, then notes that there have been other changes already
sufficiently explained in my text, and wants an answer on that, when I had
already given that answer, and I wanted answers myself in regards to that. You
are setting me back 2 steps, and ask me to redo what I've already done but you
were too lazy to read.
This is a really small patch. It amounts to almost nothing. It creates a very
simple builder and moves some code around. Of course there is a potential for
error. I was going to write unit tests if the patch was accepted in principle.
Or after amendmend. I wrote about those things. I asked for amendmend.
So I cannot work with you people this way. I do everything right, but you fail
to respond with what's necessary to get it done, instead trying to place the
burden on me.
Apparently that's what open source is about: placing the burden on someone
else. I recently read a random discussion on some blog about some script. A
user suggests that the package/script is broken or flawed in some way. The
creator/maintainer immediately says "If you have a fix, please submit a pull
request." The user's idea was not meant for starting to submit solutions right
away. He merely wanted to indicate a problem. The maintainer immediately tried
to place the burden on the bringer of bad news. Trying to shove the
responsibility for the software onto him. You fail to understand what belongs
to whom.
My task is to elucidate what I've done.
Your task is to answer my questions or to ask questions about what I've done
(if necessary).
My task is to incorporate your desires and to change it as you wish, according
to the standards you have for this project, and that it agrees with you and can
be incorporated into the system as desired.
Your task is then to see if everything is okay about it and then incorporate it
if required or requested or desired.
you are doing it this way:
- I submit an idea/patch and tell you about it
- you don't read it and ask for a unit test and note that there's something odd
about the code.
- I'm supposed to supply a full unit test and write again what I have already
written before
- You check that the unit test works, which doesn't tell you really anything
else accept the code doesn't break.
- You now still have to answer my initial questions or think about whether you
really want it.
- We are still at the second stage (above) and haven't proceeded at all,
wasting everyone's time.
You may think "nondiscussion" advances things faster but it does not, unless
you want a flawed system and wasted time everywhere.
It is easy enough to see the changes I've made in this patch. I don't have to
tell you about it if you read it. It is clear what I've done: create a
sanityCheck function and move some code to it. That's all, there is nothing
special to it, it doesn't take more than 2 seconds to understand. "The patch
contains what appears to be non-builder changes at @@ -118,33 +122,21 @@" just
doesn't cut it. That's not viable.
This is not a workable process. It just frustrates everyone and doesn't advance
the work. I will not do stuff that is nothing other than a waste of time for
everyone, while you are trying to waste mine. If you had just answered my
questions (if possible) straight away and suggested amendmends, I would easily
have made them, written the unit test, and be done with it. Quick, fast and
efficient. Writing the unit test (like, stage 5) before the initial questions
have been answered (like, stage 2) is not efficient and it might end up doing
stuff that you can subsequently throw away -- ie. time waste.
I'm sorry, but your system is flawed, this doesn't work. I'm proceeding like a
normal human being and you're throwing up road blocks out of some sense of
superior position and the right to claim my "contributions" as you see fit,
irrespective or without regard for how much time it could cost me.
You think that your time spend reading my text (2-3 minutes) warrants my time
spent writing unit tests (30 minutes) and this is a good tradeoff, that you can
sacrifice my 30 minutes of time so that you won't have to spend your 3 minutes
of time potentially wasting it if you don't like it after all.
Asking for so much contribution up in advance is not a right thing. You cannot
ask to see the money first.
I'm not going to make any advance payment to get something accepted other than
what I've already done. You can call that my attitude, but I love my attitude,
it is more like my choice of self respect.
I'm sorry, but your attitude of "this patch will not be accepted" is just
WRONG. I have no obligation to work for you. I'm not in it for the money. I do
it because I love it. I'm not trying to get "credit" or gain "status". You're
acting like you have the right to demand things from me. If you don't want the
patch, then just say so, don't throw up fake reasons.
You are not in the position of gratitude here, I am. I am grateful if the patch
is accepted. You, apparently, don't care. This attitude of not being grateful
at all for what other people do for you is what's going to cause this person to
leave pretty soon, unless something changes to improve it. It will be your
loss, not mine, because I'm just going to continue my work based on something
else.
Regards, B.
> Builder for FileAppender
> -------------------------
>
> Key: LOG4J2-1093
> URL: https://issues.apache.org/jira/browse/LOG4J2-1093
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders
> Affects Versions: 2.4
> Environment: Any
> Reporter: Bart S.
> Labels: features, patch
> Attachments: FileAppender_patch-Builder-proposal.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Hi, In my quest for programmatic control I ran into the fact that the
> FileAppender didn't have an Builder method to use.
> I really wanted to brainstorm about it first before I sent in my patch,
> seeing as that it might deviate from coding standards that I'm not completely
> aware of.
> The FileAppender has these issues with creating a Builder:
> - the create..... method takes String parameters and does sanity checking
> - to have a builder use the create.... method requires converting all
> parameters back to String, which is ugly and in a sense time consuming.
> - the same is true for the ConsoleAppender and its builder just does away
> with any sanity checks and error messages and just calls the constructor
> directly.
> I have taken a different path in my code. I have extracted the sanity check
> and placed it in its own routine. So there are basically four options:
> * no sanity checking for the builder
> * builder uses create method
> * create method uses builder
> * separate sanity checking and call both from create and builder
> I have currently chosen the latter path. I use a MutableBoolean or the
> equivalent. My current code uses a new static inner class just thrown
> together for this purpose, but I believe the Core utilizes
> org.apache.commons.lang3, which contains mutable.MutableBoolean.
> The rewrite is currently complete and compiles well. The unit test for
> FileAppender still completes without fail (1 skipped, it says):
> {quote}
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running org.apache.logging.log4j.core.appender.FileAppenderTest
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 4.713 sec -
> in org.apache.logging.log4j.core.appender.FileAppenderTest
> Results :
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 1
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 01:18 min
> [INFO] Finished at: 2015-08-12T17:59:18+02:00
> [INFO] Final Memory: 22M/336M
> [INFO]
> ------------------------------------------------------------------------
> {quote}
> Meanwhile, my own code that utilizes it compiles against it and works
> perfectly. I haven't written a unit test or tests for it yet.
> Moreover, I have made these changes:
> - extract sanity checking from create........() method. Into its own
> "checkParameters() : boolean".
> - the boolean value that is subject to being changed is turned into a type of
> MutableBoolean (simply a class with a boolean field at this point)
> - this variable is passed to the checking function where it might get changed
> - the value of the variable is subsequently used in place of the original
> boolean
> - this {{checkParameters()}} is called from {{createAppender()}} AND from
> {{Builder.build()}}.
> - a minor amount of code is still duplicated, namely the creation of the
> manager (FileManager) and the call to the constructor.
> - annotations and style is/are mimicked as much as possible from
> ConsoleAppender.Builder
> That's all for it now. You can view the result at the attached diff. Note
> that there is still no unit test for it and this is just a proposal, open for
> amendment and suggestion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
