I guess one thing to remember here is that we have a dedicated quality assurance team. As a developer it makd s sense to have a fast dev cycle As a PM it makes sense to have quality release As a qa person it makes sense to be thd last person to signoff before a package is declared golden As a customer any bug that passes through devel to golden untested is a big failure on ACs part So We need to think not only in terms of developers being able to come up with quick changes but qa also being able to test them. Those processes need to bw delinked as much as possoble so they dont block on each other unnecessarily Also I dont buy the argument that incentivizing developers to test more is going to solve our testing requirements. There is a reason companies invest in q.a. developers test pieces of code. Q.a. tests the functionality and its correctness. That is ultimately what is most important to the customer. Just my 2c <div class="gmail_quote">On Oct 11, 2012 9:40 AM, "Ajay Garg" <<a href="mailto:ajay@activitycentral.com">ajay@activitycentral.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="gmail_quote">On Thu, Oct 11, 2012 at 6:54 PM, Ruben Rodríguez <<a href="mailto:ruben@activitycentral.com" target="_blank">ruben@activitycentral.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 2012/10/11 Ajay Garg <<a href="mailto:ajay@activitycentral.com" target="_blank">ajay@activitycentral.com</a>>: <div>> Having so many branches is an overkill; it is too efforts-intensive, > error-prone and generally daunting. </div>It may be a bigger effort when you compare it with how we work now, but there are good reasons for that scheme: * A lot more provision against failure. Think of what would happen if we ever push a rpm update that unexpectedly makes the machines stop to boot or causes some other big trouble. I've seen that happen in several distros, and it is a project killer. At least we need to separate what code is golden, what is being tested by the QA team and what is fresh from the coders. </blockquote><div> Well, I think the onus lies on the developer then, since he/she was responsible for committing a fix that caused the catastrophe. Moreover, I think this is a blessing in disguise (if I may say), as this will cause such catastrophes to be caught much earlier. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> * Most of that work is supposed to be automated or to be done by the RM. Code going up the branches should always be fast-forward. </blockquote><div> Again, another candidate for time-wastage. Why not work in one branch itself? That would prevent un-necessary duplicate testing by the RM. It makes MUCH, MUCH, MUCH more sense to concentrate all testing for one codebase (i.e. for one code, corresponding to one branch). (and this applies to everyone, not just the RM). </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> * The developers only work in their personal clones of the devel branch,</blockquote><div> That is understood. As long as developers don't commit, they are free to do anything they want to do on the branch, as long as they don't commit. A code is "effectively" in the branch, only and only after it is remotely-pushed. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> so from their perspective there is only *one* branch that matters. All the rest is risk management. Of course this is a provision for more developers working on the code in the future, so I understand it can look overkill now that you do most of the code alone :) * Some steps in the scheme are optional and can be removed, like the master and the production branches being different. As with any proposal this needs to be tuned up. </blockquote><div> All this I am speaking from personal experience, as giving commit-access to the develper was a big step in saving time (courtesy Anish). Earlier, before committing, me and Anish had to go through the testing process individually (meaning double effort; surely no gain). Instead, Anish then started to test on a RPM-level (i.e. building rpms, and deploying on the XO). That served the following purposes :: a) End-to-End testing b) Testing at a rpm-level, not patch-level. Anyways, now that the code-review would be in-place soon, the committer (other than the developer) will anyways test the patch once before committing (thus providing more security against catastrophes). In summary, I am not in favour of multiple branches. As Rafa said, we may split into a devel-branch sometime just before the final release; but even that too if necessary. Let's conceentrate on just one branch - meaning one branch to test. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div><div> -- Rubén Rodríguez CTO Activity Central: <a href="http://activitycentral.com" target="_blank">http://activitycentral.com</a> Facebook: <a href="https://activitycentral.com/facebook" target="_blank">https://activitycentral.com/facebook</a> Google+: <a href="https://activitycentral.com/googleplus" target="_blank">https://activitycentral.com/googleplus</a> Twitter: <a href="https://activitycentral.com/twitter" target="_blank">https://activitycentral.com/twitter</a> _______________________________________________ Dextrose mailing list <a href="mailto:Dextrose@lists.sugarlabs.org" target="_blank">Dextrose@lists.sugarlabs.org</a> <a href="http://lists.sugarlabs.org/listinfo/dextrose" target="_blank">http://lists.sugarlabs.org/listinfo/dextrose</a> </div></div></blockquote></div> Regards, Ajay Garg Dextrose Developer Activity Central: <a href="http://activitycentral.com/" style="font-size:13px;font-family:arial,sans-serif" target="_blank">http://activitycentral.com</a> _______________________________________________ Dextrose mailing list <a href="mailto:Dextrose@lists.sugarlabs.org">Dextrose@lists.sugarlabs.org</a> <a href="http://lists.sugarlabs.org/listinfo/dextrose" target="_blank">http://lists.sugarlabs.org/listinfo/dextrose</a> </blockquote></div>