Hi, the Shinken project has a great future perspective I believe. As I am still somewhat new in the project, I would like to gently propose to adapt the branching model which Hartmut mentioned. I've read through the article and it is easy to understand how it works. I don't think that it should be considered to be a heavy model.
As far as the shell scripts are concerned, they could be put into the projects file tree just like the install script, but in a separate directory. Then only the core developers of the project decide when to do version bumping for example. Others shall not touch this. And if they do, their changes just won't be incooperated into the origin. So every new participant could read that article and also some very few lines of descriptive text of how to contribute to the project. Something like "clone the repo from github, checkout the development branch and start coding your changes. Then make a pull request". So they just don't have to do all the branching in the first place. Only one branch. That shouldn't be too hard for admins, too. As you know we already have a wiki page which describes how one can participate and contribute code. It could be added there, e.g. For bigger changes and feature additions which a Shinken developer only starts if he/she is more experienced and a longer project member, it should also be easy to adapt the branching model. Those developers would have "two levels" of branching then. Doesn't sound much to me. New feature branches and their meaning could be introduced on the mailing list. I don't know if github provides something similar, but I doubt that "issues and comments" may be the right place for that. With a short descriptive text every project member has a chance to get to know and read about the sense of the branch. Another idea: put a README.<branchname> in the root. That way, code collisons when merging and needlessly doubled work could probably be foreseen. I am not a git pro, but what I have read so far is that branching and merging is made very easy with it. If we would get a tidy project through it, so why shouldn't we try to use it? Every serious project that I have get to know of, maintains some kind of stable, testing and/or unstable trees. The user can decide if he goes with the stable version or tries the unstable one and reports bugs etc. Also, if we don't introduce the stable/testing manner but start using the branching model now, we were able to so easier later on. We were kind of prepaired, if we started to adapt it just now. So this would be some step between the "RedHat" and "Fedora" practice. Maybe some developer would then stand up and commit himself to maintain a certain release branch, do hotfixes and bug backporting. With a branching model already in use, it would at least be easier to do so for him. Developers are often employed somewhere and are at their work in charge for the same stuff they are also contributing to in the community. So the employers and the developers have an interest in stable versions. Let me conclude. If we would use the branching model, small code fixes could also be added to a "develop" branch by new commiters (just one more level). Big features like the logging thing which has broken user experience could be swapped out to a feature branch. So that a new main versions behaves more as expected to users. There already were examples in Shinken where branching was used for big features. So I propose to combine the light approach which is currently used with the branching model. Timo ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Shinken-devel mailing list Shinken-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shinken-devel
