On Tue, 2003-07-08 at 20:10, Luis Villa wrote:
[snip]
> I don't have any brilliant, great ideas to solve any of these things. My
> off-the-cuff suggestion is that one way that we could help alleviate the
> problem is more meaningful groupings, like GNOME Office has striven to
> be for many years. If someone had the desire to organize and motivate a
> meaningful 'GNOME media' release with the same standards for QA, UI, and
> a11y as the desktop release, it would take a huge amount of pressure off
> the core. Ditto 'GNOME communications.' Do that, and you've knocked out
> all the media stuff (totem, gnome-media, maybe RB in future, etc.) and
> all the communications stuff (AIM, gnomemeeting, maybe evo in future?,
> etc.) from core, while still giving QA, l10n, etc. defined sets of
> things to work on, and still giving those hackers a sense of
> participation in something bigger than themselves (which I think is
> something most of us value.) I'm sure you could look at the core apps
> and find other groupings as well. [Maybe 'display tools'- gthumb, gpdf,
> eog, ggv?][And obviously a11y tools fall out of this as well.]
>
> If you break things down in that way, 'GNOME' is still fairly clearly
> defined ('it's desktop + media + communications') so you have those
> benefits for all the teams, but you've reduced the pressure for the core
> to grow and you have slightly more flexibility and less pressure on the
> edges. You also more clearly define where we need to grow- if there are
> enough tools for a 'group' of tools to form, then probably that means
> there is interest and demand for them in a way that isn't necessarily
> reflected in our current process.
>
> Anyway, I'm really not sure that is a workable solution- it would
> require strong leadership at the team/group level that isn't currently
> there. But otherwise, it seems to solve the problems that I see that we
I'm not entirely convinced that the leadership isn't there, though it
certainly isn't leading at the moment. I think that in order for this
to work out well we'd need to have a 'release team' for these groups.
(Hmm, I can't find any list of who is currently on the release-team, nor
what their jobs are. This would be really handy to have.) We'd
probably have to figure out how many folks were needed for this, see who
would volunteer, and have them officially 'blessed' by whoever 'blessed'
The Release Team. I don't think this is a job that 1 or 2 people can
keep on top of effectively.
Greg
> have. I don't think making things more diffuse, as Iain proposes, solves
> these problems- it's a large-scale way of saying 'we don't know how to
> do this, we'll just code an option.'
>
> My two cents-
> Luis
Attachment:
signature.asc
Description: This is a digitally signed message part