I don't think that we should regard the committer of this project as the
default user of OFBiz. With respect to evaluating logs, it most often is the system administrator. Again, think of the average user. We also have to consider that not all development effort takes place in this project, but also at user sites. Would we help those organisations and their staff by leaving it out and having them take extra steps to get it in again? If you can't find consensus amongst your selfs, ask the community. Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Tue, Sep 9, 2014 at 12:41 PM, Jacopo Cappellato < [hidden email]> wrote: > On Sep 9, 2014, at 12:24 PM, Pierre Smits <[hidden email]> wrote: > > > In stead of opposing each other, find consensus for the good of the > project > > and its community. > > This is the main reason the trunk should be kept as clean as possible, > instead of changing stuff to fit committers' personal preferences. > > Jacopo |
On Sep 9, 2014, at 12:54 PM, Pierre Smits <[hidden email]> wrote: > I don't think that we should regard the committer of this project as the > default user of OFBiz. With respect to evaluating logs, it most often is > the system administrator. Again, think of the average user. > Exactly: we shouldn't try to step in sys admin's shoes by trying to imagine and pre-configure OFBiz. Keep it as simple as possible without pretending to understand other's needs. Jacopo > We also have to consider that not all development effort takes place in > this project, but also at user sites. Would we help those organisations and > their staff by leaving it out and having them take extra steps to get it in > again? > > If you can't find consensus amongst your selfs, ask the community. > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com > > On Tue, Sep 9, 2014 at 12:41 PM, Jacopo Cappellato < > [hidden email]> wrote: > >> On Sep 9, 2014, at 12:24 PM, Pierre Smits <[hidden email]> wrote: >> >>> In stead of opposing each other, find consensus for the good of the >> project >>> and its community. >> >> This is the main reason the trunk should be kept as clean as possible, >> instead of changing stuff to fit committers' personal preferences. >> >> Jacopo |
Administrator
|
In reply to this post by Adrian Crum-3
Le 09/09/2014 11:42, Adrian Crum a écrit :
> Jacques, > > You still are not understanding what you are saying, and you are not understanding our replies. Thanks for clearing my brain :D > > You are saying: > > 1. You want to change log settings because it benefits Jacques. > 2. You want to change ignore settings because it benefits Jacques. > > Jacopo and I are saying: > > 1. Every developer wants different log settings, so they are free to modify them on their local copy. > 2. Every developer uses different tools and shortcuts, so they are free to add them to their local copy. > 3. Since every developer is different, we should leave #1 and #2 out of the trunk. 1) Seriously, *we had* the error.log before and I see no serious reasons and arguments in Jacopo's, Scott's and your answers to *remove it*. I find it particularly handy when I want to quickly know the current issues (often minors) in a custom deployment. Without having to grep and such, just read a short plain text file with all the errors collected in, no needs to look backward in zip files, etc. 2) Thank you for your permission of using my tools on my machine :) Jacques > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 9/9/2014 10:09 AM, Jacques Le Roux wrote: >> My answer was >> >What I mean is I don't see how and why (re-)adding error.log in >> log4j2.xml will make it messy >> >> I just added a point about performance issue because I knew it would be >> the next argument on the table. Adding few lines in log4j2.xml does not >> stand as an argument to me. >> >> Jacques >> >> Le 09/09/2014 10:55, Jacopo Cappellato a écrit : >>> Jacques, >>> >>> you are clearly not reading what I and others wrote. >>> >>> Jacopo >>> >>> On Sep 9, 2014, at 10:39 AM, Jacques Le Roux >>> <[hidden email]> wrote: >>> >>>> Le 09/09/2014 10:12, Jacopo Cappellato a écrit : >>>>> On Sep 9, 2014, at 9:52 AM, Jacques Le Roux >>>>> <[hidden email]> wrote: >>>>> >>>>>> I understand you want to keep things as clean as possible, but are >>>>>> we not going too far in our slimdown crusade? >>>>> This is ridiculous, Jacques. This is not about the slimdown >>>>> (crusade?), this ended up months ago. This is all about writing and >>>>> maintaining good, well-crafted artifacts and code. The current OFBiz >>>>> trunk is still a great mess and I am surprised (and a bit concerned) >>>>> that you think we are going too far in the attempt to keep things >>>>> clean. >>>> What I mean is I don't see how and why (re-)adding error.log in >>>> log4j2.xml will make it messy, really are we not splitting hairs here? >>>> If you told me, "this will slow down and the system" or something >>>> like that I could understand. But I explained why it should not, >>>> except if you have an extremely big issue and then this big issue >>>> would be your concern, not the error.log which would only be the >>>> symptom. >>>> >>>>> Jacopo >>>>> >>>>> >>>>> >>> >>> > |
In reply to this post by Jacopo Cappellato-3
Le 09/09/2014 12:41, Jacopo Cappellato a écrit :
> This is the main reason the trunk should be kept as clean as possible, instead of changing stuff to fit committers' personal preferences. It's clear and good to simplify the configuration on production site. On some other projet (mostly on debian ;) ), configuration file contains few enable element but so mostly commented configurations with context explication of the reason to use it. With a good text editor (notepad no match) it's also clear and simple and help uncover some other view. No I don't use trunk for my configuration, I have my own parameters with my own method to deploy them :) Nicolas |
Administrator
|
Le 09/09/2014 13:26, Nicolas Malin a écrit : > Le 09/09/2014 12:41, Jacopo Cappellato a écrit : >> This is the main reason the trunk should be kept as clean as possible, instead of changing stuff to fit committers' personal preferences. > It's clear and good to simplify the configuration on production site. > > On some other projet (mostly on debian ;) ), configuration file contains few enable element but so mostly commented configurations with context > explication of the reason to use it. > With a good text editor (notepad no match) it's also clear and simple and help uncover some other view. > > No I don't use trunk for my configuration, I have my own parameters with my own method to deploy them :) > > Nicolas > That's a very interesting point Nicolas. The problem is now to know what means "as clean as possible" in Jacopo's sentence above Jacques |
And for whom
Verstuurd vanaf mijn iPad > Op 9 sep. 2014 om 14:23 heeft Jacques Le Roux <[hidden email]> het volgende geschreven: > > > Le 09/09/2014 13:26, Nicolas Malin a écrit : >> Le 09/09/2014 12:41, Jacopo Cappellato a écrit : >>> This is the main reason the trunk should be kept as clean as possible, instead of changing stuff to fit committers' personal preferences. >> It's clear and good to simplify the configuration on production site. >> >> On some other projet (mostly on debian ;) ), configuration file contains few enable element but so mostly commented configurations with context explication of the reason to use it. >> With a good text editor (notepad no match) it's also clear and simple and help uncover some other view. >> >> No I don't use trunk for my configuration, I have my own parameters with my own method to deploy them :) >> >> Nicolas >> > > That's a very interesting point Nicolas. The problem is now to know what means "as clean as possible" in Jacopo's sentence above > > Jacques |
Administrator
|
Since Jacopo did not answer, here is my proposition. We could, as suggested Nicolas, add some educational comments in log4j2.xml and add 2 commented
out sections for error.log Agreed? Jacques Le 09/09/2014 15:10, Pierre Smits a écrit : > And for whom > > Verstuurd vanaf mijn iPad > >> Op 9 sep. 2014 om 14:23 heeft Jacques Le Roux <[hidden email]> het volgende geschreven: >> >> >> Le 09/09/2014 13:26, Nicolas Malin a écrit : >>> Le 09/09/2014 12:41, Jacopo Cappellato a écrit : >>>> This is the main reason the trunk should be kept as clean as possible, instead of changing stuff to fit committers' personal preferences. >>> It's clear and good to simplify the configuration on production site. >>> >>> On some other projet (mostly on debian ;) ), configuration file contains few enable element but so mostly commented configurations with context explication of the reason to use it. >>> With a good text editor (notepad no match) it's also clear and simple and help uncover some other view. >>> >>> No I don't use trunk for my configuration, I have my own parameters with my own method to deploy them :) >>> >>> Nicolas >>> >> That's a very interesting point Nicolas. The problem is now to know what means "as clean as possible" in Jacopo's sentence above >> >> Jacques > |
On Sep 11, 2014, at 9:40 PM, Jacques Le Roux <[hidden email]> wrote:
> Since Jacopo did not answer, here is my proposition. Was there a question for me? I was hoping that this waste of time was finished > We could, as suggested Nicolas, add some educational comments in log4j2.xml and add 2 commented out sections for error.log > So, you are not happy until you mess up with the log4j2 config file? :-) Apart from you, Jacques, no one complained or asked for modifications to the config file (even after you asked for feedback). Jacopo > Agreed? > > Jacques > > Le 09/09/2014 15:10, Pierre Smits a écrit : >> And for whom >> >> Verstuurd vanaf mijn iPad >> >>> Op 9 sep. 2014 om 14:23 heeft Jacques Le Roux <[hidden email]> het volgende geschreven: >>> >>> >>> Le 09/09/2014 13:26, Nicolas Malin a écrit : >>>> Le 09/09/2014 12:41, Jacopo Cappellato a écrit : >>>>> This is the main reason the trunk should be kept as clean as possible, instead of changing stuff to fit committers' personal preferences. >>>> It's clear and good to simplify the configuration on production site. >>>> >>>> On some other projet (mostly on debian ;) ), configuration file contains few enable element but so mostly commented configurations with context explication of the reason to use it. >>>> With a good text editor (notepad no match) it's also clear and simple and help uncover some other view. >>>> >>>> No I don't use trunk for my configuration, I have my own parameters with my own method to deploy them :) >>>> >>>> Nicolas >>>> >>> That's a very interesting point Nicolas. The problem is now to know what means "as clean as possible" in Jacopo's sentence above >>> >>> Jacques >> |
In reply to this post by Jacques Le Roux
That, or otherwise improve the OFBiz documentation regarding logging.
Referring to documentation on other sites is not enough. Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Thu, Sep 11, 2014 at 9:40 PM, Jacques Le Roux < [hidden email]> wrote: > Since Jacopo did not answer, here is my proposition. We could, as > suggested Nicolas, add some educational comments in log4j2.xml and add 2 > commented out sections for error.log > > Agreed? > > Jacques > > Le 09/09/2014 15:10, Pierre Smits a écrit : > > And for whom >> >> Verstuurd vanaf mijn iPad >> >> Op 9 sep. 2014 om 14:23 heeft Jacques Le Roux < >>> [hidden email]> het volgende geschreven: >>> >>> >>> Le 09/09/2014 13:26, Nicolas Malin a écrit : >>> >>>> Le 09/09/2014 12:41, Jacopo Cappellato a écrit : >>>> >>>>> This is the main reason the trunk should be kept as clean as possible, >>>>> instead of changing stuff to fit committers' personal preferences. >>>>> >>>> It's clear and good to simplify the configuration on production site. >>>> >>>> On some other projet (mostly on debian ;) ), configuration file >>>> contains few enable element but so mostly commented configurations with >>>> context explication of the reason to use it. >>>> With a good text editor (notepad no match) it's also clear and simple >>>> and help uncover some other view. >>>> >>>> No I don't use trunk for my configuration, I have my own parameters >>>> with my own method to deploy them :) >>>> >>>> Nicolas >>>> >>>> That's a very interesting point Nicolas. The problem is now to know >>> what means "as clean as possible" in Jacopo's sentence above >>> >>> Jacques >>> >> >> |
On Sep 12, 2014, at 9:03 AM, Pierre Smits <[hidden email]> wrote:
> That, or otherwise improve the OFBiz documentation regarding logging. Yes, I like this option! Jacopo > Referring to documentation on other sites is not enough. > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com > > On Thu, Sep 11, 2014 at 9:40 PM, Jacques Le Roux < > [hidden email]> wrote: > >> Since Jacopo did not answer, here is my proposition. We could, as >> suggested Nicolas, add some educational comments in log4j2.xml and add 2 >> commented out sections for error.log >> >> Agreed? >> >> Jacques >> >> Le 09/09/2014 15:10, Pierre Smits a écrit : >> >> And for whom >>> >>> Verstuurd vanaf mijn iPad >>> >>> Op 9 sep. 2014 om 14:23 heeft Jacques Le Roux < >>>> [hidden email]> het volgende geschreven: >>>> >>>> >>>> Le 09/09/2014 13:26, Nicolas Malin a écrit : >>>> >>>>> Le 09/09/2014 12:41, Jacopo Cappellato a écrit : >>>>> >>>>>> This is the main reason the trunk should be kept as clean as possible, >>>>>> instead of changing stuff to fit committers' personal preferences. >>>>>> >>>>> It's clear and good to simplify the configuration on production site. >>>>> >>>>> On some other projet (mostly on debian ;) ), configuration file >>>>> contains few enable element but so mostly commented configurations with >>>>> context explication of the reason to use it. >>>>> With a good text editor (notepad no match) it's also clear and simple >>>>> and help uncover some other view. >>>>> >>>>> No I don't use trunk for my configuration, I have my own parameters >>>>> with my own method to deploy them :) >>>>> >>>>> Nicolas >>>>> >>>>> That's a very interesting point Nicolas. The problem is now to know >>>> what means "as clean as possible" in Jacopo's sentence above >>>> >>>> Jacques >>>> >>> >>> |
In reply to this post by Pierre Smits
But a JIRA issue of the improvement type with a patch might also do the
trick. Users can then decide whether they leave it as is, or implement the patch and have more insight. It helps the user. Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Fri, Sep 12, 2014 at 9:03 AM, Pierre Smits <[hidden email]> wrote: > That, or otherwise improve the OFBiz documentation regarding logging. > Referring to documentation on other sites is not enough. > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com > > On Thu, Sep 11, 2014 at 9:40 PM, Jacques Le Roux < > [hidden email]> wrote: > >> Since Jacopo did not answer, here is my proposition. We could, as >> suggested Nicolas, add some educational comments in log4j2.xml and add 2 >> commented out sections for error.log >> >> Agreed? >> >> Jacques >> >> Le 09/09/2014 15:10, Pierre Smits a écrit : >> >> And for whom >>> >>> Verstuurd vanaf mijn iPad >>> >>> Op 9 sep. 2014 om 14:23 heeft Jacques Le Roux < >>>> [hidden email]> het volgende geschreven: >>>> >>>> >>>> Le 09/09/2014 13:26, Nicolas Malin a écrit : >>>> >>>>> Le 09/09/2014 12:41, Jacopo Cappellato a écrit : >>>>> >>>>>> This is the main reason the trunk should be kept as clean as >>>>>> possible, instead of changing stuff to fit committers' personal preferences. >>>>>> >>>>> It's clear and good to simplify the configuration on production site. >>>>> >>>>> On some other projet (mostly on debian ;) ), configuration file >>>>> contains few enable element but so mostly commented configurations with >>>>> context explication of the reason to use it. >>>>> With a good text editor (notepad no match) it's also clear and simple >>>>> and help uncover some other view. >>>>> >>>>> No I don't use trunk for my configuration, I have my own parameters >>>>> with my own method to deploy them :) >>>>> >>>>> Nicolas >>>>> >>>>> That's a very interesting point Nicolas. The problem is now to know >>>> what means "as clean as possible" in Jacopo's sentence above >>>> >>>> Jacques >>>> >>> >>> > |
Administrator
|
In reply to this post by Pierre Smits
The point with embedded documentation (in OOTB files) is, as long as it's not in often changed files (where you have to be sure the documentation is
well maintained), you have it up to date at hand, without having to search online which might be not always available (like Git is now often preferred over svn for this reason) And morevoer I don't see why we would not update embedded documentation, it's as important as code, it's actually part of it. This reflects for instance in project evaluation like does https://www.openhub.net/p/Apache-OFBiz/factoids#FactoidCommentsLow But who cares anyway? :/ It seems nobody got the importance and value of error.log in the dev community, I really wonder about that! Jacques Le 12/09/2014 09:03, Pierre Smits a écrit : > That, or otherwise improve the OFBiz documentation regarding logging. > Referring to documentation on other sites is not enough. > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com > > On Thu, Sep 11, 2014 at 9:40 PM, Jacques Le Roux < > [hidden email]> wrote: > >> Since Jacopo did not answer, here is my proposition. We could, as >> suggested Nicolas, add some educational comments in log4j2.xml and add 2 >> commented out sections for error.log >> >> Agreed? >> >> Jacques >> >> Le 09/09/2014 15:10, Pierre Smits a écrit : >> >> And for whom >>> Verstuurd vanaf mijn iPad >>> >>> Op 9 sep. 2014 om 14:23 heeft Jacques Le Roux < >>>> [hidden email]> het volgende geschreven: >>>> >>>> >>>> Le 09/09/2014 13:26, Nicolas Malin a écrit : >>>> >>>>> Le 09/09/2014 12:41, Jacopo Cappellato a écrit : >>>>> >>>>>> This is the main reason the trunk should be kept as clean as possible, >>>>>> instead of changing stuff to fit committers' personal preferences. >>>>>> >>>>> It's clear and good to simplify the configuration on production site. >>>>> >>>>> On some other projet (mostly on debian ;) ), configuration file >>>>> contains few enable element but so mostly commented configurations with >>>>> context explication of the reason to use it. >>>>> With a good text editor (notepad no match) it's also clear and simple >>>>> and help uncover some other view. >>>>> >>>>> No I don't use trunk for my configuration, I have my own parameters >>>>> with my own method to deploy them :) >>>>> >>>>> Nicolas >>>>> >>>>> That's a very interesting point Nicolas. The problem is now to know >>>> what means "as clean as possible" in Jacopo's sentence above >>>> >>>> Jacques >>>> >>> |
Interesting observations in that openhub evaluation. Something to think
about! Didn't know it existed. How OFBiz is perceived by others should be part of the considerations regarding future roadmaps and (short term) plans. Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Fri, Sep 12, 2014 at 9:18 AM, Jacques Le Roux < [hidden email]> wrote: > The point with embedded documentation (in OOTB files) is, as long as it's > not in often changed files (where you have to be sure the documentation is > well maintained), you have it up to date at hand, without having to search > online which might be not always available (like Git is now often preferred > over svn for this reason) > > And morevoer I don't see why we would not update embedded documentation, > it's as important as code, it's actually part of it. This reflects for > instance in project evaluation like does https://www.openhub.net/p/ > Apache-OFBiz/factoids#FactoidCommentsLow > > But who cares anyway? :/ It seems nobody got the importance and value of > error.log in the dev community, I really wonder about that! > > Jacques > > Le 12/09/2014 09:03, Pierre Smits a écrit : > >> That, or otherwise improve the OFBiz documentation regarding logging. >> Referring to documentation on other sites is not enough. >> >> Pierre Smits >> >> *ORRTIZ.COM <http://www.orrtiz.com>* >> >> Services & Solutions for Cloud- >> Based Manufacturing, Professional >> Services and Retail & Trade >> http://www.orrtiz.com >> >> On Thu, Sep 11, 2014 at 9:40 PM, Jacques Le Roux < >> [hidden email]> wrote: >> >> Since Jacopo did not answer, here is my proposition. We could, as >>> suggested Nicolas, add some educational comments in log4j2.xml and add 2 >>> commented out sections for error.log >>> >>> Agreed? >>> >>> Jacques >>> >>> Le 09/09/2014 15:10, Pierre Smits a écrit : >>> >>> And for whom >>> >>>> Verstuurd vanaf mijn iPad >>>> >>>> Op 9 sep. 2014 om 14:23 heeft Jacques Le Roux < >>>> >>>>> [hidden email]> het volgende geschreven: >>>>> >>>>> >>>>> Le 09/09/2014 13:26, Nicolas Malin a écrit : >>>>> >>>>> Le 09/09/2014 12:41, Jacopo Cappellato a écrit : >>>>>> >>>>>> This is the main reason the trunk should be kept as clean as >>>>>>> possible, >>>>>>> instead of changing stuff to fit committers' personal preferences. >>>>>>> >>>>>>> It's clear and good to simplify the configuration on production >>>>>> site. >>>>>> >>>>>> On some other projet (mostly on debian ;) ), configuration file >>>>>> contains few enable element but so mostly commented configurations >>>>>> with >>>>>> context explication of the reason to use it. >>>>>> With a good text editor (notepad no match) it's also clear and simple >>>>>> and help uncover some other view. >>>>>> >>>>>> No I don't use trunk for my configuration, I have my own parameters >>>>>> with my own method to deploy them :) >>>>>> >>>>>> Nicolas >>>>>> >>>>>> That's a very interesting point Nicolas. The problem is now to know >>>>>> >>>>> what means "as clean as possible" in Jacopo's sentence above >>>>> >>>>> Jacques >>>>> >>>>> >>>> |
Administrator
|
Le 12/09/2014 09:25, Pierre Smits a écrit : > Interesting observations in that openhub evaluation. Something to think > about! Though it seems Openhub only refers to comments in Java, we have a lot of comments in XML It was just an example to explain why I'd like to follow Nicolas's suggestion and add explaining comments in log4j2.xml Jacques > > Didn't know it existed. How OFBiz is perceived by others should be part of > the considerations regarding future roadmaps and (short term) plans. > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com > > On Fri, Sep 12, 2014 at 9:18 AM, Jacques Le Roux < > [hidden email]> wrote: > >> The point with embedded documentation (in OOTB files) is, as long as it's >> not in often changed files (where you have to be sure the documentation is >> well maintained), you have it up to date at hand, without having to search >> online which might be not always available (like Git is now often preferred >> over svn for this reason) >> >> And morevoer I don't see why we would not update embedded documentation, >> it's as important as code, it's actually part of it. This reflects for >> instance in project evaluation like does https://www.openhub.net/p/ >> Apache-OFBiz/factoids#FactoidCommentsLow >> >> But who cares anyway? :/ It seems nobody got the importance and value of >> error.log in the dev community, I really wonder about that! >> >> Jacques >> >> Le 12/09/2014 09:03, Pierre Smits a écrit : >> >>> That, or otherwise improve the OFBiz documentation regarding logging. >>> Referring to documentation on other sites is not enough. >>> >>> Pierre Smits >>> >>> *ORRTIZ.COM <http://www.orrtiz.com>* >>> >>> Services & Solutions for Cloud- >>> Based Manufacturing, Professional >>> Services and Retail & Trade >>> http://www.orrtiz.com >>> >>> On Thu, Sep 11, 2014 at 9:40 PM, Jacques Le Roux < >>> [hidden email]> wrote: >>> >>> Since Jacopo did not answer, here is my proposition. We could, as >>>> suggested Nicolas, add some educational comments in log4j2.xml and add 2 >>>> commented out sections for error.log >>>> >>>> Agreed? >>>> >>>> Jacques >>>> >>>> Le 09/09/2014 15:10, Pierre Smits a écrit : >>>> >>>> And for whom >>>> >>>>> Verstuurd vanaf mijn iPad >>>>> >>>>> Op 9 sep. 2014 om 14:23 heeft Jacques Le Roux < >>>>> >>>>>> [hidden email]> het volgende geschreven: >>>>>> >>>>>> >>>>>> Le 09/09/2014 13:26, Nicolas Malin a écrit : >>>>>> >>>>>> Le 09/09/2014 12:41, Jacopo Cappellato a écrit : >>>>>>> This is the main reason the trunk should be kept as clean as >>>>>>>> possible, >>>>>>>> instead of changing stuff to fit committers' personal preferences. >>>>>>>> >>>>>>>> It's clear and good to simplify the configuration on production >>>>>>> site. >>>>>>> >>>>>>> On some other projet (mostly on debian ;) ), configuration file >>>>>>> contains few enable element but so mostly commented configurations >>>>>>> with >>>>>>> context explication of the reason to use it. >>>>>>> With a good text editor (notepad no match) it's also clear and simple >>>>>>> and help uncover some other view. >>>>>>> >>>>>>> No I don't use trunk for my configuration, I have my own parameters >>>>>>> with my own method to deploy them :) >>>>>>> >>>>>>> Nicolas >>>>>>> >>>>>>> That's a very interesting point Nicolas. The problem is now to know >>>>>>> >>>>>> what means "as clean as possible" in Jacopo's sentence above >>>>>> >>>>>> Jacques >>>>>> >>>>>> |
Administrator
|
In reply to this post by Jacopo Cappellato-3
Le 12/09/2014 06:17, Jacopo Cappellato a écrit : > On Sep 11, 2014, at 9:40 PM, Jacques Le Roux <[hidden email]> wrote: > >> Since Jacopo did not answer, here is my proposition. > Was there a question for me? I was hoping that this waste of time was finished > >> We could, as suggested Nicolas, add some educational comments in log4j2.xml and add 2 commented out sections for error.log >> > So, you are not happy until you mess up with the log4j2 config file? :-) Apart from you, Jacques, no one complained or asked for modifications to the config file (even after you asked for feedback). I could be wrong, but it seems to me Pierre and Nicolas expressed something about it I'm not asking to put back the error.log w/o good reasons and I already explained them If you want an example of its handy use, here is one. I want to monitor what's happening in the trunk demo. Because it's a an efficient mean, beside tests and reviews, to early spot new introduced errors. Of course I can got there and run zgrep, but it's much easier to simply monitor an error.log file. The same apply in custom project. Of course again, I can change the log4j2.xml there as I can schlep a patch in all places I would have to in future :/ I don't understand why you are so not open to put back the error.log in log4j2.xml and qualify this as a mess and almost myself and idiot. Could you explain your reasons please? For the other part (comments), I explained why I prefer to have comments in files over having an online documentation, ever if of course having both is not bad (as long as the online doc is updated). Jacques > Jacopo > >> Agreed? >> >> Jacques >> >> Le 09/09/2014 15:10, Pierre Smits a écrit : >>> And for whom >>> >>> Verstuurd vanaf mijn iPad >>> >>>> Op 9 sep. 2014 om 14:23 heeft Jacques Le Roux <[hidden email]> het volgende geschreven: >>>> >>>> >>>> Le 09/09/2014 13:26, Nicolas Malin a écrit : >>>>> Le 09/09/2014 12:41, Jacopo Cappellato a écrit : >>>>>> This is the main reason the trunk should be kept as clean as possible, instead of changing stuff to fit committers' personal preferences. >>>>> It's clear and good to simplify the configuration on production site. >>>>> >>>>> On some other projet (mostly on debian ;) ), configuration file contains few enable element but so mostly commented configurations with context explication of the reason to use it. >>>>> With a good text editor (notepad no match) it's also clear and simple and help uncover some other view. >>>>> >>>>> No I don't use trunk for my configuration, I have my own parameters with my own method to deploy them :) >>>>> >>>>> Nicolas >>>>> >>>> That's a very interesting point Nicolas. The problem is now to know what means "as clean as possible" in Jacopo's sentence above >>>> >>>> Jacques > > |
On Sep 12, 2014, at 10:35 AM, Jacques Le Roux <[hidden email]> wrote:
> I don't understand why you are so not open to put back the error.log in log4j2.xml Because it is just one of 1 million possible ways to configure logging: it is a specific one on not a generic one and so it is not better than the other 1 million possibilities; you have explained why you like it but me or others could find similar arguments for the other millions ways; since no one seconded you in your attempt to add the configuration back this confirms to me that this specific configuration is not better than other; for this reason it should be left out of the trunk. > and qualify this as a mess and almost myself and idiot. I didn't say this and the mail archive can demonstrate it; you have been trying to raise the tone of the conversation since the beginning of this thread (and you did the same in at least another thread recently) but I will not start to fight with you. Jacopo |
I support reverting this regression.
Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Fri, Sep 12, 2014 at 11:29 AM, Jacopo Cappellato < [hidden email]> wrote: > On Sep 12, 2014, at 10:35 AM, Jacques Le Roux < > [hidden email]> wrote: > > > I don't understand why you are so not open to put back the error.log in > log4j2.xml > > Because it is just one of 1 million possible ways to configure logging: it > is a specific one on not a generic one and so it is not better than the > other 1 million possibilities; you have explained why you like it but me or > others could find similar arguments for the other millions ways; since no > one seconded you in your attempt to add the configuration back this > confirms to me that this specific configuration is not better than other; > for this reason it should be left out of the trunk. > > > and qualify this as a mess and almost myself and idiot. > > I didn't say this and the mail archive can demonstrate it; you have been > trying to raise the tone of the conversation since the beginning of this > thread (and you did the same in at least another thread recently) but I > will not start to fight with you. > > Jacopo > > |
Administrator
|
In reply to this post by Jacopo Cappellato-3
Le 12/09/2014 11:29, Jacopo Cappellato a écrit : >> and qualify this as a mess and almost myself and idiot. > I didn't say this and the mail archive can demonstrate it; you have been trying to raise the tone of the conversation since the beginning of this thread (and you did the same in at least another thread recently) but I will not start to fight with you. You said a mess for sure (several times). The error.log was there before. I call that a regression, we have not clearly discussed its removing before you did :/ What if one of my processes was based on it? Jacques > > Jacopo > > > |
ok, if you want, call a vote
Jacopo On Sep 12, 2014, at 11:44 AM, Jacques Le Roux <[hidden email]> wrote: > > Le 12/09/2014 11:29, Jacopo Cappellato a écrit : >>> and qualify this as a mess and almost myself and idiot. >> I didn't say this and the mail archive can demonstrate it; you have been trying to raise the tone of the conversation since the beginning of this thread (and you did the same in at least another thread recently) but I will not start to fight with you. > > You said a mess for sure (several times). The error.log was there before. I call that a regression, we have not clearly discussed its removing before you did :/ What if one of my processes was based on it? > > Jacques > >> >> Jacopo >> >> >> |
If consensus can't be reached between the two of you, then a vote amongst
the community members would surely help find the direction we should follow. Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Fri, Sep 12, 2014 at 11:46 AM, Jacopo Cappellato < [hidden email]> wrote: > ok, if you want, call a vote > > Jacopo > > On Sep 12, 2014, at 11:44 AM, Jacques Le Roux < > [hidden email]> wrote: > > > > > Le 12/09/2014 11:29, Jacopo Cappellato a écrit : > >>> and qualify this as a mess and almost myself and idiot. > >> I didn't say this and the mail archive can demonstrate it; you have > been trying to raise the tone of the conversation since the beginning of > this thread (and you did the same in at least another thread recently) but > I will not start to fight with you. > > > > You said a mess for sure (several times). The error.log was there > before. I call that a regression, we have not clearly discussed its > removing before you did :/ What if one of my processes was based on it? > > > > Jacques > > > >> > >> Jacopo > >> > >> > >> > > |
Free forum by Nabble | Edit this page |