Re: How to propose a module for inclusion?



On 3/8/07, Andre Klapper <ak-47 gmx net> wrote:
ahoj,

Am Donnerstag, den 08.03.2007, 16:32 +0100 schrieb Vincent Untz:
> > so, silence means compliance?
>
> Yes, please go ahead. It'll be easier to edit the pages on the wiki
> anyway :-)

right. committed:
http://live.gnome.org/ReleasePlanning/ModuleProposing
http://live.gnome.org/ReleasePlanning/ModuleRequirements

i will link against ModuleProposing in the 2.19 schedule.

These are *awesome*.  Thanks.  Three small notes...
 - I moved some of the stuff around from ModuleRequirements to
ModuleProposing (judgement critieria for new modules).
 - I added some clarifications and additional details
 - I fleshed out the ModuleRequirements, like I've been promising to
do for over a year now.
...and a quick question:
 Are all the judgement criteria for new modules still relevant?
(gnome-config vs. gconf, for example)  Complete?  I didn't have time
to read over it all.

Anyway, in more detail about my changes:
- Moving stuff:
The judgement criteria for new modules was listed in the
ModuleRequirements page rather than that ModuleProposing page, which
seemed a bit odd to me.  Since it is predominantly criteria for
judging new modules rather than requirements for existing modules
(e.g. 'no repeatable crasher' would suggest that evo and nautilus
should often be removed from the desktop release which we have never
done), I didn't think it fit.  So I moved it to the ModulesProposing
page, with some slight change in wording to make it fit.

- Clarifications, additional details:
I don't remember all the changes I made.  The major one was spelling
out in detail what the proposal email should contain.  As far as other
clarifications, one example is that the usage of GNOME FTP is not
merely encouraged.  It's mandatory.  (Our release sets are defined by
tarballs on GNOME FTP, so not uploading tarballs to GNOME FTP mean
that the tarballs are not part of the release set.  Period.)

- Fleshing out the module requirements
I added lots of details to the module requirements.  Which release
sets can depend on which other release sets, modules must always be
buildable, subscribing to d-a-l, branching notifications, keeping up
with releases, version numbering, follow freezes, etc.


Comments welcome.

Thanks Andre,
Elijah



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