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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list