Re: First ideas


On Fri, November 18, 2005 02:20, Federico Mena Quintero wrote:
> I'm spinning this off the thread we had, since I now have more concrete
> ideas :)
> 1. Have a deadline for API docs.  Just like we don't accept API/ABI
> breakage, I'd like us not to accept cases where libraries introduce new
> APIs without documentation.  I saw the TwoPointThirteen calendar and
> there's this:
> 	Jan 16 - API freeze, 2.13.5 tarballs due
> 	Jan 30 - 2.14.0 beta1 tarballs due, UI freeze
> Could we add something in between like this:
> 	Jan 23 - API documentation deadline.  If you added new APIs
> 	to a platform library, they must have docs or we nag you endlessly.

Sounds like a good idea.

> In particular, we sometimes add non-code interfaces like public GConf
> keys (which are invariably undocumented), which other people rely on
> eventually and yet we make no commitment to them.

Hrm... Do you mean we should commit to a kind of "gconf key stability"
and that all gconf keys should be documented? If so, would this be for
all modules? Or just the modules in the platform? Or...

> 2. In each module's release notes, have a list of newly-added APIs.  You
> can see that (1) and (2) are sort of tied together; if (1) happens, (2)
> is nearly effortless.

Maybe having a list of newly-added APIs (or a list of links to pages
containing those lists) in the "For developers" section of the .0
release notes could also help.

> 3. Let's keep track of modules whose fixed/total bugs ratio didn't
> increase during each release.  I'm not sure how this will work for
> Special(tm) modules like GTK+ which have a million API requests, but
> people don't ever follow up on them --- maybe GTK+ just needs to make a
> decision and WONTFIX them after some time unless the reporters care
> enough to implement the stuff themselves.

What's the goal of this? :-)
What happens if the ratio does increase?

> 4. dotplan and ReleasePlanning are more or less the same thing.  Can we
> deprecate dotplan and just redirect it to ReleasePlanning?  Any missing
> sublinks from dotplan should get moved to the wiki.

Agree. There's some pages to move, though.

> 5. We have talked about this in the past but have not formed concrete
> plans.  Sometimes we find things that should be improved or made
> consistent across the whole desktop --- a magic new API that solves a
> problem for everyone, a consistent mis-use of some clipboard type, etc.
> How can we get people to know about this information, and have them fix
> things on time?  Is it just an organizational issue?

A first step is to send a mail to devel-announce-list, IMHO. Someone
should also come with concrete examples of where the magic new API
can be useful (list of modules, list of cases, etc.). People will then
know about it. However I'm not sure we can make sure that people will
fix things on time.

It reminds me that I wanted to see all modules switch to


Les gens heureux ne sont pas pressés.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]