How to become a 3rd Party Package =================================
- The community (core committers) have to vote on allowing the application
in CVS.
The Vote has to be made by an existing core committer.
- A committer (not necessarily the same person who made the vote) needs to maintain the code. It is possible to make someone a committer for the
express
purpose of maintaining 3rd-party code.
- As such, the package needs to have a committer supporting it.
- A package that is not maintained can be removed from CVS if nobody desires
to
maintain it further.
- The release manager decides which packages are included in a distribution.
- The core committers decide which package gets the status
'community-maintained'.
A community-maintained package no longer requires a specific committer to maintain it, though a core committer will be typically assigned to
overview
and approve changes.
Ok, looking at the changes between this one and the original vote:
- All code submitted must follow the MPL. This may change later, but we don't want a full discussion on licenses right now.
> - The recommended license for these kind of packages is the MPL or any > compatible > (BSD-like) license.
You propose a slighty more relaxed license policy, which I persoanlly don't have issues with, but which is a discussion I didn't want to start yet. If nobody else objects I don't mind this chnage.
- All code must follow MMBase code conventions and have documentation (or aim to fulfill these requirements as soon as possible).
Was dropped. As I wrote earlier, this is not really an 'extra' rule, it is applies already. So even if I drop it in the vote, it still applies in general. In the end though code conventions are mostly guidelines.
One thing that I do think important is that projects use the same build process (where appicable). If a package doesn't, there is no way to distribute that package, except when people build it themselves in cvs using their own tools.
Note that I don't mind 'maven' for this (even though I don't know how to use it), but as currently the ant builds work, I would suggest that if soemone desires this it be done by a project (a Distro II project perhaps), and therefor it is not part of the vote.
- The application/component must be generic, useful, and applicable with a broad enough systems and configurations of MMBase (i.o.w., no vendor-locking).
Was dropped. I think though that this (or something smilar) should be included as it allows people to judge packages for inclusion, and re-affirms that they can use their own judgement.
- A committor (not necessarily the same person who amde the vote) needs to maintain the code. It is possible to make someone a committor for the express purpose of maintaining 3rd-party code (with the expected limitations on such a committor's rights to change code), but an existing committor should [still call the vote].
(note: last bit got dropped in the original vote mail for some reason) This is bacically left the same but formulated in a different way.
No other changes to the call. As to:
> -1 because there isn't a text explaining what is offered to 3rd > parties when the cvs is open.
I still so not fully understand what that has to do with the vote itself. Writing such a tekst is obviously something that should take place, as is creating those needed facilities (i.e. a webpage for information and/or documentation). However the latter takes some time.
Note that I did include some text:
Asside from a location in CVS, the application should get a place on the MMBase website where documentation and progress can be added. This place currently does not exist, and should be added (do not expect this to happen immediately - should be done though).
It could have a similar structure as the projects page. It may also be included, when applicable/possible, in the package manager once that is fully functional on mmbase.org.
Which is not a full description but an indication of what we expect that we can offer in the short term.
-- Pierre van Rooden Mediapark, C 107 tel. +31 (0)35 6772815 "Anything worth doing is worth overdoing." _______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
