Nico Klasens wrote: > > 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. > > It is third party code and that shouldn't have to follow our code > conventions. When it want to become a community package then it has to > comply. And like you write it are guidelines (best practices).
I would be fine with the rule: 'Third party code must be subject to code conventions, preferrably ours'. Especially, of course, if the code could possibly even become a 'community' application. > > > 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. > > It is third party and the maintainer is responsible for it. If it can't be > build in the way we build then it is his/her problem. If we have a build > process that is suitable for most cases then others will likely use it. For this I would be fine with something similar: 'Third pary code must build, preferrably in our way'. Similar build processes for different applications is advantageous in some ways, as e.g. Ernst pointed out. I agree, but find it more important that code becomes open and 'near' MMBase, than this technicality. 'Preferrence' does not make real rules, but could give you a handheld for a abstain, or could make your argument for a -1 stronger. Since it is only a preference it cannot be the sole reason for a negative vote. > People who want to make things open source should answer the question: why > do I want to make it open source? > Personnally, I would never open source WIAB, LeoCMS or Surfnet. Not because > they aren't great sources to learn from, but they are too specific for a > customer and there is too much functionality in there everyone don't want. I think this is actually the precise reason why it was doubted that these kind of things should find a place in our CVS. Of course this implies that we prefer their reusable _components_. Btw, if someone would propose these, they still can be added as long as the +3 criterium is satisfied. > > > > > -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: > > I want a text to clarify to a potential third party what the vote is all > about. I am confident that every committer wants the same thing as you want. > It is quiet clear for us what we want, but an outsiders will still have lots > of unanswered questions after your vote. The vote is targeted to us. The > text should describe our opinions and should be targeted at third parties. > Hopefully, third parties will follow our mindset after reading the text. I > like the text to be present at the vote so we know what we are communicating > to third parties. Of course everybody welcomes such a text, but as it is more-or-less clear what it would say, I don't see the objection against the vote 'an sich'. Michiel -- Michiel Meeuwissen mihxil' Mediacentrum 140 H'sum [] () +31 (0)35 6772979 nl_NL eo_XX en_US _______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
