pull requests - advice

[Ricardo Pedroso]

I have created a pull request on github about contrib/redis_session.py
and I would like to make more modifications in the same file.

Should I wait to see if the the pull request is accepted or not and
then create another branch and do the modifications?

Should I make the modifications in the same branch (but then they will
be available in the same pull request)?


Ricardo

[Massimo DiPierro]

I see it. There 6 pending requests. Will merge tomorrow.

> --
> -- mail from:GoogleGroups "web2py-developers" mailing list
> make speech: web2py-d...@googlegroups.com
> unsubscribe: web2py-develop...@googlegroups.com
> details : http://groups.google.com/group/web2py-developers
> the project: http://code.google.com/p/web2py/
> official : http://www.web2py.com/
> ---
> You received this message because you are subscribed to the Google Groups "web2py-developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to web2py-develop...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Niphlod]

pesky case but without seeking massimo's intels maybe cancelling the PR, rebasing your changes to the latest master and resubmitting a PR should be fine. It's a corner case, though ^_^

[Ricardo Pedroso]

I will wait...

[Michele Comitini]

I would not worry too much, if you have doubts just pull from main repository (web2py/web2py on github) and merge resolving conflicts (if there are any), so that your tree is aligned and Massimo has less work to do when he does merge your changes back in main repo.

2013/5/14 Ricardo Pedroso <rmdpe...@gmail.com>

[Ricardo Pedroso]

On Tue, May 14, 2013 at 6:31 AM, Massimo DiPierro
<massimo....@gmail.com> wrote:
> I see it. There 6 pending requests. Will merge tomorrow.

Niphlod, since you developed the redis_session.py, are you ok with this:

https://github.com/rpedroso/web2py/commit/4c1dbf4e4084e851fb8523fad9c36d419f469db1

The other changes are mainly typo fixes

Ricardo

[Niphlod]

is it for the issue on having multiple applications with different namespaces ? I don't see any issue with it.

As for distributed locking, did you came up with something ?

[Ricardo Pedroso]

On Tue, May 14, 2013 at 12:30 PM, Niphlod <nip...@gmail.com> wrote:
> is it for the issue on having multiple applications with different
> namespaces ? I don't see any issue with it.

Yes. And to be able to have different redis connections, otherwise,
even with different arguments to RedisSession in different apps they all use
"the first and only one"

> As for distributed locking, did you came up with something ?

Not yet, but I will chase this.


Ricardo

> Il giorno martedì 14 maggio 2013 13:24:14 UTC+2, Ricardo Pedroso ha scritto:
>>
>> On Tue, May 14, 2013 at 6:31 AM, Massimo DiPierro
>> <massimo....@gmail.com> wrote:
>> > I see it. There 6 pending requests. Will merge tomorrow.
>>
>> Niphlod, since you developed the redis_session.py, are you ok with this:
>>
>>
>> https://github.com/rpedroso/web2py/commit/4c1dbf4e4084e851fb8523fad9c36d419f469db1
>>
>> The other changes are mainly typo fixes
>>
>> Ricardo
>

[Niphlod]

this leads to some issues: if you develop something directly on master then you have to "guess" that Massimo merges your PR before doing any other work (or you and Massimo can end up with merge issues)....
it's far better to keep your master in sync and work only on topic branches, rebasing commits in such way that are fast-forward merges.

On Tuesday, May 14, 2013 8:24:31 PM UTC+2, rh wrote:

On Mon, 13 May 2013 23:33:32 +0100
Ricardo Pedroso <rmdpe...@gmail.com>

I may misunderstand the situation but it seems like you're asking
about the dev workflow. I will tell you what I did.

I forked the web2py master to my github
I cloned my github repo to my local workspace
I made changes to my local clone
I tested the changes locally
I pushed local changes to my github
I sent a pull request to the web2py master
I continue working on my local clone
push changes later, etc.

[Niphlod]

more or less yes..... you work always on branches, so you can pull upstream into your master without issues. 

If needed, you can rebase your commits on topic branches to your master (that is in sync with upstream) to create a "clean PR" that can be merged with a fast-forward merge.

This leads to a cleaner branching on github (one additional step would be for Massimo to merge manually instead of automatically to avoid)

A

  \

   B

  /

C

kinda git log but that's another story...... 

rebasing your PR to a FF merge make the previous "scheme" happen and it's always better than (if you do changes on your master and send a PR from there)

A

|  \

B   F

|     |

C   G

|     |

D   H

|     |

E   L

|   /

M

This is my interpretation of what you've said, is this right?

You create a topic branch and work there.
When done on the topic branch you rebase to your sync'd master
Then send a PR for the topic branch.