The remark about 'not acceptable when working within a community' reminds me of the the joke about 'How many community members does it take to get four wheel nuts loosened'. It takes 4: 1 loosening the nuts and 3 others discussing....
JFDI (putting on the earplugs, and doing it) is part of the Apache Way. It applies to contributing code changes and to people having the need to discuss stuff. But in this project some need to have discussions on everything. In tickets with statements like 'we should discuss this' or in specific threads on a side tracking remark, without taking that 'need' forward to a new thread (maybe hoping the other community member does that). Some have even brought forward that issues (whether they be bugs or improvements) need to be discussed before they are registered as issues. A result of this side-tracking (bike shedding??) of JFDI, is not going for accepting 'good enough' in many cases and an almost unclimbable mountain of open tickets. That is not the way to go in an Apache project, as it alienates contributors (leading to drastic measures taken - as seen again recently). Going down that road - all/most of the time - is not beneficial to the project, as seems to bring moving forward to a halt. Paraphrasing Alec Steele here: at a certain moment in time it is time to stop yacking and start whacking. Met vriendelijke groet, Pierre Smits *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since 2008 (without privileges) *Apache Trafodion <https://trafodion.apache.org>, Vice President* *Apache Directory <https://directory.apache.org>, PMC Member* Apache Incubator <https://incubator.apache.org>, committer Apache Steve <https://steve.apache.org>, committer On Wed, Mar 11, 2020 at 12:33 PM Mathieu Lirzin <[email protected]> wrote: > Hello Jacques, > > Jacques Le Roux <[email protected]> writes: > > > If my opinion is worth telling, I was initially reluctant to use the > > PR process instead of the patch process. Because in general I prefer > > to control things, it's even sometimes a problem for me in real > > life. I must say it was more laziness which inclined me to PR. > > Your opinion is always worth telling on this topic since to my knowledge > you are the most active reviewer which really valuable. > > > Like Michael I had a look about the settings. The settings button is > > available on my fork but not on the official mirror Github repo. > > Thanks for double checking. > > >> This said you certainly saw this thread started by Pierre Smits: > > https://markmail.org/message/so7ljoqxzuq7jplz and the related wiki > > document > > > https://cwiki.apache.org/confluence/display/OFBIZ/Contributing+via+Git+and+Github > > AIUI this page is only collection of Git/Github tips and fuzzy > "maybe"/"you can" rules. Moreover it does not propose to > replace/deprecate/simplify existing contribution procedures/tools. > > So it misses the point that adopting Github workflow only makes sense if > it simplifies the contribution process for both contributors and > reviewers. > > > The discussion ended with Michael's disagreement, as somehow yours, > > but nothing happened. So I think we should move ahead with your > > proposition and note the change in the wiki page. I have created > > https://issues.apache.org/jira/browse/INFRA-19950 for that. If > > somebody disagrees please speak now, even if it will always possible > > to revert the change. > > > > We have also to maintain the related stuff which are also still WIP: > > > > > https://cwiki.apache.org/confluence/display/OFBIZ/Migration+from+Subversion+%28SVN%29+to+Git > > https://issues.apache.org/jira/browse/OFBIZ-11268 > > > > Nothing happens magically, but it seems we are near the end about the > > migration from Subversion to Git process. > > Yes things seems to happen not magically but by putting earplugs on and > going ahead, which is certainly more effective but IMO not acceptable > when working within a community. > > > BTW, a question for you: do you think not having a linear commit > > history would have an impact on Bisect. I don't think so, just asking > > in case you have an experience with that. > > ‘git bisect’ handles non-linear history nicely but it achieves this with > a more complex algorithm than basic binary search [1][2]. > > The difficulty is when a commit identified as introducing the regression > is a merge commit because it requires analysing each branch up to their > common ancestor. > > The major issue is more social, because once people adopts the practice > of merging branches without rebasing and cleaning that branch first, > since contributors often branch from another development branch, this > will eventually lead to have the same commit present multiple times but > with different hashes. > > The simple solution to prevent this is to get into the habit of > linearizing history, meaning always rebasing and clean history before > merging into trunk. > > > Please don't be angry, it's not good for health. Just listen few > > minutes to https://www.youtube.com/watch?v=d-diB65scQU it generally > > helps ;) > > :-) > > [1] > https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html#_git_bisect_details > [2] https://www.wikipedia.org/wiki/Binary_search_algorithm > > -- > Mathieu Lirzin > GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37 >
