Re: Assigned responsibilites, again

[Elijah Newren <newren gmail com>]

On 6/16/05, Vincent Untz <vuntz gnome org> wrote:

> Let's finish this discussion :-)

:)
 
> I don't know if we have an extensive list of tasks available somewhere
> (except [1]), so here's the start of a more complete list:

Not that I know of, but see at the end for a few more that I got from
searching through old email...

> Bindings Tasks:
>         * ??
> 
> Desktop Tasks:
>         * UI review (before UI freeze)

I don't think I understand how this is meant to be a release team
task...could you elaborate?

>         * documentation links nagging

I'm also not quite sure what this means.

> 
> Platform Tasks:
>         * ??
> 
> General Tasks:
>         * string bugs nagging (before string freeze)

Would this just consist of sending out an email pointing to the
relevant i18n page describing the details and reminding people to ask
them for permission instead of us?

>         * patch nagging

What should this entail?  Olav and I put together
http://bugzilla.gnome.org/reports/patch-status.cgi and
http://bugzilla.gnome.org/reports/patch-report.cgi (where the former
is a front-end to the latter) which complement the older
http://bugzilla.gnome.org/reports/patch-diligence-report.cgi; I was
also thinking of a weekly automated email summarizing three things:
(1) new patches in the week, (2) a few stats about patches for the
product/component in general, and (3) providing a simple link to the
relevant patch-report for the given product/component.  Other ideas
are also under consideration, probably after the bugzilla upgrade
underway (e.g. automatic detecting and marking of unmaintained modules
in a way visible to anyone looking at bug reports against the relevant
product).

Ideas of things "patch nagging" could mean here, but I'd like
ideas/suggestions: (a) periodic public reminder of general patch
state, pointing out those who have done well recently, (b) checking
for modules that may have become unmaintained so that the release team
and development community can be aware of possible issues, (c)
pointing out any longstanding accepted-commit_now or
accepted-commit_after_freeze patches, (d) a call for action to assist
maintainers with bugsquad like pseudo-review of patches ("does it
still apply?", "does it appear to follow coding guidelines?", "are
there conflicting patches elsewhere in bugzilla?", "does it
work-for-me?", "does it appear to be valgrind-clean?", "are there any
problems obvious to a non-maintainer?")--i.e. something that could be
a big enough task to encompass a lot of the bugsquad or gnome-love or
be a new project altogether, (e) something else entirely?

>         * new modules
>                 + call for new modules
>                 + animating a new modules discussion in the community
>                 + new modules decision
>         * sending the "tarballs due" mails
>         * announcing releases
>         * creating a schedule
>         * freeze breaks
> 
> Hrm... It might make sense to create a wiki page. I will do this later,
> if it seems useful to others.

Murray had an email to r-t last september (which appears to have been
nuked from the archives when r-t became public; 
http://mail.gnome.org/mailman/private/release-team/ only shows the
same information as http://mail.gnome.org/archives/release-team/)
where he listed a few other tasks.  Here's the ones you didn't list
above:

2) Ensuring release notes get written
3) Defining the contents of each release set
4) Reminding maintainers that tarballs are due, gathering those
together for each release, sanity checking and announcing
6) What other tasks should be here? I think that
bug-monitoring/summarising should be here too...

(Well, you listed the tarball due reminder and announcing, but not the
other stuff like sanity checking and whatever else is done when making
the release)

Cheers,
Elijah