Re: I want in!

[Elijah Newren <newren gmail com>]

On 11/7/05, Federico Mena Quintero <federico ximian com> wrote:
> On Mon, 2005-11-07 at 12:16 -0700, Elijah Newren wrote:
>
> > - I've chatted with Johnathan over email recently and he expressed a
> > similar sentiment, so you could also contact him.  An important point
> > he brought up, though, is that we need to work hard to be open about
> > our plans so that distributors relying on us can plan accordingly.
>
> What's this about?  Informing them about things like
>
>         String freeze is on such and such date
>         Hard code freeze is on such and such date
>         Yo, dudes, tarballs are out

Actually, I'm not quite sure.  I asked again and he didn't elaborate
other than "well, right now things are going well so just keep it up"
so I guess it does include things like this.  However, it reminded me
of Miguel joining the gtk+-2.8-in-gnome-2.12 debate--after it was
already over--and then strongly trying to reverse the decision despite
it having been finalized.  Reflecting on it, I wonder if it was
perhaps caused by us not communicating well enough, and perhaps it put
him and others at Novell in a tough position (which perhaps he jumped
in because others didn't feel they had enough clout to pull it off?). 
If possible, I'd really like to try to avoid something like that,
because I don't want the community members distributing Gnome to be
stuck in tough positions.  So, my guess is that Jonathan was just
trying to be cautious on the avoid surprises thing.

> > - We need to work harder at involving the community if we're The
> > Cabal.  We'd like to get the community a lot more involved.  In
> > particular, I don't see how you'd need to be a member of the release
> > team to do the performance work you suggest.
>
> Oh, the performance stuff is not the only thing I want to do.  It's
> pretty hard to get automated performance tests.
>
> I'd like to put in place several things:

Note that these really aren't things the release team can impose
(though we are the ones that try to assist in getting others to follow
them once everyone has agreed on these rules).  They're something that
need to be proposed to the community on desktop-devel-list and see if
we can get broad consensus for; proposing such things can be done by
community members as well as release team members.

I can't resist the urge to comment on them though...

> 1. A freeze for user documentation, so that translators can keep up.

So, in other words, Shaun can't start documenting until feature freeze
and has to quit early too?  That may be asking a little much of him. 
;-)

> 2. A deadline for new APIs that don't have docs yet.  We simply should
> not accept new APIs that don't have documentation.  If a module didn't
> add new APIs, we should not accept it unless it has more API
> documentation than it used to have.

Brian and Murray tried to push earlier for some similar things but
didn't get real far.  I think any effort in this area would be great.

> 3. No-go for modules whose fixed bugs / total bugs ratio didn't increase
> since the last release.

What's that mean?  Removal from the release?  Or are you only talking
about proposed modules (which would probably get a huge boost in bug
reports from the extra exposure and thus get kicked out despite likely
being less buggy)?  I'm skeptical...

> 4. See if we can pull things off like no-go for modules with critical
> warnings.

:-)