[Dextrose] Defining Dextrose 4 code workflow

[David Farning]

On Thu, Oct 4, 2012 at 7:33 PM, Ruben Rodríguez
<ruben at activitycentral.com> wrote:
> With this new release we have an opportunity to improve how the
> dextrose code is managed.
>
> From a code point of view Dextrose is composed of a set of
> modifications on OOB and a group of patches to the sugar,
> sugar-toolkit and sugar-artwork packages. At this point all those
> changes live together in the same git repository:
> http://git.sugarlabs.org/dextrose/mainline The patches to the sugar
> packages are in the rpms directory.
>
> I think that the first thing to do is separating both things, as the
> changes to OOB are not directly related to the patches, and should
> live in separate repos.
> The next step would be more complicated, and would be moving from the
> patch set to a git workflow that allows us to separate the different
> features so we can upstream them individually, and build rpm's with
> all the changes applied. This was tried before, but since we
> developers are stubborn sometimes, it didn't catch on. We need to make
> a bigger effort this time.
>
> Apart from having a clean way to be able to produce patch files to
> send upstream as needed, we should take into account the deployment's
> need to select which set of features they want to have in their
> packages. To simplify that, features like 1-to-n or multiselect could
> have an "enable" switch in a config file or gconf key, so they can
> share the same codebase.

Ruben,
This is an example of when it is a good idea to clearly identify what
problems you are trying to solve and why.

1. The Sugar code change sets and oob modification live in the same
git repo. This requires XXX to spend extra time when they .... (or
some thing like that)
2. The current git workflow makes if difficult to isolate individual
patches. This results in ...

Then, I suggest using timeboxing to make sure the job is completed in
a reasonable amount of time (or drop if necessary)

Something like.
Soft deadline -- We will wrap up email discussion on this top by XYZ.
-- If someone misses that date, to bad. As a company we need to stay
on track.
Soft deadline -- We will discuss the issue as an angenda at the
meeting on XYZ - Then set a time limit on the discussion.  X number of
hours. In the short term it sets a practical length on the discussion
time. In the long term it help us communicate more effectively as we
self police rambles because we want to make sure the other agenda item
which is important to us does not get cut from the meeting.
Hard deadline -- Decision point based on the information you have
gather set a deadline for making the decision. This can be hard for
perfectionist and acedemics. But in order to keep thing going you
often make decision with incomplete information:(

Soft deadline -- Turn back point if the prefered solution ends up
being to complicated to complete their should be a fall back. (I often
have four options when working on something mission critical. I use
the term PACE or Primary, Alternate, Contingency, Emergency)
Hard deadline -- implementation complete

It seems like a lot of work -- and it is -- at first. but after while
it become second nature.

Dave

> In any case that is just a suggestion, and I'd like to hear yours!
>
> --
> Rubén Rodríguez
> CTO
> Activity Central: http://activitycentral.com
>
> Facebook: https://activitycentral.com/facebook
> Google+: https://activitycentral.com/googleplus
> Twitter: https://activitycentral.com/twitter
> _______________________________________________
> Dextrose mailing list
> Dextrose at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/dextrose



-- 
David Farning
Activity Central: http://www.activitycentral.com

Facebook: https://activitycentral.com/facebook
Google+: https://activitycentral.com/googleplus
Twitter: https://activitycentral.com/twitter