Re: How we make decisions... [Fwd: Re: Proposal: replacing esound with polypaudio in 2.10]

[Brian Cameron <Brian Cameron Sun COM>]

Mark/Sri/Others:

One of the jobs that I have been spending a lot of time working on
lately is making sure that the GNOME stack goes through ARC (Architecture
Review Committee) reviews.  This is a Sun internal process that is
focused on ensuring stability from release to release.  They work to
ensure that libraries that are supposed to be ABI compatible are meeting
the requirements, that file-integration points remain backwards compatible
when appropriate, etc.  We are hoping to start work to ensure that GConf
keys behave sanely when a user tends to run multiple versions of GNOME
from the same home directory.

Unfortunately this Sun internal process has been having a lot of
difficulty dealing with the sheer size of the GNOME project and the
difficulty of getting a Sun-internal process to work well with an
open/public community.  The current ARC procss in Sun is really geared
to work best for projects that are controlled by Sun, so current and
past efforts have not translated into enough positive contributions
back to the community.  Instead, ARC has focused on areas where
it does have some control - such as file installation locations.

We feel that since Sun is already spending effort and time reviewing
the architecture of GNOME's interfaces, that it would be more
productive to work with the community.  With this in mind, we have
been looking for ways to make our process work better.  I have
been meeting with the ARC chairs, who are responsible for high-level
decisions in the process.  One of the conclusions that we have come
to is that it would benefit to better engage the community.

For example, Sun currently spends a lot of time putting together
documentation to highlight specifically what ABI changes exist from
release-to-release.  Currently Sun is only focused on Solaris
releases, so we currently only do this work between releases that
Sun plans to ship on Solaris (2.0 to 2.6 for example).  Some of the
information is taken from the gtk-docs, which do a good job of
explaining when new function interfaces are added.  But the gtk
docs do not highlight other interface changes, such as the
following:

+ when enumerations are added
+ when data structures are modified, to perhaps include new data
  variables
+ what release functions are depricated or removed.
+ changes/additions/removal of environment variable usage
+ to give some information about stability level of an interface,
  where appropriate

Simply enhancing the gtk-doc utility to provide such useful,
additional information would be a better way to document this
information than putting it in Sun-internal and confidential
ARC documents.  It would also be more likely that such information
would be maintained by the community if the gtk-doc infrastructure
made it simple and straighforward to document such changes.

The ARC chairs have agreed that we likely need a better internal
process for handling architecture review of external projects.  For
example, it would be good if we were able to transform the
internal documentation so it doesn't need to be confidential when
working with open source projects.  Then it would be easier to
share information that we discover back with the community.

The ARC process is similar in some ways to the GEP process.  So
if there is an interest in the community to review this process
and determine how to make it better and less painful, then I
would like to let you know that within Sun there is a similar
interest in making our process better and less painful.

Perhaps this is an area where Sun and the GNOME community could
work together, review each other's processes and see if we can
figure out a way to make each others process more fun and useful
for everyone.

If there would be an interest in the community, I know that a
number of the ARC chairs have expressed that they have an interest
in working with, learning from, and contributing to the free
software community.  I was recently told by Joe Kowalski that
he spoke with SAC (Systems Architecture Council which ARC is a
part of) management and "they would be more than willing to
fund three [ARC members] to attend the Gnome winter meeting and
discuss interface management issues."  Suggestions about how to
best use their time would also be useful.

I have cc:ed the sun-sac-foss-ext sun com mail alias, which is an
external Sun alias for discussing how to improve relations
between the FOSS (Free/Open Source Software) community and the
Sun SAC processes.

Sri Ramkrishna wrote:
> On Fri, 2004-11-12 at 12:19 +0000, Mark McLoughlin wrote:
> /<snip>
>
>>    I'd encourage people who are complaining about our decision making
>> process to go back and consider the GEP process:
>>
>> http://developer.gnome.org/gep/gep-0.html
>>
>>    Now, everybody hated the GEP process because it felt way too
>> heavyweight and GEPs were, by and large, never concluded. The former
>> problem is certainly solvable, but I'm not sure about the latter.
>> Possibly have an number of people who own the overall job of making
>> people bring GEPs to a conclusion, any conclusion.
>
> Indeed. The problem with too formal of a process is that it takes away
> the fun of working on a project.  If I wanted formal process I'd get it
> at work.  We got plenty of that crap there.  It doesn't necessarily help
> making decision making.
>
> What we're looking for is a pragmatic approach to technology.  We tend
> to get bogged down by details (eg does it work for non MMU? etc etc) of
> either the implementation or what?  What it boils down to I think is
> this:
>
> * Do we need this technology?
>
> * Is the architecture sane.  Can we extend it if we want to in case we
>    have more requirements?
>
> * Does it have good documentation?  If the module goes unmaintained is
>   there enough information in there for someone to pick it up?
>
> * Does it meet 80% of our requirements and can the other 20% be
>   implemented in a reasonable timeframe? (this might be redundant with
>   point 1)
>
> * If it ends up being broken, how do you back out of it?
>
>
> I prefer to make decision making as simple as we can.  The easier the
> better.
>
>>    The process did have some nice properties, though:
>>
>>  - It made people think about what they were trying to achieve:
>>
>>     + Why do we need a new sound server?
>>     + What do we really need to be better in our new sound server?
>>     + What worked well with the old one?
>>
>
> Thats good stuff.
>
>>  - It defined a group of people who were going to voluntarily take
>>    on the responsibility of co-ordinating the discussion
>
>
> That still needs to be done.  I tend to believe that the people who need
> to make decisions are the maintainers of the modules who are most
> affected (if any is affected at all).  If no maintainers, it should go
> to ddl or maybe a seperate mailing list of people who care to
> participate in such things.  I don't know.  Something worth discussing.
>
>>  - It documented the discussion
>
> Yes, something we miss doing everytime.  If you look at the history, you
> never actually see a decision made.  After a discussion nobody comes
> back saying "we decided to do this".  Magically, later something starts
> showing up.  I'm actually cool with that; prior warning though would be
> nice.
>
>>    I think I'd be happy to try and resurrect the GEP process in a much
>> more lightweight form if I thought there would be any enthusiasm for it.
>
> That would be great if you could do that!

--

Brian