incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: [DISCUSS]: AOO 3.4.1 reflection and lessons learned
Date Thu, 27 Sep 2012 17:35:24 GMT
On Mon, Sep 17, 2012 at 7:24 AM, Jürgen Schmidt <> wrote:
> Hi,
> AOO 3.4.1 was our second release and I would like to do some reflection
> of the past and especially the hot phase in the end where we tried to
> finalize the version. Things that were not so good and that can and
> should be improved in the future. I am looking for general remarks and
> feedback from people who were involved in this release process and who
> were affected in one or the other way.
> I would like to start first with some brainstorming and have created a
> wiki page [1] to collect the outcome of this brainstorming and
> reflection. This will hopefully help us to avoid mistakes for future
> releases. It can hopefully also help to identify gaps that we have and
> where we should focus a little bit more to close these gaps.

I put some comments on the wiki, but it looks like not much out there
from others.  A few quick thoughts to stimulate some more ideas.

To publish Apache OpenOffice requires two kinds of tasks:

1) Routine, repetitive, time consuming, not-fun work.

2) Fun, exciting, creative work.

Some of this varies by the individual.  For some, debugging is a pain.
 For others it might be an adventure.  Perhaps it depends on whether
you are debugging your own code or not ;-)

In any case, I think the project grows to the extent we can increase
the ratio of fun work to not-fun work.  This makes it overall more fun
for us and helps us attract more volunteers.

The most direct way to improve this ratio is to reduce the amount of
time we spend doing it, by automation or other means of increasing

Examples of time-consuming, repetitive, non-fun work might be:

1) Building AOO

2) Coordinating and posting a RC

3) Explaining the same things over and over again, whether to users or
to other project volunteers

4) Release requirements checking on each release

Perhaps other similar tasks and embedded processes come to mind.

If we think of this as a process of continual refinement and
optimization, we would identify how can improve on items like this.
In fact, from what I hear, more discussions of improving the build,
making more use of build bots, etc., we're heading in the right

I read a good quote yesterday that is somewhat relevant, by Alfred
North Whitehead:

"It is a profoundly erroneous truism, repeated by all copy-books and
by eminent people when they are making speeches, that we should
cultivate the habit of thinking of what we are doing. The precise
opposite is the case. Civilization advances by extending the number of
important operations which we can perform without thinking about them.
Operations of thought are like cavalry charges in a battle — they are
strictly limited in number, they require fresh horses, and must only
be made at decisive moments."

I think the same is true of software development.  Our probably today
is we have too much that requires thought and not enough that happens
automatically.  We don't have a lot of "fresh horses".  So we need to
concentrate our efforts on where they make the most difference.  This,
at the same, is the stuff that is most fun.


> [1]

View raw message