<div class="gmail_quote">On Wed, Oct 10, 2012 at 11:37 PM, Ajay Garg <<a href="mailto:ajay@activitycentral.com" target="_blank">ajay@activitycentral.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Having so many branches is an overkill; it is too efforts-intensive, error-prone and generally daunting. We should just go for one branch (besides the upstream master branch). This singular branch should serve everyone's purposes - developers, QA, staging, "golden", etc. </blockquote><div> </div><div>Too many are overkill but too few are also error prone and become critical to maintain. an alternative scheme could be:</div><div> </div><div>1 Upstream - Master</div><div>2 DX - Master 3 DX - Devel</div><div> </div><div> </div><div> </div><div> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As far as extracting patches is concerned, well, hold me responsible for doing it later. Right now, let's just focus on getting things completely and efficiently, IN AS SIMPLE A MANNER as possible, for December-16.<div><div class="h5"> <div class="gmail_quote">On Thu, Oct 11, 2012 at 9:02 AM, Ruben Rodríguez <<a href="mailto:ruben@activitycentral.com" target="_blank">ruben@activitycentral.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 2012/10/5 Anish Mangal <<a href="mailto:anish@sugarlabs.org" target="_blank">anish@sugarlabs.org</a>>: <div>> Advantages: > * Easier to collaborate with upstream. They can actually view the code > in it's intelligible form, rather than discrete patches. > * Easier for deployments to see the code. > * Perhaps better integration with automated build workflow > * The pros that Ajay mentioned. > > Challenges: > * Cost of switching. Something that the project managers need to analyze. </div>I don't see this as much of a problem if we can extract patches cleanly. Other than that issue, almost any git based workflow would be an improvement. <div> > * The question of different features for customers remains unanswered > to an extent. > *a. Do we start to maintain different branches for codebases? Are we > maintaining different branches for OOB build envs. right now? > *b. Everything can't be gconfable? > > There has to be some level of agreement between uy and au on features > otherwise dextrose starts to lose it's identity. </div>I think we can either think of Dextrose as a product that the deployments can adapt to some extent, or as the base upon we build a different thing for every client. Those are diferent ideas both from a technical and a business perspective. I vote for the first one in any case, I think having an unified codebase would benefit both the deployments and us as maintainers. Adding Ajay's comment for thread unification: > Pros :: > * No need to "rebase" a change upon the patch. > * All that is needed is make-a-change; test; commit. > > Cons :: > * Difficult to isolate patches feature-wise, which is kinda necessary for upstreaming. > * But, I (at least) would want to make life easier "in the moment", rather than worry for later. > > It should not be too tedious to "extract" feature-patches, whenever upstream wishes that they are ok to accept new features. Making patches is one of my biggest concerns, and I want to have some tests done (with our patches and some fake commits on git) to see how cleanly we can get our patches out of git. But I agree it shouldn't be hard, as git was designed with that (among many other features) in mind. I got into several meetings and discussions with Santiago in the last days regarding the git workflow, and we have come up with the following proposal: We start by cloning every upstream package separately into git repos * Sugar > Sugar-dextrose * Sugar-toolkit > Sugar-toolkit-dextrose * Sugar-artwork > Sugar-artwork-dextrose and so on. The clones will live in <a href="http://git.sugarlabs.org" target="_blank">git.sugarlabs.org</a>[1] and will grant commit permissions to the release manager (RM). Each of this repos will have the following branches, that define the workflow: 1 Master 2 Devel 3 QA 4 Staging 5 Production Additionally each developer will have a personal clone of the Devel branch, upon where to commit his code. 1 MASTER: it is a direct clone of an upstream tag, (e.g. sugar v0.98.1). Optionally it will receive as commits only bugfixes that are directly approved for upstreaming. This simplifies the commit merges. 2 DEVEL: it receives the latest code from the developers' repos, via fast-forward merges that the RM would do by request of the developers. It is the developer duty to make sure the commit applies cleanly (fast-forward) to the devel branch, by having their own local repos properly updated. 3 QA: groups of commits forming a new feature or a bugfix are then committed into the QA branch. Grouping them this way should simplify extracting patches to send upstream. Automated from this branch we will generate a set of rpm's in a repository that the QA team will have set in their machines, so they can test that the new code fixes the issue. If the fix is approved (or after new commits if it needs a modification), the commits are merged into the Staging branch. 4 STAGING: This is an optional step. As with QA, it would be used to generate a (at this time already tested) rpm repository that a "classroom 0" would use. This extra testing can be done in an environment closer to production, like a particular school, and with the help of the teachers, and would prevent a bad update to be pushed to the whole deployment. 5 PRODUCTION: At this point the code is golden, and is automatically packaged into a rpm repo for general use. The passing of code between one branch to the other should be handled by the appropriate acting of the different teams and the RM using redmine metadata changes to the related issues. 1: Why not basing the git repos directly in <a href="http://sugardextrose.org" target="_blank">sugardextrose.org</a>? * Visibility: We wont to be as close to the community as possible, and the Sugar code lives at <a href="http://git.sugarlabs.org" target="_blank">git.sugarlabs.org</a> * Redmine's support for git is incomplete, and is mostly limited to browsing the code and it's commits, and to connect certain commits to issues and their changes in status. But it lacks support for multiple repositories per project, or for personal repositories per developer. It also lacks support for ssh-key management and other developer-centric features. * We would still set redmine to keep a direct clone of the repos at <a href="http://git.SL.org" target="_blank">git.SL.org</a> so the code and commits will still browseable at sdxo, keeping all the git integration features redmine provides. NOTES: * It is the devel responsibility to make sure the commits apply cleanly, and that they are signed and commented, with the appropriate headers pointing to the redmine issues. * It is the RM duty to make sure those rules are followed. * Commits should be grouped by feature or bugfix as much as possible, to simplify extracting them for upstreaming. This process will need to be thoroughly documented with commands and tips for code refactoring. * Initiating a release on a new upstream Sugar version would start by tagging the current version (thus freezing the code for the previous release) and merging down the changes from upstream into master, then rebasing the Production branch on that master and renaming it to Devel. New QA, Staging and Production branches would be spawned from this new Devel branch. * OOB is somewhat different and needs its own workflow, much simpler. * We should also review our workflow for activities as a separate project. My 200 cents. <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> </div></div>Regards, Ajay _______________________________________________ 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>