Hello Jacques, Jacques Le Roux <jacques.le.r...@les7arts.com> 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
