ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre Smits <pierre.sm...@gmail.com>
Subject Re: OFBiz specific rules on lazy consensus [was Re: [VOTE] Put the Flatgrey theme in Attic]
Date Sun, 25 Sep 2016 09:02:51 GMT
Everyone participating can be blamed for complaints, or needlessly
prolonging discussions. Some want to discuss everything, Some blame the
other contributor.

Does the blame game help the project? Instead of pointing out the 'flaw' in
other, it is better to apply some introspection first wit respect to one
own contributions and that helps the project forward.

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace

On Sun, Sep 25, 2016 at 10:53 AM, Taher Alkhateeb <
slidingfilaments@gmail.com> wrote:

> I find it exhausting that I cannot focus on coding in OFBiz because of the
> "machine-gun" like activities, many of which are triggered by Jacques. I am
> spending more and more time trying to limit code getting into the framework
> than actually doing critical things like refactoring and improving the code
> base.
> Quality wins over quantity hands-down. We need to focus on quality, we need
> to focus our limited resources and efforts on fewer but more critical
> issues. It is really tiring to engage in these threads that go on
> indefinitely many of which I find not that important anyway. For example:
> - There were some long, long discussions on whether or not to add Gradle
> shortcut tasks. These tasks are minor and not that important in the first
> place. Why bloat the code early, this can always be visited once we finish
> more critical work.
> - We had discussions on "Style guides" when we have some very bad code that
> needs to be cleaned first. Does it really matter if I say if(x==y) or if
> (x==y) when the bigger issues are unresolved like hidden mutable shared
> state, no interfaces, poor design, poor documentation, faulty logic, and
> spaghetti code. Before focusing on style and spending a lot of energy
> there, let's look at the much much bigger problem of poor quality and badly
> designed code. (REF http://markmail.org/message/cpqfhxn6fnu5zuu7)
> - There was another long discussion for example on semi colons in Groovy
> scripts. Again, is that the most important thing right now? I can see much
> bigger problems in our groovy scripts than that. (REF
> http://markmail.org/message/rabzquyotw3gf3vx)
> - We had a long discussion on whether to make binary releases when we
> didn't even release! (REF http://markmail.org/message/7up63poazemvgha2)
> - The themes discussion is not that important, it is more important to
> focus on the underlying technology. We have major problems in the way
> themes are designed, web assets are fragmented between framework, apps and
> themes, there is a lot of duplication, the widget system is not pure and
> mixed with a lot of templates. These problems are more pressing and if
> resolved, makes the themes a smaller problem. (REF
> https://issues.apache.org/jira/browse/OFBIZ-8293
> So I think the philosophy (Less is More) is very relevant in here. We need
> less long exhausting threads and more focus on critical technical areas to
> help improve the fundamentals of our project.
> On Sun, Sep 25, 2016 at 11:35 AM, Paul Piper <pp@ilscipio.com> wrote:
> > Aren't these meant to be private discussions between you guys (perhaps
> > within
> > the PMC ml)?
> >
> > I don't understand how Jacques' activity level has anything to do with
> the
> > topic discussed here, or on this thread
> > (http://ofbiz.135035.n4.nabble.com/Wiki-page-for-the-
> > monthly-Jira-issues-list-creation-in-the-blog-tp4694738p4695235.html).
> >
> > Oh and -1 on flatgrey as it is one of the few themes that aren't broken
> > within stock ofbiz.
> >
> >
> >
> > --
> > View this message in context: http://ofbiz.135035.n4.nabble.
> > com/VOTE-Put-the-Flatgrey-theme-in-Attic-tp4695129p4695240.html
> > Sent from the OFBiz - Dev mailing list archive at Nabble.com.
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message