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
