Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.1, 2.2
    • Fix Version/s: 2.1.1
    • Component/s: Groups
    • Labels:
      None
    • Rank:
      18016

      Description

      The problem is that removing user from cohort often leads to dropped enrolment which may result in loss of grades, groups, et.

        Activity

        Hide
        Sam Hemelryk added a comment -

        Thanks Petr - integrated now

        Show
        Sam Hemelryk added a comment - Thanks Petr - integrated now
        Hide
        Eloy Lafuente (stronk7) added a comment - - edited

        oh, oh, Sam, Petr!

        It seems we are having 100% different ways and approaches to submit for integration and integrate issues like this.

        For example this issue. Only has been integrated into master, because only the master branch was available and no comment from the developer was pointing to cherry-pick i for 21_STABLE.

        But, in the other side, Petr put fixfor versions for this being 2.1 and 2.2.

        So it's not clear for me what should be done. I've been backporting others like this to 21_STABLE, lalala. See these:

        http://tracker.moodle.org/browse/MDL-28270 (there is at least one integrated by me)

        IMO, we should:

        1) not use fixfor versions at all. We use them only at the end to point to which releases will include officially the fix (stable ones OR dev one).

        2) decide the target branches by:

        a) submit as many branches as necessary. That avoids any double interpretation.
        b) submit only master but comment in the submit message about the target branches.
        c) initial (1-2-3) weeks (where we are now), no dev stuff should arrive so assume anything going only to master must go to latest stable (unless clearly stated the opposite)
        d) ask

        Clearly a) and b) are the best ones because they don't lead to problems. c) is one interim situations for 1-2-3 weeks. d) is the last resort.

        Ciao

        Show
        Eloy Lafuente (stronk7) added a comment - - edited oh, oh, Sam, Petr! It seems we are having 100% different ways and approaches to submit for integration and integrate issues like this. For example this issue. Only has been integrated into master, because only the master branch was available and no comment from the developer was pointing to cherry-pick i for 21_STABLE. But, in the other side, Petr put fixfor versions for this being 2.1 and 2.2. So it's not clear for me what should be done. I've been backporting others like this to 21_STABLE, lalala. See these: http://tracker.moodle.org/browse/MDL-28270 (there is at least one integrated by me) IMO, we should: 1) not use fixfor versions at all. We use them only at the end to point to which releases will include officially the fix (stable ones OR dev one). 2) decide the target branches by: a) submit as many branches as necessary. That avoids any double interpretation. b) submit only master but comment in the submit message about the target branches. c) initial (1-2-3) weeks (where we are now), no dev stuff should arrive so assume anything going only to master must go to latest stable (unless clearly stated the opposite) d) ask Clearly a) and b) are the best ones because they don't lead to problems. c) is one interim situations for 1-2-3 weeks. d) is the last resort. Ciao
        Hide
        Sam Hemelryk added a comment -

        Hi Eloy,

        Quite right sorry this should have to 21_STABLE as well, I have been cherry-picking many of the simple improvements to MOODLE_21_STABLE as well.
        I'm not too sure why I missed this one sorry.
        As for the options - certainly A + B, I'm happy with c for most situations (new features obviously need careful consideration) and D for when I'm feeling like a noob!

        Did you cherry-pick this to MOODLE_21_STABLE? I'll check shortly and if not I will do it before this is tested.

        Cheers
        Sam

        Show
        Sam Hemelryk added a comment - Hi Eloy, Quite right sorry this should have to 21_STABLE as well, I have been cherry-picking many of the simple improvements to MOODLE_21_STABLE as well. I'm not too sure why I missed this one sorry. As for the options - certainly A + B, I'm happy with c for most situations (new features obviously need careful consideration) and D for when I'm feeling like a noob! Did you cherry-pick this to MOODLE_21_STABLE? I'll check shortly and if not I will do it before this is tested. Cheers Sam
        Hide
        Petr Škoda added a comment -

        I personally think we are backporting too much because the release cycle is much shorter now.

        Sorry for the confusion, I will select only fix version that has patch brach.

        Show
        Petr Škoda added a comment - I personally think we are backporting too much because the release cycle is much shorter now. Sorry for the confusion, I will select only fix version that has patch brach.
        Hide
        Eloy Lafuente (stronk7) added a comment -

        Sam: no I've not picked this to 21 stable.

        Petr: very first weeks after release are about to bugfixing so "backporting master -> last stable" is the usual operation, unless it's a clear new dev issue or has been stated by the dev. (right now this "first weeks" behavior will be until 31 July (based in the 2.2. roadmap). So, in any case, a) and b) are the recommended ones IMO. Fixfor versions ignored.

        Thanks both!

        Show
        Eloy Lafuente (stronk7) added a comment - Sam: no I've not picked this to 21 stable. Petr: very first weeks after release are about to bugfixing so "backporting master -> last stable" is the usual operation, unless it's a clear new dev issue or has been stated by the dev. (right now this "first weeks" behavior will be until 31 July (based in the 2.2. roadmap). So, in any case, a) and b) are the recommended ones IMO. Fixfor versions ignored. Thanks both!
        Hide
        Petr Škoda added a comment - - edited

        Ideally there should not be any bugfixing after the release, scrum and pull requests were supposed to eliminate that, right?

        Show
        Petr Škoda added a comment - - edited Ideally there should not be any bugfixing after the release, scrum and pull requests were supposed to eliminate that, right?
        Hide
        Eloy Lafuente (stronk7) added a comment -

        ideally...yes, but... what the hell are we doing all the time but bugfixing?

        "should not be any bugfixing after the release" - just annotating that in my wall, LOL

        Show
        Eloy Lafuente (stronk7) added a comment - ideally...yes, but... what the hell are we doing all the time but bugfixing? "should not be any bugfixing after the release" - just annotating that in my wall, LOL
        Hide
        Eloy Lafuente (stronk7) added a comment -

        Tested, the message is there, thanks!

        Show
        Eloy Lafuente (stronk7) added a comment - Tested, the message is there, thanks!
        Hide
        Sam Hemelryk added a comment -

        Congratulations - this fix has just been released in the weeklies.

        Show
        Sam Hemelryk added a comment - Congratulations - this fix has just been released in the weeklies.

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: