On, Tue Jul 25, 2006, Simon Wittber wrote: > On 7/25/06, Peter Shinners <pete@xxxxxxxxxxxx> wrote: > >On Mon, 2006-07-24 at 22:36 +0800, Simon Wittber wrote: > >> Let's build a pygame-contrib package, which is distributed with the > >> pygame installers. The package contains contributed tools and > >> utilities, which might be candidates for the pygame distribution. > > > >I think there's some good reasons to do this. Arguably there are niche > >parts of Pygame that belong more in a package like this. Things like > >sysfont and color (maybe even sprites). > > If we keep contrib stuff out of pygame, there is one other thing which > needs to be thought about. How are contributions 'blessed' and > guaranteed to work for some period of time? Should there be a stable / > experimental set of packages? I think this is what you mean by Gnome > eggs. We just need a stable package to 'roll up' to. > > Here is a potential implementation plan. Comments appreciated. > > 1. Document the aim and goals of pygame-contrib, so that it is not > confused with pygame itself, and users (all of us) understand what it > is for. Why not adding a pygame.contrib module directly and/or, like python does, a pygame.future module for unstable or freshly adopted code? In those modules small snippets can be evaluated, fit with pygame and, and, and... Larger code parts or complete modules could be added as direct submodule using pygame.MODNAME. This way, you can solve the following problems easily: * package synchronisation * flame wars about code XYZ that did not go into contrib - if the direct pygame maintainers and/or developers say no "because of this or that", the acceptance of the decision might be better. * people do not need to download x different packages, but instead can stick with (x-n) and use pygame.MODNAME, pygame.future, * pygame.contrib, ... for their needs. Contibutions however should not have any dependencies besides python and pygame and their direct dependencies, but must support anything, pygame does, e.g. compatibility to OPENGL in some way, but not a (necessary) dependency to PIL. Not because I hate to install X deps (I really hate that, but that's not the cause here), but because pygame seems to become more interesting for several embedded devices and platforms and is widely supported on various platforms currently. Adding new necessary dependencies just through some contributions would lower its availability range and that would not be a good deal. > 2. Choose a maintainer or two. This should preferably be a willing > volunteer with plenty of time (at least for the next few months) for > this kind of work :-) Not only the next few months, if you do not want to see it dying after a short amount of time. > 3. Document the veto powers. BDFL style, or design by committee? > Document acceptance criteria. Eg PEP-8 style guide (or pygame style if > pygame style is different to PEP 8), LIcense etc. Document submission > process. Document the 'blessing' process. Need to keep these documents > as short and simple as possible. Wiki pages might do. Absolutely necessary. I'd prefer PEP style and maybe a short resume for those who are not that familiar with PEPs (pygame seems to be an introdcution platform for many people, who are new to programming and python). > 4. Create new svn folder in pygame SVN. See above, create new folders pygame.XXX :). [...] Regards Marcus
Attachment:
pgpfbYkB6H48g.pgp
Description: PGP signature