FYI: there is now a very interesting discussion going on numpy-di...@scipy.org that resulted in [1], see also the forwarded message below. Shall we create a similar document for sfepy?
r.
[1] http://docs.scipy.org/doc/numpy/dev/gitwash/index.html
---------- Forwarded message ---------- Date: Tue, 12 Oct 2010 11:55:04 -0700 From: Fernando Perez fpere...@gmail.com Reply-To: Discussion of Numerical Python numpy-di...@scipy.org To: Discussion of Numerical Python numpy-di...@scipy.org Subject: Re: [Numpy-discussion] Development workflow
On Tue, Oct 12, 2010 at 6:51 AM, Vincent Davis vin...@vincentdavis.net wrote:
Lots of good reading :) Just thought I'd put a plug in for the contributor that may make only a few contributions and needs a simple workflow to do so. It would be great if they could just.. make there own fork clone the branch of interest make changes push to there own fork request pull.
I think part of the point of moving to git was to make these types of contributions easier. Ideally there would be instructions here http://www.numpy.org/
Matthew Brett has prepared a document with much of this in ready-to-digest form:
http://github.com/matthew-brett/gitwash
It's meant for easy inclusion in other projects (if they agree with the worfklow it presents), here it is for example rendered with the urls pointing to ipython repos:
http://ipython.scipy.org/doc/nightly/html/development/gitwash/index.html
Cheers,
f
NumPy-Discussion mailing list NumPy-Di...@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Wed, Oct 13, 2010 at 3:42 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
FYI: there is now a very interesting discussion going on numpy-di...@scipy.org that resulted in [1], see also the forwarded message below. Shall we create a similar document for sfepy?
+1 This is a good document. Should we recommend a similar workflow (using github forks)?
We have some initial notes on using git to contribute patches in the documentation. Would it fit there, or is it better to have a separate document?
Logan
r.
[1] http://docs.scipy.org/doc/numpy/dev/gitwash/index.html
---------- Forwarded message ---------- Date: Tue, 12 Oct 2010 11:55:04 -0700 From: Fernando Perez fpere...@gmail.com Reply-To: Discussion of Numerical Python numpy-di...@scipy.org To: Discussion of Numerical Python numpy-di...@scipy.org Subject: Re: [Numpy-discussion] Development workflow
On Tue, Oct 12, 2010 at 6:51 AM, Vincent Davis vin...@vincentdavis.net wrote:
Lots of good reading :) Just thought I'd put a plug in for the contributor that may make only a few contributions and needs a simple workflow to do so. It would be great if they could just.. make there own fork clone the branch of interest make changes push to there own fork request pull.
I think part of the point of moving to git was to make these types of contributions easier. Ideally there would be instructions here http://www.numpy.org/
Matthew Brett has prepared a document with much of this in ready-to-digest form:
http://github.com/matthew-brett/gitwash
It's meant for easy inclusion in other projects (if they agree with the worfklow it presents), here it is for example rendered with the urls pointing to ipython repos:
http://ipython.scipy.org/doc/nightly/html/development/gitwash/index.html
Cheers,
f
NumPy-Discussion mailing list NumPy-Di...@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- You received this message because you are subscribed to the Google Groups "sfepy-devel" group. To post to this group, send email to sfepy...@googlegroups.com. To unsubscribe from this group, send email to sfepy-devel...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
On Wed, 13 Oct 2010, Logan Sorenson wrote:
On Wed, Oct 13, 2010 at 3:42 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
FYI: there is now a very interesting discussion going on numpy-di...@scipy.org that resulted in [1], see also the forwarded message below. Shall we create a similar document for sfepy?
+1 This is a good document. Should we recommend a similar workflow (using github forks)?
Well, the primary sfepy repo is now on github. We have also the organization [2], which is not much used now, but could be used much more.
As for the workflow, our current way is essentially what is in the section "Making a patch" in [1] - for smaller patches this is fine, but for larger ones the github forks seem better.
We have some initial notes on using git to contribute patches in the documentation. Would it fit there, or is it better to have a separate document?
I would add it as a section to our developer guide - the current notes could be merged in, if appropriate.
What do you think?
r.
Logan
r.
[1] http://docs.scipy.org/doc/numpy/dev/gitwash/index.html [2] http://github.com/sfepy
---------- Forwarded message ---------- Date: Tue, 12 Oct 2010 11:55:04 -0700 From: Fernando Perez fpere...@gmail.com Reply-To: Discussion of Numerical Python numpy-di...@scipy.org To: Discussion of Numerical Python numpy-di...@scipy.org Subject: Re: [Numpy-discussion] Development workflow
On Tue, Oct 12, 2010 at 6:51 AM, Vincent Davis vin...@vincentdavis.net wrote:
Lots of good reading :) Just thought I'd put a plug in for the contributor that may make only a few contributions and needs a simple workflow to do so. It would be great if they could just.. make there own fork clone the branch of interest make changes push to there own fork request pull.
I think part of the point of moving to git was to make these types of contributions easier. Ideally there would be instructions here http://www.numpy.org/
Matthew Brett has prepared a document with much of this in ready-to-digest form:
http://github.com/matthew-brett/gitwash
It's meant for easy inclusion in other projects (if they agree with the worfklow it presents), here it is for example rendered with the urls pointing to ipython repos:
http://ipython.scipy.org/doc/nightly/html/development/gitwash/index.html
Cheers,
f
NumPy-Discussion mailing list NumPy-Di...@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- You received this message because you are subscribed to the Google Groups "sfepy-devel" group. To post to this group, send email to sfepy...@googlegroups.com. To unsubscribe from this group, send email to sfepy-devel...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
-- You received this message because you are subscribed to the Google Groups "sfepy-devel" group. To post to this group, send email to sfepy...@googlegroups.com. To unsubscribe from this group, send email to sfepy-devel...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
On Wed, Oct 13, 2010 at 10:15 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On Wed, 13 Oct 2010, Logan Sorenson wrote:
On Wed, Oct 13, 2010 at 3:42 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
FYI: there is now a very interesting discussion going on numpy-di...@scipy.org that resulted in [1], see also the forwarded message below. Shall we create a similar document for sfepy?
+1 This is a good document. Should we recommend a similar workflow (using github forks)?
Well, the primary sfepy repo is now on github. We have also the organization [2], which is not much used now, but could be used much more.
As for the workflow, our current way is essentially what is in the section "Making a patch" in [1] - for smaller patches this is fine, but for larger ones the github forks seem better.
We have some initial notes on using git to contribute patches in the documentation. Would it fit there, or is it better to have a separate document?
I would add it as a section to our developer guide - the current notes could be merged in, if appropriate.
What do you think?
This sounds good, I went ahead and shamelessly pulled [1] into our developer guide (changing numpy -> sfepy). The existing git stuff needs to be cleaned up and integrated better. You can review it at [3] (following the new guide ;) ).
r.
Logan
r.
[1] http://docs.scipy.org/doc/numpy/dev/gitwash/index.html [2] http://github.com/sfepy
[3] http://github.com/logansorenson/sfepy/compare/master...gitwash
<snip>
Hi Logan,
On Wed, 13 Oct 2010, Logan Sorenson wrote:
On Wed, Oct 13, 2010 at 10:15 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On Wed, 13 Oct 2010, Logan Sorenson wrote:
On Wed, Oct 13, 2010 at 3:42 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
FYI: there is now a very interesting discussion going on numpy-di...@scipy.org that resulted in [1], see also the forwarded message below. Shall we create a similar document for sfepy?
+1 This is a good document. Should we recommend a similar workflow (using github forks)?
Well, the primary sfepy repo is now on github. We have also the organization [2], which is not much used now, but could be used much more.
As for the workflow, our current way is essentially what is in the section "Making a patch" in [1] - for smaller patches this is fine, but for larger ones the github forks seem better.
We have some initial notes on using git to contribute patches in the documentation. Would it fit there, or is it better to have a separate document?
I would add it as a section to our developer guide - the current notes could be merged in, if appropriate.
What do you think?
This sounds good, I went ahead and shamelessly pulled [1] into our developer guide (changing numpy -> sfepy). The existing git stuff needs to be cleaned up and integrated better. You can review it at [3] (following the new guide ;) ).
Great job! So here is the review:
- although the docs were borrowed from NumPy, the NumPy guys borrowed them themselves from Matthew Brett [4] - we should IMHO cite the original source :)
- it seems your editor does not break lines (see developer_guide.rst) at max. 79 chars per line.
- the links SfePy_ are not defined - dev/gitwash/git_links.inc needs to be updated (replace _PROJECTNAME etc.)
Also, the original git stuff can be moved to a sort of "quick start" section.
Btw. does github allow posting review comments?
cheers, r.
[1] http://docs.scipy.org/doc/numpy/dev/gitwash/index.html [2] http://github.com/sfepy [3] http://github.com/logansorenson/sfepy/compare/master...gitwash [4] http://github.com/matthew-brett/gitwash
Hi Robert,
On Thu, Oct 14, 2010 at 3:33 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
Hi Logan,
On Wed, 13 Oct 2010, Logan Sorenson wrote:
On Wed, Oct 13, 2010 at 10:15 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On Wed, 13 Oct 2010, Logan Sorenson wrote:
On Wed, Oct 13, 2010 at 3:42 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
FYI: there is now a very interesting discussion going on numpy-di...@scipy.org that resulted in [1], see also the forwarded message below. Shall we create a similar document for sfepy?
+1 This is a good document. Should we recommend a similar workflow (using github forks)?
Well, the primary sfepy repo is now on github. We have also the organization [2], which is not much used now, but could be used much more.
As for the workflow, our current way is essentially what is in the section "Making a patch" in [1] - for smaller patches this is fine, but for larger ones the github forks seem better.
We have some initial notes on using git to contribute patches in the documentation. Would it fit there, or is it better to have a separate document?
I would add it as a section to our developer guide - the current notes could be merged in, if appropriate.
What do you think?
This sounds good, I went ahead and shamelessly pulled [1] into our developer guide (changing numpy -> sfepy). The existing git stuff needs to be cleaned up and integrated better. You can review it at [3] (following the new guide ;) ).
Great job! So here is the review:
- although the docs were borrowed from NumPy, the NumPy guys borrowed them themselves from Matthew Brett [4] - we should IMHO cite the original source :)
- it seems your editor does not break lines (see developer_guide.rst) at max. 79 chars per line.
- the links SfePy_ are not defined - dev/gitwash/git_links.inc needs to be updated (replace _PROJECTNAME etc.)
Also, the original git stuff can be moved to a sort of "quick start" section.
Awesome, these are very good points. I'll make the changes as soon as I can. I like the idea of the git quick start section.
Btw. does github allow posting review comments?
I'm not sure...I don't see anything obvious...
Logan
cheers, r.
[3] http://github.com/logansorenson/sfepy/compare/master...gitwash
[4] http://github.com/matthew-brett/gitwash
-- You received this message because you are subscribed to the Google Groups "sfepy-devel" group. To post to this group, send email to sfepy...@googlegroups.com. To unsubscribe from this group, send email to sfepy-devel...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sfepy-devel?hl=en.
On Thu, 14 Oct 2010, Logan Sorenson wrote:
Hi Robert,
On Thu, Oct 14, 2010 at 3:33 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
Great job! So here is the review:
- although the docs were borrowed from NumPy, the NumPy guys borrowed them themselves from Matthew Brett [4] - we should IMHO cite the original source :)
- it seems your editor does not break lines (see developer_guide.rst) at max. 79 chars per line.
- the links SfePy_ are not defined - dev/gitwash/git_links.inc needs to be updated (replace _PROJECTNAME etc.)
Also, the original git stuff can be moved to a sort of "quick start" section.
Awesome, these are very good points. I'll make the changes as soon as I can. I like the idea of the git quick start section.
Great, looking forward to it!
Btw. does github allow posting review comments?
I'm not sure...I don't see anything obvious...
No problem. I just think we do not use github's capabilities to its full power, so if you (anyone) happen to find a cool feature, post it here, please.
r.
Logan
cheers, r.
[3] http://github.com/logansorenson/sfepy/compare/master...gitwash
Hi Robert,
On Fri, Oct 15, 2010 at 4:26 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On Thu, 14 Oct 2010, Logan Sorenson wrote:
Hi Robert,
On Thu, Oct 14, 2010 at 3:33 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
Great job! So here is the review:
- although the docs were borrowed from NumPy, the NumPy guys borrowed them themselves from Matthew Brett [4] - we should IMHO cite the original source :)
- it seems your editor does not break lines (see developer_guide.rst) at max. 79 chars per line.
- the links SfePy_ are not defined - dev/gitwash/git_links.inc needs to be updated (replace _PROJECTNAME etc.)
Also, the original git stuff can be moved to a sort of "quick start" section.
Awesome, these are very good points. I'll make the changes as soon as I can. I like the idea of the git quick start section.
Great, looking forward to it!
Ok, it's done, see the same review link [3].
Btw. does github allow posting review comments?
I'm not sure...I don't see anything obvious...
No problem. I just think we do not use github's capabilities to its full power, so if you (anyone) happen to find a cool feature, post it here, please.
Will do!
Logan
> [1] http://docs.scipy.org/doc/numpy/dev/gitwash/index.html
[3] http://github.com/logansorenson/sfepy/compare/master...gitwash
On Fri, 15 Oct 2010, Logan Sorenson wrote:
Hi Robert,
On Fri, Oct 15, 2010 at 4:26 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On Thu, 14 Oct 2010, Logan Sorenson wrote:
Hi Robert,
On Thu, Oct 14, 2010 at 3:33 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
Great job! So here is the review:
- although the docs were borrowed from NumPy, the NumPy guys borrowed them themselves from Matthew Brett [4] - we should IMHO cite the original source :)
- it seems your editor does not break lines (see developer_guide.rst) at max. 79 chars per line.
- the links SfePy_ are not defined - dev/gitwash/git_links.inc needs to be updated (replace _PROJECTNAME etc.)
Also, the original git stuff can be moved to a sort of "quick start" section.
Awesome, these are very good points. I'll make the changes as soon as I can. I like the idea of the git quick start section.
Great, looking forward to it!
Ok, it's done, see the same review link [3].
Looks good, thanks! I have rebased it on the current master, but used --no-ff when merging, the result is for the moment at [5]. Do you think we should merge in this way for "bigger" changes? So far I have always used the fast-forward merges.
Btw. does github allow posting review comments?
I'm not sure...I don't see anything obvious...
No problem. I just think we do not use github's capabilities to its full power, so if you (anyone) happen to find a cool feature, post it here, please.
Will do!
Great, thanks, r.
>> [1] http://docs.scipy.org/doc/numpy/dev/gitwash/index.html
[3] http://github.com/logansorenson/sfepy/compare/master...gitwash
On Mon, 18 Oct 2010, Robert Cimrman wrote:
On Fri, 15 Oct 2010, Logan Sorenson wrote:
Hi Robert,
On Fri, Oct 15, 2010 at 4:26 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On Thu, 14 Oct 2010, Logan Sorenson wrote:
Hi Robert,
On Thu, Oct 14, 2010 at 3:33 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
Great job! So here is the review:
- although the docs were borrowed from NumPy, the NumPy guys borrowed them themselves from Matthew Brett [4] - we should IMHO cite the original source :)
- it seems your editor does not break lines (see developer_guide.rst) at max. 79 chars per line.
- the links SfePy_ are not defined - dev/gitwash/git_links.inc needs to be updated (replace _PROJECTNAME etc.)
Also, the original git stuff can be moved to a sort of "quick start" section.
Awesome, these are very good points. I'll make the changes as soon as I can. I like the idea of the git quick start section.
Great, looking forward to it!
Ok, it's done, see the same review link [3].
Looks good, thanks! I have rebased it on the current master, but used --no-ff when merging, the result is for the moment at [5]. Do you think we should merge in this way for "bigger" changes? So far I have always used the fast-forward merges.
It's now in the gitwash-no-ff branch at [5]. I have decided to go our usual way in this case :).
r.
>>> [1] http://docs.scipy.org/doc/numpy/dev/gitwash/index.html > > [2] http://github.com/sfepy
[3] http://github.com/logansorenson/sfepy/compare/master...gitwash
On Tue, Oct 19, 2010 at 3:26 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On Mon, 18 Oct 2010, Robert Cimrman wrote:
On Fri, 15 Oct 2010, Logan Sorenson wrote:
Hi Robert,
On Fri, Oct 15, 2010 at 4:26 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On Thu, 14 Oct 2010, Logan Sorenson wrote:
Hi Robert,
On Thu, Oct 14, 2010 at 3:33 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
Great job! So here is the review:
- although the docs were borrowed from NumPy, the NumPy guys borrowed them themselves from Matthew Brett [4] - we should IMHO cite the original source :)
- it seems your editor does not break lines (see developer_guide.rst) at max. 79 chars per line.
- the links SfePy_ are not defined - dev/gitwash/git_links.inc needs to be updated (replace _PROJECTNAME etc.)
Also, the original git stuff can be moved to a sort of "quick start" section.
Awesome, these are very good points. I'll make the changes as soon as I can. I like the idea of the git quick start section.
Great, looking forward to it!
Ok, it's done, see the same review link [3].
Looks good, thanks! I have rebased it on the current master, but used --no-ff when merging, the result is for the moment at [5]. Do you think we should merge in this way for "bigger" changes? So far I have always used the fast-forward merges.
It's now in the gitwash-no-ff branch at [5]. I have decided to go our usual way in this case :).
Sorry for the slow reply! That sounds good for now. I'm not too sure what the repercussions of --no-ff are. :) I'll compare the two and do some reading on the numpy-discussion list.
By the way, do you prefer developers working from your github/rc account or from the official sfepy github account? For this case, I worked from the official sfepy github repo, but I see you had to rebase off the current master. Or maybe this is what --no-ff solves... :)
Logan
r.
>>>> [1] http://docs.scipy.org/doc/numpy/dev/gitwash/index.html >> >> [2] http://github.com/sfepy > > [3] http://github.com/logansorenson/sfepy/compare/master...gitwash
On Tue, 19 Oct 2010, Logan Sorenson wrote:
On Tue, Oct 19, 2010 at 3:26 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On Mon, 18 Oct 2010, Robert Cimrman wrote:
On Fri, 15 Oct 2010, Logan Sorenson wrote:
Hi Robert,
On Fri, Oct 15, 2010 at 4:26 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On Thu, 14 Oct 2010, Logan Sorenson wrote:
Hi Robert,
On Thu, Oct 14, 2010 at 3:33 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote: > > Great job! So here is the review: > > - although the docs were borrowed from NumPy, the NumPy guys borrowed > them > themselves from Matthew Brett [4] - we should IMHO cite the original > source > :) > - it seems your editor does not break lines (see developer_guide.rst) > at > max. 79 chars per line. > - the links SfePy_ are not defined - dev/gitwash/git_links.inc needs > to > be > updated (replace _PROJECTNAME etc.) > > Also, the original git stuff can be moved to a sort of "quick start" > section. >
Awesome, these are very good points. I'll make the changes as soon as I can. I like the idea of the git quick start section.
Great, looking forward to it!
Ok, it's done, see the same review link [3].
Looks good, thanks! I have rebased it on the current master, but used --no-ff when merging, the result is for the moment at [5]. Do you think we should merge in this way for "bigger" changes? So far I have always used the fast-forward merges.
It's now in the gitwash-no-ff branch at [5]. I have decided to go our usual way in this case :).
Sorry for the slow reply! That sounds good for now. I'm not too sure what the repercussions of --no-ff are. :) I'll compare the two and do some reading on the numpy-discussion list.
No problem. I just wanted show the two possibilities.
By the way, do you prefer developers working from your github/rc account or from the official sfepy github account? For this case, I worked from the official sfepy github repo, but I see you had to rebase off the current master. Or maybe this is what --no-ff solves... :)
The official sfepy github repo. My github account may at times contain commits I will revert/amend later etc.
As for rebasing, IMHO the numpy discussion converged on that it is always better to rebase prior to merging to resolve possible conflicts locally within a feature branch. Then the merge will be clean. --no-ff makes the branch visible for future, that's the only difference I am aware off. I have used tags for this purpose...
cheers, r.
>>>>> [1] http://docs.scipy.org/doc/numpy/dev/gitwash/index.html >>> >>> [2] http://github.com/sfepy >> >> [3] http://github.com/logansorenson/sfepy/compare/master...gitwash > > [4] http://github.com/matthew-brett/gitwash
On Tue, Oct 19, 2010 at 10:58 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On Tue, 19 Oct 2010, Logan Sorenson wrote:
On Tue, Oct 19, 2010 at 3:26 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On Mon, 18 Oct 2010, Robert Cimrman wrote:
On Fri, 15 Oct 2010, Logan Sorenson wrote:
Hi Robert,
On Fri, Oct 15, 2010 at 4:26 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On Thu, 14 Oct 2010, Logan Sorenson wrote:
> Hi Robert, > > On Thu, Oct 14, 2010 at 3:33 AM, Robert Cimrman cimr...@ntc.zcu.cz > wrote: >> >> Great job! So here is the review: >> >> - although the docs were borrowed from NumPy, the NumPy guys >> borrowed >> them >> themselves from Matthew Brett [4] - we should IMHO cite the original >> source >> :) >> - it seems your editor does not break lines (see >> developer_guide.rst) >> at >> max. 79 chars per line. >> - the links SfePy_ are not defined - dev/gitwash/git_links.inc needs >> to >> be >> updated (replace _PROJECTNAME etc.) >> >> Also, the original git stuff can be moved to a sort of "quick start" >> section. >> > > Awesome, these are very good points. I'll make the changes as soon as > I can. I like the idea of the git quick start section.
Great, looking forward to it!
Ok, it's done, see the same review link [3].
Looks good, thanks! I have rebased it on the current master, but used --no-ff when merging, the result is for the moment at [5]. Do you think we should merge in this way for "bigger" changes? So far I have always used the fast-forward merges.
It's now in the gitwash-no-ff branch at [5]. I have decided to go our usual way in this case :).
Sorry for the slow reply! That sounds good for now. I'm not too sure what the repercussions of --no-ff are. :) I'll compare the two and do some reading on the numpy-discussion list.
No problem. I just wanted show the two possibilities.
By the way, do you prefer developers working from your github/rc account or from the official sfepy github account? For this case, I worked from the official sfepy github repo, but I see you had to rebase off the current master. Or maybe this is what --no-ff solves... :)
The official sfepy github repo. My github account may at times contain commits I will revert/amend later etc.
As for rebasing, IMHO the numpy discussion converged on that it is always better to rebase prior to merging to resolve possible conflicts locally within a feature branch. Then the merge will be clean. --no-ff makes the branch visible for future, that's the only difference I am aware off. I have used tags for this purpose...
Ok, just to make sure it's correct in the docs, that means you (Robert) will always always rebase before merging with master. But it's still a good idea for the developer contributing a patch or entire branch to rebase off the latest available master at that time to make it easier on you.
I'll turn my attention to the build system then. :)
Thanks! Logan
cheers, r.
>>>>>> [1] http://docs.scipy.org/doc/numpy/dev/gitwash/index.html >>>> >>>> [2] http://github.com/sfepy >>> >>> [3] http://github.com/logansorenson/sfepy/compare/master...gitwash >> >> [4] http://github.com/matthew-brett/gitwash
On Tue, 19 Oct 2010, Logan Sorenson wrote:
On Tue, Oct 19, 2010 at 10:58 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote: <snip>
The official sfepy github repo. My github account may at times contain commits I will revert/amend later etc.
As for rebasing, IMHO the numpy discussion converged on that it is always better to rebase prior to merging to resolve possible conflicts locally within a feature branch. Then the merge will be clean. --no-ff makes the branch visible for future, that's the only difference I am aware off. I have used tags for this purpose...
Ok, just to make sure it's correct in the docs, that means you (Robert) will always always rebase before merging with master. But it's still a good idea for the developer contributing a patch or entire branch to rebase off the latest available master at that time to make it easier on you.
Exactly, I could not summarize it better :)
I'll turn my attention to the build system then. :)
Great, many thanks!
r.
On Tue, Oct 19, 2010 at 9:27 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On Tue, 19 Oct 2010, Logan Sorenson wrote:
On Tue, Oct 19, 2010 at 10:58 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
<snip> >> >> The official sfepy github repo. My github account may at times contain >> commits I will revert/amend later etc. >> >> As for rebasing, IMHO the numpy discussion converged on that it is always >> better to rebase prior to merging to resolve possible conflicts locally >> within a feature branch. Then the merge will be clean. --no-ff makes the >> branch visible for future, that's the only difference I am aware off. I >> have >> used tags for this purpose... > > Ok, just to make sure it's correct in the docs, that means you > (Robert) will always always rebase before merging with master. But > it's still a good idea for the developer contributing a patch or > entire branch to rebase off the latest available master at that time > to make it easier on you.
Exactly, I could not summarize it better :)
I'll turn my attention to the build system then. :)
Great, many thanks!
In sympy, we just created this simple page:
http://sympy.org/development.html
that pretty much says "send us a github pull request", with a link to github documentation of how to do it.
Since then, we got some new contributors. :)
Ondrej
On 11/06/10 00:11, Ondrej Certik wrote:
On Tue, Oct 19, 2010 at 9:27 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
On Tue, 19 Oct 2010, Logan Sorenson wrote:
On Tue, Oct 19, 2010 at 10:58 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
<snip> >> >> The official sfepy github repo. My github account may at times contain >> commits I will revert/amend later etc. >> >> As for rebasing, IMHO the numpy discussion converged on that it is always >> better to rebase prior to merging to resolve possible conflicts locally >> within a feature branch. Then the merge will be clean. --no-ff makes the >> branch visible for future, that's the only difference I am aware off. I >> have >> used tags for this purpose... > > Ok, just to make sure it's correct in the docs, that means you > (Robert) will always always rebase before merging with master. But > it's still a good idea for the developer contributing a patch or > entire branch to rebase off the latest available master at that time > to make it easier on you.
Exactly, I could not summarize it better :)
I'll turn my attention to the build system then. :)
Great, many thanks!
In sympy, we just created this simple page:
http://sympy.org/development.html
that pretty much says "send us a github pull request", with a link to github documentation of how to do it.
That's the message :) But Matthew Brett's text that we included into our docs (=no work for us) is nicely self-contained.
Since then, we got some new contributors. :)
Yeah, you got the stone rolling...
r.
On Sun, Nov 7, 2010 at 7:17 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On 11/06/10 00:11, Ondrej Certik wrote:
On Tue, Oct 19, 2010 at 9:27 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
On Tue, 19 Oct 2010, Logan Sorenson wrote:
On Tue, Oct 19, 2010 at 10:58 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
<snip> >> >> The official sfepy github repo. My github account may at times contain >> commits I will revert/amend later etc. >> >> As for rebasing, IMHO the numpy discussion converged on that it is >> always >> better to rebase prior to merging to resolve possible conflicts locally >> within a feature branch. Then the merge will be clean. --no-ff makes >> the >> branch visible for future, that's the only difference I am aware off. I >> have >> used tags for this purpose... > > Ok, just to make sure it's correct in the docs, that means you > (Robert) will always always rebase before merging with master. But > it's still a good idea for the developer contributing a patch or > entire branch to rebase off the latest available master at that time > to make it easier on you.
Exactly, I could not summarize it better :)
I'll turn my attention to the build system then. :)
Great, many thanks!
In sympy, we just created this simple page:
http://sympy.org/development.html
that pretty much says "send us a github pull request", with a link to github documentation of how to do it.
That's the message :) But Matthew Brett's text that we included into our docs (=no work for us) is nicely self-contained.
Thanks for the link Ondrej!
I like github because it is very easy to pick up and get started. And git is very awesome once you get the hang of it. I think git-gui is very helpful for learning the basic workflow until one can get used to the command line.
Since then, we got some new contributors. :)
Yeah, you got the stone rolling...
The main challenge to me is keeping the documentation up to date and comprehensive and creating exciting examples to attract potential users/contributors. Definitely making contributing as easy as possible will help out a lot. I hope we can attract more contributors.
Speaking of which, I have several deadlines coming up, so I haven't been able to work on the bento build system...
Greetings, Logan
On 11/11/10 06:54, Logan Sorenson wrote:
On Sun, Nov 7, 2010 at 7:17 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
On 11/06/10 00:11, Ondrej Certik wrote:
On Tue, Oct 19, 2010 at 9:27 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
On Tue, 19 Oct 2010, Logan Sorenson wrote:
On Tue, Oct 19, 2010 at 10:58 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
<snip> >> >> The official sfepy github repo. My github account may at times contain >> commits I will revert/amend later etc. >> >> As for rebasing, IMHO the numpy discussion converged on that it is >> always >> better to rebase prior to merging to resolve possible conflicts locally >> within a feature branch. Then the merge will be clean. --no-ff makes >> the >> branch visible for future, that's the only difference I am aware off. I >> have >> used tags for this purpose... > > Ok, just to make sure it's correct in the docs, that means you > (Robert) will always always rebase before merging with master. But > it's still a good idea for the developer contributing a patch or > entire branch to rebase off the latest available master at that time > to make it easier on you.
Exactly, I could not summarize it better :)
I'll turn my attention to the build system then. :)
Great, many thanks!
In sympy, we just created this simple page:
http://sympy.org/development.html
that pretty much says "send us a github pull request", with a link to github documentation of how to do it.
That's the message :) But Matthew Brett's text that we included into our docs (=no work for us) is nicely self-contained.
Thanks for the link Ondrej!
I like github because it is very easy to pick up and get started. And git is very awesome once you get the hang of it. I think git-gui is very helpful for learning the basic workflow until one can get used to the command line.
Yeah, I find git gui really helpfull as you can mark a region to be included in the commit by mouse - sometimes git add --patch is not enough as it's chunk splitting capability is limited.
Since then, we got some new contributors. :)
Yeah, you got the stone rolling...
The main challenge to me is keeping the documentation up to date and comprehensive and creating exciting examples to attract potential users/contributors. Definitely making contributing as easy as possible will help out a lot. I hope we can attract more contributors.
That's the first necessary condition - to attract people. But there is the second one, maybe even more important - the code must be easy to use and extend so that the people stay. The 'use' case is ok IMHO, but extending by adding a new term is difficult. I have a radical refactoring in mind and and "waiting" now to have a spare time window big enough to code a prototype.
Speaking of which, I have several deadlines coming up, so I haven't been able to work on the bento build system...
Dto...
cheers, r.
participants (3)
-
Logan Sorenson -
Ondrej Certik -
Robert Cimrman