Re: [Fwd: Re: New procedure for proposed modules]

["Elijah Newren" <newren gmail com>]

On 4/3/06, Andrew Sobala <aes gnome org> wrote:
> Slightly surprised that this is being held for moderation on
> gnome-hackers, and worried it will get lost in the ether, so bouncing it
> to r-t too.

Sorry for the really slow reply...

> As I understand it, this implicitly makes module inclusion slightly
> different for applications and libraries. A question to ask if I've

Yes.

> understood this correctly:
>
> If you're an application, then you get your module synchronised with the
> release cycle by 2.15.1. If you're crackful, the community should voice
> dissent straight away; if it doesn't, then you're accepted. By 2.15.4,
> you can only be vetoed for technical reasons (ie. those in GEP 10).
>
> If you're a framework (library, "su"-framework, etc.) , then the above
> applies, but you should get yourself used by other modules. By 2.15.4,
> you could be vetoed for technical reasons (GEP 10), but in general if
> you have widespread adoption by maintainers then that is a de-facto
> acceptance by the community. On the other hand, if you haven't got
> yourself used by other modules, it begins to look like the
> service-as-implemented isn't really wanted in GNOME.
>
> To summarise, the community makes an initial decision on applications
> and libaries straight away, but libraries also have to prove themselves
> as useful in-the-wild.
>
> Is that correct, or have I got the wrong end of the stick?

I personally think that sounds like a great way to put it.  This
wording makes our thinking look much more clear.  My rough take on
what the reasoning was is a bit more like: "Crap, we've sucked each
and *every* release cycle at getting module decisions done; we always
do it too late."  "Let's move it up so it gets done sooner!"  "Wait,
what about libraries -- should we necessarily veto e.g. epiphany using
iso-codes after 2.odd.3 just because they didn't realize such a good
lib existed for the feature they were adding?"  "Okay, let's allow
libs to be proposed later, if a module depends on them".

I've exaggerated a bit about how murky it looked on our end, but I
still think your way of putting it is clearer and I like it.  :)

Cheers,
Elijah