On Fri, Sep 11, 2015 at 2:02 PM, Akila Ravihansa Perera <raviha...@wso2.com> wrote:
> 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 > [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 > -- Lakmal Warusawithana Vice President, Apache Stratos Director - Cloud Architecture; WSO2 Inc. Mobile : +94714289692 Blog : http://lakmalsview.blogspot.com/
