OK...
I have created a tracker report and assigned it to me
I have coded a fix and pushed it as a branch to (my) GitHub (a branch with just the one commit)
Now what do I do?
It's just some language help file changes against 1.9, so I'm not really expecting it to be "fixed" but I'd like to make a link to the fix available in the tracker report. How do I do that? I can create a pull request but I don't know who I would send it to.
Confused... any de-confusion appreciated
EDIT:
I stumbled across 'compare view' in GitHub which appears to give a diff of the change. I put this in the 'Pull 1.9 Diff URL' field of the tracker report. Is that right?
That is part of it. You should also
- Click the 'request peer review' button.
- Fill in the 'Pull from repository field'
- FIll in the '1.9 fix branch' field.
- Be very patient.
It's a pity about that last one.
I'm going to sound very pathetic... who do I get to peer review it??
I'm not sure I understand the difference between 2 and 3.
As I say, I'm not terribly optimistic that this would be accepted now, but I'm considering it a low risk experiment. I haven't submitted a Moodle fix in a long time and I should really pull my finger out
It's MDL-28713 by the way
EDIT:
I put something in those fields by pure guess work... if anybody can be bothered to check my github links....
I'm not sure I understand the difference between 2 and 3.
As I say, I'm not terribly optimistic that this would be accepted now, but I'm considering it a low risk experiment. I haven't submitted a Moodle fix in a long time and I should really pull my finger out
It's MDL-28713 by the way
EDIT:
I put something in those fields by pure guess work... if anybody can be bothered to check my github links....
Pull from repository field should be the link that is given as 'Git read-only' in the github interface.
The X.X fix branch should be just the branch name.
Where there is a known Component maintainer, set them as the peer reviewer. In this case that would be David Mudrak. In other cases leave that field blank. Then Moodle HQ will look at it when they get the time.
The deed is done for better or worse.
I'm sure I'll be back with more questions soon
Thanks Tim!
I'm sure I'll be back with more questions soon
Thanks Tim!
Howard,
If you have never done this before how did you get this far?
I've devised a working pattern that I am happy with, but as far as I can see just fixing one little branch is not the way I was told.
As for Peer Review that's a laugh as you can sit there for weeks and no one does a thing. I tend to go straight for the jugular in this respect, and select Integration Review (I think it's called) which is like the old Pull Request.
Have you done the 'cherry picking' bit, where you add your fix to the Master? First time I did this it worked a treat, second time I tried and all hell broke loose, as I soon discovered that the Moodle version I was working on was not uptodate, it was on the Git Hub but I hadn't fast forwarded it. But they say you learn by making mistakes. LOL
Good luck.
Mary
To answer your first question: by fixing many bugs before the recent development process changes.
And, not everyone has permission to submit things for integration.
To be honest, I got out of the habit of submitting fixes because I haven't really had the time now I'm doing a lot of Moodle Partner related dev work. I'm been feeling a bit guilty about it. I also got shouted at by Petr a lot but it's made me a better person I'm sure
This was a bit easier because it really only applies to 1.9,so there's no Master branch to worry about.
I am reasonably comfy with Git now but I had to find my way around GitHub (which is cool but not terribly intuitive) and then to figure out how the hell the Moodle submission process now works (especially as it seems to keep changing !!)
This was a bit easier because it really only applies to 1.9,so there's no Master branch to worry about.
I am reasonably comfy with Git now but I had to find my way around GitHub (which is cool but not terribly intuitive) and then to figure out how the hell the Moodle submission process now works (especially as it seems to keep changing !!)
It's also worth noting that your commit message in github has to be in the right format, but what this is seems to depend on who subsequently does the integration!
As Tim Hunt explained to me in a previous discussion on this board, there's no consensus between the core developers. As I understand it, this means your pull request has a chance of being rejected by the integrator whichever one of the two commonly-used styles you use. (I have to say that in my case the integrator, Sam Hemelryk, kindly fixed my commit message - which was in neither of the commonly used styles - so I can't really complain!)
Hmmm... I read the linked post and I'm not sure I'm any better off.
I just did what I always did in the "Good Old Days" (TM). I put the tracker number followed by a brief comment about what the commit was. I think that was one of the options.
Why doesn't someone make a decision and then put it in the documentation in a place where nobody will ever find it?
I just did what I always did in the "Good Old Days" (TM). I put the tracker number followed by a brief comment about what the commit was. I think that was one of the options.
Why doesn't someone make a decision and then put it in the documentation in a place where nobody will ever find it?
Actually, the comit process is now more or less offically documented:
Exactly as I suggested....
http://docs.moodle.org/dev/Special:WhatLinksHere/Commit_cheat_sheet
(for posterity, at the time of writing nothing linked to the page).
http://docs.moodle.org/dev/Special:WhatLinksHere/Commit_cheat_sheet
(for posterity, at the time of writing nothing linked to the page).