Hi all, as far as I know, PMCs have the carma to create repos.
And sure ... happy to do a rough plan before starting to write code. As long as it's not like writing a RFC document. If you or someone here could setup a root document, we could start writing and drawing. Chris On 01.07.21 17:23, Ralph Goers wrote: > Davyd, > > You have commit rights but I am not sure if that gives you the ability to > create a new repo. But before doing that I would create a confluence page to > lay out the initial requirements and design. > > If you can’t create a repo and would like one I can certainly help with that. > > Ralph > >> On Jun 30, 2021, at 12:44 PM, Davyd McColl <dav...@gmail.com> wrote: >> >> I'm rather new to go, but looking for ways to improve by writing code >> alongside people who actually know what they're doing. If I can help, please >> ping me. >> >> -d >> >> >> On June 30, 2021 18:12:46 Christofer Dutz <cd...@apache.org> wrote: >> >>> Hi all, >>> >>> and sorry for being late to the party ;-) >>> >>> I am currently working hard on PLC4X' Go support and am also using what I >>> create in the Open-Source project in some larger corporate applications. >>> >>> One thing that has always bugged me with go, was the inavailability of >>> loggers that allow me to set different log levels for different parts of >>> the application. In go with every half-efficient logging framework, it's an >>> all or nothing thing. So if I want to track down a problem in my driver for >>> protocol X and I switch logging to TRACE it's like trying to drink out of >>> an open fire-hose. >>> >>> What I would love to do as a first step, and I don't think it should be too >>> complicated, would be to create a Go API that allows us to define >>> hierarchies of log levels, just like we know them in the Java world. This >>> API would be used in the application to log, but it wouldn't actually do >>> any logging but internally sort of use an underlying framework (possibly >>> auto configured to TRACE or the most talkative log level) and forward log >>> requests to that if it passes the filter criteria. >>> >>> So in PLC4Go for example we could use this Go Logging API. If my company >>> now uses logrus or zerolog, then all we have to do in that application is >>> initialize the log4go system (I know there's a project using that name >>> pattern ... I'm referring to something we built) with the corresponding >>> adapter. >>> >>> What do you think? I'm not one of these "I whish someone would build X for >>> me" folks ... I am willing to put quite some effort into something like >>> this. But I think it should be in a project like Apache Logging and not as >>> a side project of PLC4X. >>> >>> Chris >>> >>> >>> On 2020/12/11 12:20:18 Volkan Yazıcı wrote: >>>> I support the initiative. At bol.com, we also needed to implement our own >>>> Go logging layouts (JSON) and appenders (Redis). That said, I don't know Go >>>> and I don't think I will be able to spare time to both learn a new language >>>> (even though I am really into learning Go) and maintain such a project. I >>>> mean, not that you need my help, but just wanted to share my availability. >>>> If I would have time, I would rather clean up Log4j bugs piled up in JIRA. >>>> I also agree with Matt that this would pave the road to standardizing the >>>> logging configuration file formats across multiple languages. >>>> What I witness most for code — in particular libraries, APIs, etc. — >>>> written by programmers whose expertise is actually in another language, >>>> that they mostly don't get the language conventions right. For instance, I >>>> was horrified many times in the past to read/use Java code written by >>>> JavaScript (front-end) developers. These two languages have totally >>>> different approaches and (community embraced) conventions that one cannot >>>> plug-n-play the mindset of one to another. In conclusion, as far as I know, >>>> none of us is programming in Go on a daily basis. Hence, I strongly >>>> recommend consulting to experts in this domain before publishing something >>>> to the outside world. For one, I am pretty sure there should be Go experts >>>> within the Apache community, hence having expert reviews should be >>>> relatively easy. Second, Apache has such a good track record in delivering >>>> high quality software, even an inferior project might get quite some >>>> attraction and we will be bound to maintain it for years. These are my >>>> concerns in general. That said, I would be more than happy to ditch off our >>>> custom Go loggers with an Apache-approved alternative. >>>> On Wed, Dec 9, 2020 at 10:29 PM Ralph Goers <ralph.go...@dslextreme.com> >>>> wrote: >>>>> The company I work for has started using Go for some of the middleware >>>>> components we are developing. I have looked at several logging frameworks >>>>> for Go and have not been impressed by any of them. As such, I am >>>>> considering starting a project here. The major goals of this would be: >>>>> >>>>> Use an external configuration (at least JSON and XML). >>>>> Allow the configuration to be accessed via HTTP(S) - Spring Cloud >>>>> Configuration. >>>>> Allow dynamic reconfiguration. >>>>> Allow plugins (probably as Go plugins?) >>>>> Support for Markers, context attributes, Layouts, Appenders. >>>>> >>>>> Anyone interested? >>>>> >>>>> Ralph >>>>> >>>>> > >
