Submitting patches to PyMT

[Jonathan Gossage]

I have just started working with PyMT and have discovered a few
problems that I would like to submit patches for. I have been unable
to find a clear description of the procedure but I think I may have
pieced most of it together. If I am wrong about anything I would be
most grateful for some guidance.

1. Fork the PyMT repository on Github.
2. Clone my fork (jfgossage/pymt)
3. Create a local branch for the area under investigation.
4. Create or upgrade an automated test to show the flawed behavior.
5. Debug PyMt to uncover the reason for the flawed behavior.
6. Create a fix in my local branch.
7. Verify that the automated test now passes.
8. Commit my changes in my topic branch
8. Merge my changes into my local master branch.
9. Pull the most recent changes from tito/pymt
10. Push my changes to my forked repository on Github
11. Create an issue in the PyMT issue tracker that references the
commit which contains the patch for the problem
12. I am not certain about the next step as the instructions on Github
are generic. Is this sufficient or do you also want a Github pull
request or some other notification of the availability of a patch.

Incidentally, my project is investigating the effective use of multi-
touch capabilities for natural language text editing so I will be
likely concentrating on the textarea and textinput widgets.

[Mathieu Virbel]

Hi Jonathan,

Thanks for this precious explanation. Can you add it on the
http://pymt.eu/wiki/DevGuide/HowToContribute page ?

Even if some people don't do the 11, it's still very very nice to have
an issue associated to the pull request.
If the 11 reference the commit or branch to pull, it's ok.
Or if you use the "Pull Request" method, we can easily integrate
changes too. "Pull Request" is faster, but not associated to the
issue.
Also, changes shuold be pulled from a specific branch. User shouldn't
commit lot of fixes on his master. Otherwise, it's impossible for us
to determine which commit is good for merge or not.

About the next, can write how to update your branch after your fixes
have been merged ?

Thanks !

Mathisu

2010/8/17 Jonathan Gossage <jgos...@gmail.com>:

> --
> You received this message because you are subscribed to the Google Groups "pymt-dev" group.
> To post to this group, send email to pymt...@googlegroups.com.
> To unsubscribe from this group, send email to pymt-dev+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pymt-dev?hl=en.
>
>

[Christopher Denter]

Jonathan,

that is the ideal workflow, yes. You've put it together quite nicely. If you'd also create a pull request we'd be more than happy.
I'm sorry that the docs are lacking a good 'How to contribute?' page. Up to now I've been telling people individually, but I feel that I have to write one now.

If you're familiar with IRC, a good way to get in touch is also our IRC channel #pymt on irc.freenode.net.

Feel free to ask questions or open issues as you see fit.

Thanks and welcome!

Christopher

On Aug 17, 2010, at 3:57 PM, Jonathan Gossage wrote:

> s into

[Jonathan Gossage]

As I understand it then, you would like each patch to be submitted as
a separate branch in the forked repository? Once I am certain on this
point I would be happy to update the contributors' guide on the wiki
with these instructions.

On Aug 17, 10:26 am, Mathieu Virbel <txp...@gmail.com> wrote:
> Hi Jonathan,
>

> Thanks for this precious explanation. Can you add it on thehttp://pymt.eu/wiki/DevGuide/HowToContributepage ?

>
> Even if some people don't do the 11, it's still very very nice to have
> an issue associated to the pull request.
> If the 11 reference the commit or branch to pull, it's ok.
> Or if you use the "Pull Request" method, we can easily integrate
> changes too. "Pull Request" is faster, but not associated to the
> issue.
> Also, changes shuold be pulled from a specific branch. User shouldn't
> commit lot of fixes on his master. Otherwise, it's impossible for us
> to determine which commit is good for merge or not.
>
> About the next, can write how to update your branch after your fixes
> have been merged ?
>
> Thanks !
>
> Mathisu
>

> 2010/8/17 Jonathan Gossage <jgoss...@gmail.com>:

[Mathieu Virbel]

Yes, one branch per bug / feature = ideal.

2010/8/17 Jonathan Gossage <jgos...@gmail.com>:

[Jonathan Gossage]

A further suggestion. Would it make sense to create the issue before
starting work on the bug/feature and to name the branch after the
issue e.g iss325. This would clearly tie the branch to a specific
issue and would provide earlier notification that a bug/feature was
being worked on.

Thoughts?

On Aug 17, 12:13 pm, Mathieu Virbel <txp...@gmail.com> wrote:
> Yes, one branch per bug / feature = ideal.
>

> 2010/8/17 Jonathan Gossage <jgoss...@gmail.com>:

[Christopher Denter]

Thanks for your input.

However, that would only be visible to others when the branch is actually being pushed to the remote.
Our way of doing that is that you assign the issue to yourself. Google code allows you to set an 'owner' for an issue, which is what we use for that.
If it's already owned by someone, probably talk to that person first.

Christopher

[Jonathan Gossage]

Do I need any special status to make myself the owner of an issue? I
was unable to find any way to do this.

On Aug 17, 2:28 pm, Christopher Denter <den...@the-space-station.com>
wrote:

[Christopher Denter]

I'm not entirely sure, but I don't think so.
The interface just isn't that discoverable. Click the white box at the bottom of an issue report and a few more boxes should pop up by some javascript magic where you can set an owner/assignee.
If not, let us know so we can add your account to the list of people with access (if there is any).

Christopher

[Mathieu Virbel]

Owner on google code is not the contributor, that's not a problem.
Just a way to known how we can split work / manage work in the core
team. Contributor still have his credits inside the commit :)

2010/8/17 Christopher Denter <den...@the-space-station.com>: