Looks good Michael. Thanks & Regards -- Deepak Dixit
On Fri, Jan 25, 2019 at 1:54 PM Michael Brohl <michael.br...@ecomify.de> wrote: > Hi everyone, > > thank you all for your feedback. It seems that we have consensus to > switch over to Git. > > I'll prepare a Wiki page to start documentation on the processes and the > needed steps to make the switch. I'll take over the topics mentioned in > this thread (Taher's initial proposed workflow, Jacques notes about > build scripts, auto-props etc.). > > We should then finish the process description, maybe discuss and decide > upon and then plan the technical switch. > > Makes sense? > > Best regards, > > Michael > > > > Am 23.01.19 um 07:37 schrieb Jacopo Cappellato: > > +1 for Git! > > > > Jacopo > > > > On Sat, Jan 12, 2019 at 1:01 PM Michael Brohl <michael.br...@ecomify.de> > > wrote: > > > >> Hi all, > >> > >> I'd like to revive this discussion again. > >> > >> Personally, I am now working with git for a few years and almost all > >> customer and company related projects have moved to git over time. In > >> the beginning, I found git complicated and less straight forward, a bit > >> like Adrian mentioned in [1]. But once I have understood the main > >> principles and get used to it, I won't like to switch back to svn ever > >> since. > >> > >> In my opinion, using git would make things much easier for > >> collaboration. Taher thoroughly described them in the inital thread > >> message. > >> > >> An important point for me would be that we could prevent premature > >> commits just to get things to be tested. Features which take some time > >> to be worked on or tested can be in separate branches which can be > >> updated with the main branch constantly. > >> > >> So, from my point of view, we should again have a disussion and/or vote > >> to see if the overall opinions have changed and if we could move to git. > >> > >> Thanks, > >> > >> Michael > >> > >> > >> [1] http://markmail.org/message/m4z5b5qevqx7n6u7 > >> > >> Am 24.10.15 um 10:23 schrieb Taher Alkhateeb: > >>> Hello Everyone, > >>> > >>> I refer to the discussion about moving to git initiated by Hans Bakker > >> back in April. After a long, long discussion followed by a vote the > >> community agreed that we should develop a more elaborate and formal > >> workflow to vote on, as the initial vote was not detailed enough. Based > on > >> that, I have proposed a workflow to see if people are interested in it. > But > >> the topic just slowly died out. > >>> The links to both threads are listed below. I understand that there was > >> a lot of interest in the community as the thread was really long. I > would > >> like to revive the discussion and see if people are still interested in > >> implementing / amending the proposed workflow if they find it appealing. > >>> discussion and vote thread : > >> > http://ofbiz.markmail.org/message/ldo77qz34kte4gat?q=move+to+git+from:%22Hans+Bakker%22+list:org.apache.ofbiz.dev&page=1 > >>> workflow proposition thread : > >> > http://ofbiz.markmail.org/message/nkthnbsgt37orynu?q=git+commit+workflow > >>> Taher Alkhateeb > >>> ----- Original Message ----- > >>> > >>> From: "Taher Alkhateeb" <slidingfilame...@gmail.com> > >>> To: dev@ofbiz.apache.org > >>> Sent: Wednesday, 24 June, 2015 5:25:31 PM > >>> Subject: Re: git commit workflow for ofbiz > >>> > >>> > >>> Hi Jacques, > >>> > >>> Very good read, thank you for sharing. > >>> > >>> The person who wrote complaining about gitflow (I think Adam Ruka) > makes > >> a good point. He prefers linear to branched history. I do not mind > branched > >> history myself as I know how to navigate it but to each his own. Either > >> way, The workflow can be accomplished the way he suggested by rebasing > >> rather than merging the history and making a few other changes like > >> dropping "develop". It is up to community to decide, and git is flexible > >> enough to accommodate any model. > >>> Taher Alkhateeb > >>> > >>> ----- Original Message ----- > >>> > >>> From: "Jacques Le Roux" <jacques.le.r...@les7arts.com> > >>> To: dev@ofbiz.apache.org > >>> Sent: Wednesday, 24 June, 2015 4:19:42 PM > >>> Subject: Re: git commit workflow for ofbiz > >>> > >>> Le 24/06/2015 14:06, Jacques Le Roux a écrit : > >>>> If you get a chance to read these articles I highly recommend them > >>>> > >>>> > >> > http://www.alwaysagileconsulting.com/organisation-pattern-trunk-based-development/ > >>> Of course don't miss > >> > http://www.alwaysagileconsulting.com/organisation-antipattern-release-feature-branching/ > >>> Jacques > >>> > >>>> http://endoflineblog.com/gitflow-considered-harmful > >>>> http://endoflineblog.com/follow-up-to-gitflow-considered-harmful > >>>> > >>>> Jacques > >>>> > >>>> > >>>> Le 12/05/2015 19:28, Adam Heath a écrit : > >>>>> Nice. This is quite thorough. There is an option missing. SVN > >> committers who use git offline. In this case, their changes can be > >> published as > >>>>> primary SVN branches, for collaboration.. See OFBIZ-6271 in JIRA, and > >> as an SVN branch, for an example. > >>>>> I've read through most of what follows, and am in agreement, but I'm > >> dealing with hardware problems, so I need to let it sink in first. > >>>>> On 05/12/2015 04:43 AM, Taher Alkhateeb wrote: > >>>>>> Hi everyone, > >>>>>> > >>>>>> This email refers to the thread for voting to move to git (link at > >> bottom) in which the vote decision was to delay and elaborate on the > >> workflow > >>>>>> first. I am not well versed in ASF guidelines and appreciate any > help > >> and feedback and also please note some of the below is my opinion and > not > >>>>>> necessarily 100% factual. > >>>>>> > >>>>>> ## First, identified problems > >>>>>> > >>>>>> 1. patches can quickly be outdated if not applied quickly > >>>>>> 2. big patches are hard to audit and not desired nor preferred and > It > >> is hard to break big patches to smaller ones because if any of those > patches > >>>>>> is outdated or modified then everything needs to be re-patched > >>>>>> 3. to collaborate with other people (non-committers) freely on big > >> features, we need a separate branch. On svn this is lengthy and heavily > >>>>>> controlled. If we create a git repository then we need to constantly > >> update from svn and merge . Another solution is to clone the ofbiz > read-only > >>>>>> git repository but then there are some patch issues to convert them > >> to clean svn patches (I faced a few including things like white space) > >>>>>> 4. a lot of _local_ offline freedom to branch, merge, commit, share > >> and experiment cannot be easily done without initiating a local git > >> repository > >>>>>> which triggers the other problems identified above. > >>>>>> 6. There are too many public branches in the repositoy. Some are not > >> active nor complete and quite old > >>>>>> ## Second, how does git provide solutions > >>>>>> > >>>>>> So, adopting git in relation to the above mentioned problems solves > >> them as follows: > >>>>>> 1. even if a patch gets outdated, I can easily recreate it by > >> switching to a branch that I created and has the work (e.g. > OFBIZ-12345), > >> merging > >>>>>> everything from trunk and re-patching > >>>>>> 2. to allow for proper feedback by community, a pull request can > >> replace a big patch and that request can hold an X amount of commits > each > >> with > >>>>>> its own message and diff details. If changes happen to any of the > >> commits, then reconciling that into the code base is minor, you just > branch > >>>>>> again, do it, and merge. Furthermore, I suggest to follow the > >> guidelines which recommend rebasing before pushing to a shared > repository > >> to keep a > >>>>>> nice linear history as much as possible as shown here -> > >> https://git-wip-us.apache.org/docs/committer-practices.html > >>>>>> 3. large features can be done in a remote repository in github or > >> bitbucket with pull requests when complete and ready for review. > >>>>>> 4. the issue is immediately solved with git which is not only local > >> but much, much faster > >>>>>> 6. We do not need to pollute the main repository with branches if we > >> decide on a distributed model like git with remote repositories to > >> contribute > >>>>>> to the project with pull requests. > >>>>>> > >>>>>> ## Third, proposed workflow > >>>>>> > >>>>>> I will make a distinction between small features / bug fixes and > >> large features. > >>>>>> ### small features > >>>>>> > >>>>>> Small features follow the exact same workflow that currently exists > >> in svn. You do your work, diff it, and attach the patch to a JIRA and > >> request > >>>>>> a commit from one of the committers. > >>>>>> > >>>>>> ### large features > >>>>>> > >>>>>> For large features usually multiple people need to collaborate on a > >> separate branch. Here is where git shines and the distributed model > kicks > >> in: > >>>>>> 1. A JIRA is created for a large feature > >>>>>> 2. The team (not necessarily having a committer) creates a remote > >> repository which itself may have many branches with the master branch > >> having all > >>>>>> the work agreed upon and merged (actually, rebased) > >>>>>> 3. The collaboration for this branch happens in the JIRA including > >> discussions, comments, and even links to the commits etc ... > >>>>>> 4. A request is made to a committer to make a pull request from the > >> repository after reaching a certain milestone with consensus from the > >>>>>> community of course > >>>>>> 5. Here, for extra safety, the branch model may have a trunk and a > >> develop branches. Everything is pulled to the develop branch and > trickles > >> down > >>>>>> to the master branch after thorough and proper testing. > >>>>>> > >>>>>> The above workflow can also adhere to the now famous Vincent > Driessen > >> git branching model found here -> > >>>>>> http://nvie.com/posts/a-successful-git-branching-model/ > >>>>>> > >>>>>> I am not sure whether this proposal is enough or correct so I > >> appreciate your guidance and feedback to fix whatever needs fixing. > >>>>>> Taher Alkhateeb > >>>>>> > >>>>>> original voting thread: > >>>>>> > >> > http://ofbiz.markmail.org/search/?q=move%20to%20git#query:move%20to%20git+page:1+mid:p62ofojcbb3oyoi4+state:results > >>> > >> > >
