Re: First ideas



More carrot, less stick?
Luis

On 11/17/05, Federico Mena Quintero <federico ximian com> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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?
>
>
> I'd really like to nail (1), (2), and (4) for the 2.14 release.
> Thoughts?
>
>   Federico
>
> _______________________________________________
> release-team mailing list
> release-team gnome org
> http://mail.gnome.org/mailman/listinfo/release-team
>



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