Re: Assigned responsibilites, again

[Vincent Untz <vuntz gnome org>]

Le jeudi 16 juin 2005 �1:03 -0600, Elijah Newren a �it :
> > 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?

It's a release team task as in "find someone with a clue who can
organize the review" :-) So, basically, it means making sure that
Bryan/Calum/Seth/anybody else (but not me) can do it and has everything
he needs to do it.

> >         * documentation links nagging
> 
> I'm also not quite sure what this means.

Oh, yes, I forgot to explain this. I blame my cut-n-paste. In each
new .0 release, it seems some Help buttons point to a documentation that
does not exist any more. This is bad. We should verify as many Help
buttons as possible before .0.

> > 
> > 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?

No. I should have explained too :-)
i18n people open bugs when there are some string problems in the apps
(typo, but also strings that should not be translated, or some other
stuff). We should make sure to close as many bugs of this kind as
possible before string freeze.

> >         * 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?

All these ideas are great :-) So I vote for all of them ;-)
But I guess it depends on the time people will have to do this.

It reminds me that I forgot:
	* showstopper bugs nagging
	* a11y bugs nagging ?
	* etc.

> >         * 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)

Nice. I'll probably move all this to the wiki this week-end.

Cheers,

Vincent

-- 
Les gens heureux ne sont pas press�