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

      Description

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

        Gliffy Diagrams

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