incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Giffuni <>
Subject Workflow (was Re: build svtools with debug)
Date Wed, 26 Sep 2012 19:04:16 GMT

Hi Juergen;

Oh.. I am not feeling any of this as a personal attack, email doesn't really represent
what one thinks or how one feels about things..
It will be interesting to meet you in Germany... I suspect we are not very different ;).

> From: Juergen Schmidt <>
>> > Please explain where exactly your problem is to do the work on a branch.
>> >  
>> > 
>> Please, when we have identified the breakage cause and iff it's clear it
>> was my update I will be glad to revert it. I really need evidence though,
>> the changes were thoroughly tested and you cannot ask me to revert it
>> based on Rob's sudden's feelings about it. 
>it seems that you don't get my point and I was not clear enough. I am not interested in
this specific case but more in a general agreement how we can address such problems.

My workflow is different to what you can expect from a professional developer
for many reasons, but what I tend to do is this:

- My build system is based on FreeBSD's ports tree but I do use the latest
code from trunk and do frequent updates from SVN. Other people's changes
do affect directly what I am doing. In a certain sense this is the same as
having my own local branch but some of my changes are not ready for sharing.

- AOO takes long to build here so I have time to do other stuff while I wait for a
build and on occasions I can be doing two orthogonal changes. Ideally I only
work on one thing at a time but I can occassionally work on two.

- All my changes are tested here first.
- If I think the change is ready but I am not prepared to support an eventual
breakage upstream, I leave it "resting" in my system for a while.
- When I think the change is very system dependent I open a bugzilla issue
and let it there for someone else to review.
- I only do the commit when it's ready but I need to stay available to fix any
eventual breakage (shit happens - I know it just too well).
Before committing I always look at svn status, svn diff, and I keep a patchset
ready in case I have to revert.
- I am not afraid to commit. That's what lazy consensus is about.
-When failure has happened I analyze quickly a solution, even if it is not
optimal. If I can't fix it, I will point out where it seems to be failing and I offer
to revert. Normally, like in the python update: I was able to fix it quickly and
after a while I replaced the quick fix with a better one.

>> If I do have to revert it then I will simply drop it. It works fine here. and
>> I don't have anything to fix.
> Mmh, I am sure you don't mean this serious and I hope I made already clear
> that I wanted address this more general.

I will explain this better: my work cycle is at most two weeks for a particular
task. This is unpaid work so I don't feel like spending too much time unless
it's real fun.

In the case of the boost update, this is something that helps the project
because we have tested patches to make boost build with both gcc and
clang. This is not something I *need* to have though: I already enjoy the
benefits of using it as system boost. If I fail by breaking a system I
don't have access to I won't stress about it: of course I will revert but
if I don't have access to such system how am I going to fix it?
Someone else may take over or it will be left to rust (as happens with so
many things that no one has updated in AOO).

If the boost change had required fixing regressions and/or optimizing other
parts of the code I surely agree creating a branch was a sound approach.
I think using branches is cool, but if your changes are simple (boost either
builds or it doesn't) and can be handled with a single diff it is an overkill.

Just my thoughts,


View raw message