Hi, Before I do the same mistake a second time: if your mail was not saying "we should do something like this for the Mozart2 VM", then do not pay too much attention to the two first paragraphs, and start reading at "For now, our contributing rules are simple". ;-)
This could be imitated ... from the first stable version of Mozart2 on. Before we reach that point in the development, there is one rule: make progress. And any contributing rules will *slow down* that progress. Do not misunderstand me (I have always had difficulties expressing myself accurately in writing, I always look too harsh - that's what my friends say): I do believe this is a good set of rules for ZeroMQ. This project is already *mature*, and hence is essentially issue-driven. As a starting project, we are not issue-driven, but rather progress-driven. So this set of rules cannot apply to Mozart2 as it stands now. For now, our contributing rules are simple: - Get in touch with me to find something of interest to you, that I think can be done now, given the current state of the codebase. Some ideas there: https://github.com/mozart/mozart2/wiki/Roadmap - Fork and start hacking. Two tools that can help you: https://github.com/sjrd/mozart-app-test and https://github.com/sjrd/mozart2-libmozart-experiment - Prepare "test cases", for example simple .oz files that can be compiled by the bootcompiler and executed, and that illustrate the features that are implemented in the pull request. These can be stored e.g. in a Gist https://gist.github.com/ -- not in the commits themselves -- and mentioned in the text and comments of the pull request. - Unit tests - in vm/test/ as actual commits - are better, of course, but as I don't write them myself, I cannot demand that you do so. - Make a pull request. Pull requests are never merged as is. We have decided to keep a linear history, so they will always be rebased instead. Besides, we are very sensitive about the quality of each individual commit, so it's likely we will rewrite the history a little bit, but we make sure your name remains attached to the commits (git is great for that!). We accept code that is well formatted, follows the guidelines, and is accompanied by convincing test cases (hence is correct "beyond a reasonable doubt"). That's pretty much it. Let us not put a burden on ourselves with many administrative things. What's important now is *progress*, i.e., *code*and/or *documentation* of the codebase. Regards, Sébastien On Sun, Mar 18, 2012 at 21:30, stewart mackenzie <setor...@gmail.com> wrote: > Hi All, > > Pieter Hintjens over at iMatix in Belgium is formalizing a contract > for code contribution. > > http://rfc.zeromq.org/spec:16 > > I recommend we take a serious look at this. > > Kind regards > Stewart >
_________________________________________________________________________________ mozart-hackers mailing list mozart-hackers@mozart-oz.org http://www.mozart-oz.org/mailman/listinfo/mozart-hackers
