Re: Help Planning For Upcoming AdBoard Meeting

[Dave Neary <dneary gnome org>]

Hi Brian,

Brian Cameron wrote:
> The next GNOME Advisory Board meeting will be on December 17th.  The
> topic of the meeting will be "Upstream/Downstream" and will focus on ways
> that various distros can cooperate and work better with the upstream
> communities.


It's an important opportunity, I would say, to figure out what is
holding any such co-operation back.

Part of what makes it difficult to work with upstream is that people
think of themselves as "downstream" - having the GNOME guys working for
Canonical think of themselves as GNOME guys, and submitting work to SVN
as it gets done, rather than after its release, is important.

But that sometimes conflicts with product schedules... if you submit a
feature upstream and it doesn't get reviewed straight away, or it's good
enough for you but not for the maintainers, you may not have time to
make suggested changes in your release planning.

This is something that downstream can work on - it's about creating
community identity, perhaps to the detriment of corporate identity. I
remember the days when it was Ximian vs RedHat vs Sun on most technical
decisions that were in any way controversial, and we paid for that in
terms of progress for a couple of years. To make hard choices you need
to get past gang wars and have a real GNOME identity, and think about
"we can't ship that" afterwards.



Attacking this idea from the other end, it must be obvious to someone
coming from downstream how they become part of the community they're
interested in, and how they gain the influence they need to do their
jobs while working upstream.

Increasing the transparency of the governance for various GNOME-related
products is a good idea - for example, who decides what goes on the GTK+
roadmap? What is the release management? Who are the maintainers? How do
I get to be a maintainer? I'm working for Motorola and I have a 10,000
line diff that implements a dozen features we needed, what is the best
way for me to go about getting those features upstream, and becoming an
influencer of the project so that I don't build up another 10,000 line
diff during the next release cycle?

You can do a lot of work on pretty much every product in the GNOME big
tent - we have a variety of governance models from committee to
company-led to individual benevolent dictator - and on top of it all is
the GNOME release process and governance.

To encourage upstream/downstream co-operation, the doors should all be
clearly labelled. I'm not saying that we should make it *easy* for
someone to become a maintainer of a platform library, but that the cost
of becoming a maintainer should be easy to evaluate.


Hope these ideas help make it a productive meeting!

Cheers,
Dave.

-- 
Dave Neary
GNOME Foundation member
dneary gnome org