For now and my own point of view i will stop commit directly in the master branch. Too much interaction between every developers.... I'm going to do only commits in my own fork and wait for a really stable and tested code before requesting for a merge in the master branch. I really think this is the simplest coding model. When code freeze will be anounced only bug fix merge should be accepted and before merging heavy test involving every developers should be done before merging bug fixes. This my own point of view. Branching should be only used for maintening bug fixes of notable versins ( as said for 1.x and 2.x).
I totally agree with Timo. With a small and flexible branching model, we can push the Shinken project to a new level, a more professional level.
Let's try it.
Am 09.09.2012 um 15:15 schrieb Timo Veith <firstname.lastname@example.org>:
> 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.
> 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