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