Hi,

i had compilation error due eue module on version 1.2. Eue module is normaly in devel version.

However, I installed 1.2 with shinken installation script on a virtual machine squeeze. I saw that there are bugs open on the installation script for the addon and plugins.

In the WebUI, the menu shinken can not access Skonf.

All this tells me is that we have not tested this version enough.

Best regard

Le 09/09/2012 11:09, Olivier Hanesse a écrit :
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 <mailto: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
    <mailto: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 <mailto:napar...@gmail.com>>

            On Wed, Sep 5, 2012 at 8:56 PM, Hartmut Goebel
            <h.goe...@crazy-compilers.com
            <mailto: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
            <mailto: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  
<mailto: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
        <mailto: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  
<mailto: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
    <mailto: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

------------------------------------------------------------------------------
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

Reply via email to