I amn't seeing "critical" issue.
only install script issue, or webui no ?
No "core" issue, so you can update your production server no ?
2012/9/9 david hannequin <david.hanneq...@gmail.com>
> 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 <david.hanneq...@gmail.com>
>
>> 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 <napar...@gmail.com>
>>
>>> On Wed, Sep 5, 2012 at 8:56 PM, Hartmut Goebel
>>> <h.goe...@crazy-compilers.com> 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
>>> Shinken-devel@lists.sourceforge.net
>>> 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
>> listShinken-devel@lists.sourceforge.nethttps://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
>> Shinken-devel@lists.sourceforge.net
>> 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
> listShinken-devel@lists.sourceforge.nethttps://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
> Shinken-devel@lists.sourceforge.net
> 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
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
