Re: [Shinken-devel] stable or develop -- we need a branching model
Status: Beta
Brought to you by:
naparuba
From: david h. <dav...@gm...> - 2012-09-09 09:01:15
|
Hi, List of issue report since 10 day :-(. Le 09/09/2012 10:52, Olivier Hanesse a écrit : > Indeed, > > Next time, I think we need to release the RC and wait at least 2 > weeks(1 month) before making it "stable". > But this version 1.2 was kinda "special" ;) > > David, what bugs are you talking about ? > > A new tag aka 1.2.1 will be out soon I think, we need to correct them > before. > > Olivier > > 2012/9/9 david hannequin <dav...@gm... > <mailto:dav...@gm...>> > > Hi, > > I can't update shinken in 1.2 on my production server because > version 1.2 is unstable ( and there lot of bug ). So that why i > think we need more test before final release. > > Best regard > > Le 06/09/2012 15:35, Olivier Hanesse a écrit : >> I agree with nap >> >> One exception : in the future, with the "2.0" release, AND if >> this release is breaking a lot of things (full redesign, >> configuration changes etc..), we can maintain a 1.x stable with >> bugfix. >> Otherwise, I think it is useless. >> >> Olivier >> >> 2012/9/6 nap <nap...@gm... <mailto:nap...@gm...>> >> >> On Wed, Sep 5, 2012 at 8:56 PM, Hartmut Goebel >> <h.g...@cr... >> <mailto:h.g...@cr...>> wrote: >> > xkilina wrot in https://github.com/naparuba/shinken/pull/567: >> > >> >> Well, we should aim to have everything ready by friday. So >> come monday >> > morning, new users can download 1.2.1 and get cooking. >> After that 1.2.2 >> > for whatever comes out of next week or the two weeks after >> that... >> > >> >> Which is why we need to have the discussion about stable >> versus dev. >> > >> > Here is my opinion: >> > >> > First of all you need to decide whether then 1.2.x-releases >> should be >> > bug-fixes only or also contain other changes. >> > >> > After this I recommend having a look at >> > <http://nvie.com/posts/a-successful-git-branching-model/>. >> I have >> > learned a lot of it and am using this model for my >> projects. I recommend >> > using this model (or a slightly adopted version). >> > >> >> Hi, >> >> It's a really good question. I think such a heavy model is >> great when >> you have all in-house dev, where you can easily add some >> shell things >> to manage it easily (I remeber about such a shell project on >> github >> for managing this model), but will kill participation for new >> commiters. If I take my example, if I see that there are su much >> branch on a project, I'll only manage a patch on my side and >> don't try >> to learn all project branch when I will send a pull request. >> Remember >> than most commiters on this project are admins, not dev. >> Asking them a >> pull request with great code and comment is already great, >> asking them >> to learn all branching things is just too much in this realm. >> >> Of course we got some huge works in progress in dev, and this >> is good. >> Let take an example of a hugely moving item : the WebUI. When >> we moved >> from Mootools to JQuery, Andreas create a devel branch where >> we get >> back all things in WebUI (and it took months :p ). This is a >> great >> way. One level of branching is great for huge things. More is >> it just >> too much. >> >> Then there are minors things, like fixing typo, a new test, a >> bug fix >> or a small feature that is not activate by default (so no >> impact). >> Such things don't need a branch. the dev should know if a >> branch is >> need or not. If he doesn't know, then the good thing is to >> create a >> branch then. >> >> But remember than each branch will make the merge harder, >> even if with >> git it's more a pain in the ass than svn or cvs. It's still >> different >> codes to merge in the end, so always more difficult than just >> a trunk. >> >> I don't also think that it's up to the community project to >> manage all >> bug backporting. I more see then project as Fedora, not as a >> RedHat >> like one. If people want stability and bug fix on a 2years >> version >> because they fear too much a change, they can ask to an >> integrator for >> this. It's their job. The project should allow people to >> propose new >> features and ideas. Putting too much branch things is a good >> way to >> kill this. >> >> So we must rely on the test cases for knowing if we break >> something or >> not. Tests should never be broken on master, because this >> version can >> be the next version from a day to another. If there is a bug, >> it means >> that there is a flaw in tests, and they must be enhanced. >> But asking >> for a stable-branch is like saying "ok we got test cases but >> we don't >> really got faith in them". So if something new breaks test, >> it must be >> put in branch too until this is fixed, or is waiting in a >> pull request >> until so :) >> >> I think the "if it breaks something or change user habits too >> much >> from the last version, put it in branch" is a light and good >> way. So >> the pull requests of new commiters are still in master, but pull >> requests are like a branch that don't break master until we >> really >> merge them. >> >> What others are thinking about this? Where should be put the >> cursor >> between "RedHat stable + backporting" and "Gnome3/KDE4 that >> breaks all >> each release" ? :) >> >> >> Jean >> >> ------------------------------------------------------------------------------ >> 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 >> Shi...@li... >> <mailto:Shi...@li...> >> https://lists.sourceforge.net/lists/listinfo/shinken-devel >> >> >> >> >> ------------------------------------------------------------------------------ >> 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 >> Shi...@li... <mailto:Shi...@li...> >> https://lists.sourceforge.net/lists/listinfo/shinken-devel > > > ------------------------------------------------------------------------------ > 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 > Shi...@li... > <mailto:Shi...@li...> > https://lists.sourceforge.net/lists/listinfo/shinken-devel > > > > > ------------------------------------------------------------------------------ > 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 > Shi...@li... > https://lists.sourceforge.net/lists/listinfo/shinken-devel |