Now that Umbraco v4 is going ahead, and there's a clear understanding that pull requests should be expedited, i would like to get back to fixing some bugs in Umbraco.
I did notice on Codeplex that I can only create a single pull request for each fork. Once before I ended up fixing 3 issues in a single pull request. But that makes the request more difficult to accept, right?
I also don't quite understand if I should just fork the main code, or switch to a specific branch before I fork. Does that make any difference, or should I just ignore the branches?
PS. I'm a beginner when it comes to Mercurial, so maybe it's just a matter of experience.
Also, should I even be looking at the list of issues on Codeplex anymore? I know it's being migrated to YouTrack, but I can't add issues on YouTrack. So if I know something that could be fixed, I would first create an issue on Codeplex, then attempt to fix it, and finally submit a pull request using the Codeplex work item ID.
Maybe this is something else that can be added to the guidelines?
One pull request per issue is certainly preferred (which would mean a fork per pull request). If the bugs are highly related, you could probably lump them together in one pull request.
You can only for the whole repo, not a single branche. However, try to apply your patches to the future branche (see roadmap, currently 4.9.0).
Just a note: you'll currently find it very painful to fork, and then clone (will take you about 15-30 minutes for each fork I estimate). This is because the repo is too large and Umbraco HQ is trying to get it shrinked in the next few weeks.
So as an alternative, you could also just clone the main repo, and commit to your local version. When you're done committing, you can export the changeset as a patch and include it in the issue you're fixing. However, I don't know how that works with attribution (if your name will be associated with the changeset once the patch gets accepted).
Finally: the HQ is hoping to get some help from MS with disabling the issuetracker on Codeplex so we can move to YouTrack completely. In the mean time, the YouTrack issues are just there for roadmap tracking and everyone else should be using the Codeplex issue tracker that will be imported into YouTrack when the time comes.
Hope this helps. I've notified the HQ about updating the guidelines, thanks!
Yeah, I noticed exactly that about the forking process, it takes a long time...
When exporting a patch, I should attach it to a comment on the Codeplex issue, right? Then do I need to notify someone of the patch, or just hope it get's noticed?
The reason I ask is because I would contribute mainly to fix things that bother me or my coworkers (like silly exceptions, visual bugs and other 'minor' annoyances). I'm not sure it'll get noticed as a patch on a Codeplex item when the core team is doing fast iterations using YouTrack issues as input.
Yes, you can attach them to the codeplex issue indeed.
Morten Christensen and Aaron Powell are monitoring the codeplex issues, and I'll be keeping an eye out as well. At the retreat we did discuss the HQ needing to be more responsive to community contributions, so I imagine that each sprint will contain a "workitem" (if you can call it that) to evaluate and integrate patches from the community.
Contribute: how to fork and what to fork?
Now that Umbraco v4 is going ahead, and there's a clear understanding that pull requests should be expedited, i would like to get back to fixing some bugs in Umbraco.
I was reading up on http://our.umbraco.org/contribute/working-with-the-umbraco-source under the Contribute section of Our Umbraco. For me it's not clear if I should create a new fork for each change, nor what the consequences are if I make a mistake.
I did notice on Codeplex that I can only create a single pull request for each fork. Once before I ended up fixing 3 issues in a single pull request. But that makes the request more difficult to accept, right?
I also don't quite understand if I should just fork the main code, or switch to a specific branch before I fork. Does that make any difference, or should I just ignore the branches?
PS. I'm a beginner when it comes to Mercurial, so maybe it's just a matter of experience.
Also, should I even be looking at the list of issues on Codeplex anymore? I know it's being migrated to YouTrack, but I can't add issues on YouTrack. So if I know something that could be fixed, I would first create an issue on Codeplex, then attempt to fix it, and finally submit a pull request using the Codeplex work item ID.
Maybe this is something else that can be added to the guidelines?
One pull request per issue is certainly preferred (which would mean a fork per pull request). If the bugs are highly related, you could probably lump them together in one pull request.
You can only for the whole repo, not a single branche. However, try to apply your patches to the future branche (see roadmap, currently 4.9.0).
Just a note: you'll currently find it very painful to fork, and then clone (will take you about 15-30 minutes for each fork I estimate). This is because the repo is too large and Umbraco HQ is trying to get it shrinked in the next few weeks.
So as an alternative, you could also just clone the main repo, and commit to your local version. When you're done committing, you can export the changeset as a patch and include it in the issue you're fixing. However, I don't know how that works with attribution (if your name will be associated with the changeset once the patch gets accepted).
Finally: the HQ is hoping to get some help from MS with disabling the issuetracker on Codeplex so we can move to YouTrack completely. In the mean time, the YouTrack issues are just there for roadmap tracking and everyone else should be using the Codeplex issue tracker that will be imported into YouTrack when the time comes.
Hope this helps. I've notified the HQ about updating the guidelines, thanks!
By the way, to export a patch:
Yeah, I noticed exactly that about the forking process, it takes a long time...
When exporting a patch, I should attach it to a comment on the Codeplex issue, right? Then do I need to notify someone of the patch, or just hope it get's noticed?
The reason I ask is because I would contribute mainly to fix things that bother me or my coworkers (like silly exceptions, visual bugs and other 'minor' annoyances). I'm not sure it'll get noticed as a patch on a Codeplex item when the core team is doing fast iterations using YouTrack issues as input.
Thanks Sebastiaan!
Yes, you can attach them to the codeplex issue indeed.
Morten Christensen and Aaron Powell are monitoring the codeplex issues, and I'll be keeping an eye out as well. At the retreat we did discuss the HQ needing to be more responsive to community contributions, so I imagine that each sprint will contain a "workitem" (if you can call it that) to evaluate and integrate patches from the community.
is working on a reply...