GNOME goal candidates

[Michael Catanzaro <mcatanzaro gnome org>]

Hi,

One of my action items from the release team meeting at GUADEC was to
go through the GNOME goals page to deal with the backlog of unapproved
goals. (I never said *when* I would do it. ;) Please review this list
and complain if you don't agree with my choices.

It's worth mentioning that some of these goals are VERY old.

I want to immediately approve the following three goals, provided that
their sponsors are willing to update the (now very stale) lists of
affected modules:

https://wiki.gnome.org/Initiatives/GnomeGoals/UseTimeoutAddSeconds
(Javier Jardon)
https://wiki.gnome.org/Initiatives/GnomeGoals/HeaderBars (Allan Day)
https://wiki.gnome.org/Initiatives/GnomeGoals/DBusActivatable (Matthias
Clasen)

I want to punt on the following goals and keep them in the unapproved
candidate list for now:

https://wiki.gnome.org/Initiatives/GnomeGoals/DistCheck
https://wiki.gnome.org/Initiatives/GnomeGoals/ModernAutotools
https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests

I want to reject the following goals:

https://wiki.gnome.org/Initiatives/GnomeGoals/UpdateInfoFiles
https://wiki.gnome.org/Initiatives/GnomeGoals/NicerBuilds
https://wiki.gnome.org/Initiatives/GnomeGoals/AddCodeCoverage
https://wiki.gnome.org/Initiatives/GnomeGoals/ValidateGtkBuilderFiles
https://wiki.gnome.org/Initiatives/GnomeGoals/CorrectIconNames

In order:

Passing distcheck is obviously good, but not useful to spend time on
this now if we wind up creating a Meson goal, which seems likely. We
have enough goals right now as it is. Moreover, this is really
something to be expected of module maintainers rather than a project-
wide goal where everyone would be encouraged to help with different
modules. And our maintainers are not stupid; if they're releasing
modules that don't pass distcheck (vte <_<), something is very
seriously wrong.

The ModernAutotools goal needs to be updated, because best practices
have changed since it was written. We'll need to look this one over
closely before approving it. Additionally, it's not useful to approve
it if we wind up creating a Meson goal instead.

As for the installed test goal, I'm really not convinced that tests
should be installed. The QA team that was enthusiastic about installed
tests seems to have disappeared, so nobody is driving this anymore. I'd
like to see further discussion on this before approving or rejecting
it. Also, I'd like to see if people are still interested in . I kinda
think that traditional make check style testing is still the way to
go....

UpdateInfoFiles includes some weirdness like updating FSF address in
all source files, and changing all applications to not use ranges to
indicate copyright years. This is not related to updating info files
and needs to be split out at the very least. But I'm also not sure this
is an appropriate goal candidate anyway. We can update all our README
files now, but they're just going to become stale again in a few years,
and we don't want to re-run this goal every couple of years. That's not
to say we shouldn't update our info files anyway -- of course we
should! -- but that I'm not convinced this should be a project-wide
GNOME goal. (P.S. This goal turns 10 at the end of the March! We should
probably handle goals a bit sooner in the future. ;)

NicerBuilds is just using silent rules. That's already complete for all
GNOME modules, so there's zero reason to approve it as a new goal.

Code coverage would be wonderful, but there is no point in adding
coverage to modules unless the modules' maintainers plan to work on
adding new tests to raise the coverage. We just don't have enough
developers to do this project-wide. Accordingly, coverage should be
pursued on a per-module rather than project-wide basis.

GtkBuilder validation looks like more gook to add to our Automake
files, when we really want less gook there. Even if it's only a small
amount of code, I'd rather it be implemented as an autoconf archive
macro and re-proposed. I'm not sure if it's really necessary anymore
anyway, since GTK+ almost always warns about XML problems at runtime,
right?

I'm not sure about the status of CorrectIconNames, but its description
is clearly very obsolete. So at the very least, that's going to need to
be revisited and proposed again.

Michael