Hi all, Thanks for the feedback!
I've created a Gdoc with what we discussed [1]. I'd like to propose that all committers create PRs for major features they are doing and some other committer review and merge them. But small bug fixes and minor features can be merged directly. wdyt? @Lakmal: Let's create the Wiki page based on this Gdoc once we finalize this. Shall we include this Wiki page when we send the welcome email to new committers and ask them to acknowledge once they have read and understood it? [1] https://docs.google.com/document/d/1Q-_NItAGTKArnumEMmW5GWBoPieRC5d89RI7hyxQW4o/edit?usp=sharing Thanks. On Fri, Sep 11, 2015 at 1:07 PM, Sajith Kariyawasam <saj...@wso2.com> wrote: > Great tips Akila! > > I would like to include 'running sonar' before committing the code. > > +1 for adding these to wiki. > > On Fri, Sep 11, 2015 at 12:37 PM, Isuru Perera <is...@apache.org> wrote: > >> Hi Akila, >> >> These are good tips! I have seen many build unstable mails recently (I >> didn't go through each of those). It's always better to avoid build breaks. >> >> +1 for adding these tips to wiki. >> >> Thanks! >> >> Best Regards, >> >> On Fri, Sep 11, 2015 at 10:46 AM, Lakmal Warusawithana <lak...@wso2.com> >> wrote: >> >>> Hi Akila, >>> >>> Shall we add these into our wiki? >>> >>> thanks >>> >>> On Fri, Sep 11, 2015 at 2:59 AM, Akila Ravihansa Perera < >>> raviha...@wso2.com> wrote: >>> >>>> Hi Devs, >>>> >>>> Thought of sharing this since we have some new committers. These are >>>> some guidelines that I think we can adopt in Stratos project. This is only >>>> my personal view, and open to discussion :) >>>> >>>> 1. Always create a branch in your fork when developing a feature or >>>> fixing a bug. We tend to forget this or even deliberately ignore it because >>>> we might think that the fix being done is not worth it. But Git was made >>>> for branching and merging is very cheap. This will avoid many merge >>>> conflicts. Once you are done-done with your task, merge it back to master. >>>> >>>> 2. Know when to use Git rebasing and merging >>>> If you continuously rebase your commits, then the chronological order >>>> of commits will be lost. Meaning that it is very hard to trace a bug by >>>> going through Git history. If you want to know why then read this great >>>> article [1]. >>>> >>>> On the other hand if you continue to use Git merging for even simple >>>> changes, then it will clutter the Git history with lots of ugly merge >>>> commits. Always keep an eye on commit log [2] and try to keep it clean. >>>> This is another good article about rebasing vs merging [3]. >>>> >>>> 3. Incomplete features on the Master Branch >>>> Master branch is not your playground :) Only well tested and complete >>>> features should be merged to master branch. You can continue to work on new >>>> features in your own branch of your personal fork. If someone needs to try >>>> out the latest feature that you are working on then he/she can "pull" from >>>> your "personal" fork, not from our main repo. I don't see any reason why we >>>> should maintain separate branches for new features. If multiple people are >>>> working on a new feature then those people can pull/push from/to each >>>> others' personal forks. Once everything is done-done, that can be merged >>>> back to master. >>>> >>>> 4. No broken builds on the master branch, ever >>>> Please make sure you run a complete maven build "with tests" before you >>>> push major changes to upstream repo. Yes it takes time and resources but >>>> build breaks can negatively affect everyone. If you break the build, others >>>> won't be able to continue with their work and in most cases only you would >>>> know where/how to debug and properly fix it. Mistakes can happen, but if >>>> you happen to build the break please fix it ASAP or temporary revert the >>>> commit until it is resolved. >>>> >>>> Tip: keep a separate VM on the cloud to run complete builds against >>>> your personal branches. There are lots of free cloud offering these days. >>>> >>>> 5. All new features or major changes should be tracked in JIRA >>>> Please put adequate information when you create JIRAs. Also put the >>>> commit ID, fix version(s) in the JIRA when you resolve them. >>>> >>>> >>>> [1] >>>> http://geekblog.oneandoneis2.org/index.php/2013/04/30/please-stay-away-from-rebase >>>> [2] https://github.com/apache/stratos/commits/stratos-4.1.x >>>> [3] >>>> https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase/ >>>> >>>> Please share your thoughts. >>>> >>>> Thanks. >>>> -- >>>> Akila Ravihansa Perera >>>> WSO2 Inc.; http://wso2.com/ >>>> >>>> Blog: http://ravihansa3000.blogspot.com >>>> >>> >>> >>> >>> -- >>> Lakmal Warusawithana >>> Vice President, Apache Stratos >>> Director - Cloud Architecture; WSO2 Inc. >>> Mobile : +94714289692 >>> Blog : http://lakmalsview.blogspot.com/ >>> >>> >> >> >> -- >> Isuru Perera >> Associate Technical Lead | WSO2, Inc. | http://wso2.com/ >> Lean . Enterprise . Middleware >> >> about.me/chrishantha >> > > > > -- > Sajith Kariyawasam > *Committer and PMC member, Apache Stratos, * > *WSO2 Inc.; http://wso2.com <http://wso2.com>* > *Mobile: 0772269575* > -- Akila Ravihansa Perera WSO2 Inc.; http://wso2.com/ Blog: http://ravihansa3000.blogspot.com
