Re: Defining GNOME software (finally)

Thanks for the reply Michael - very helpful!

Michael Catanzaro <mcatanzaro gnome org> wrote:
So I propose that
we have the wiki page say that the canonical definition of "what is
GNOME?" is the list of BuildStream elements listed in
meta-gnome-core-developer-tools.bst, meta-gnome-core-os-services.bst,
meta-gnome-core-shell.bst, and meta-gnome-core-utilities.bst.

I was wondering the same thing - this sounds good to me!

Note it
intentionally does not include SDK components like GTK or GLib. We
could potentially expand the definition to include SDK components
hosted on, but that would require splitting up sdk.bst.

If those components are relatively stable, could we just list them on
the wiki somewhere? Whatever path offers least resistance is probably
the way to go.

To make sure we don't have misplaced expectations, please remember that
this list cannot be used for deciding what repositories go into the
GNOME/ group on GitLab, because probably 90% of the stuff currently
there is not core and is therefore excluded from our definition, and
also because we add and remove things from core on a semi-regular basis
(e.g. we just removed gnome-themes-extra earlier this week). I continue
to recommend allowing experienced GNOME developers to create new
repositories there as needed.

I don't want to comment on the legal aspect of this too much, but we
probably do need a Foundation policy to cover what goes into that
group. At the same time, your point is a good one - we don't want
avoid frequent changes in the Gitlab group membership. The answer to
that is probably to have some exceptions in place in the policy, to
give us a bit of flexibility. We'll figure out the details of that.

We'll also need you to confirm that the member list [2] is
up to date.

That member list is kept up to date, yes.

Great, thanks!

We'd also like to know if you want to keep the Release Team name, or
whether you'd prefer to switch to "Release Committee" or "Engineering
& Release Committee", or anything else. It's up to you.

I think we're fine with release team.

I thought you'd say that. :)

You should also know that becoming a committee will involve some small
changes [3]:

  - You'll need to have membership changes ratified by the board
  - You'll need to have a chair, and minuted meetings

Any suggestions for who should be chair?

  - You'll need to keep the board informed about how things are going

Having membership changes ratified seems fairly low cost. We normally
hold one formal meeting per year, which we take private notes on, so
the only change there would be to make those minutes formal and public.

There's no requirement for minutes to be public. However, if the
Release Team is a committee it probably make sense for minutes to be
accessible to the Foundation (ie. Board, ED, etc).

Most of our decision-making occurs on IRC, and not as part of any
formally organized meeting, and therefore is not minuted.

I don't have much concrete advice regarding when meetings should be
held. My suggestion would be to have them whenever a non-routine
decision has to be made.

Thanks again,


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]