replace symbolic package on Octave-Forge

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

replace symbolic package on Octave-Forge

Colin Macdonald
Hi Carnë (and others),

You and I discussed replacing the old (and unlisted) symbolic package
with my new octsympy (renamed to "symbolic", or at least packaged as
"symbolic").

I think I'm ready to go forward with that.

(I forget how much of this was discussed on the list; if anyone prefers
we DO NOT do so, please speak up.)

Colin

--
Colin Macdonald
Associate Professor
Tutorial Fellow at Oriel College
University of Oxford


signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: replace symbolic package on Octave-Forge

Carnë Draug
On 6 January 2015 at 23:02, Colin Macdonald <[hidden email]> wrote:

> Hi Carnë (and others),
>
> You and I discussed replacing the old (and unlisted) symbolic package
> with my new octsympy (renamed to "symbolic", or at least packaged as
> "symbolic").
>
> I think I'm ready to go forward with that.
>
> (I forget how much of this was discussed on the list; if anyone prefers
> we DO NOT do so, please speak up.)

Cool. I noticed you have also implemented vpn on the octsympy which was the
part you thought was missing. I will need your sourceforge username to give you
push access.

If you are replacing the old symbolic package, It makes sense to me that you
continue its repository, i.e., remove all the current files and
replace them with your
code.  Since you are using git this either means converting the
current repository
to git or you adopting mercurial. I am fine either way. In Octave we
tend to favour
mercurial but I'll guess you will want the later to keep your github clone.

But let's wait until next week to give time for people to give their
opinion (and
I am also a bit too busy the next couple of days).

Carnë

Reply | Threaded
Open this post in threaded view
|

Re: replace symbolic package on Octave-Forge

Colin Macdonald
On 07/01/15 20:37, Carnë Draug wrote:
> If you are replacing the old symbolic package, It makes sense to me
> that you continue its repository, i.e., remove all the current files
> and replace them with your code.  Since you are using git this either
> means converting the current repository to git or you adopting
> mercurial.

Ok, probably I'll convert it to git.

> But let's wait until next week to give time for people to give their
> opinion (and I am also a bit too busy the next couple of days).

No problem, I'm not in a hurry.

My sourceforge username is "cmacdonald".

Colin


signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: replace symbolic package on Octave-Forge

Jordi Gutiérrez Hermoso-2
On Wed, 2015-01-07 at 22:01 +0000, Colin Macdonald wrote:
> Ok, probably I'll convert it to git.

Is there anything that could be done to convince you to try Mercurial?
It's helpful to have a single VCS for Octave, and Mercurial is what we
use for Octave itself.

- Jordi G. H.



Reply | Threaded
Open this post in threaded view
|

Re: replace symbolic package on Octave-Forge

Colin Macdonald
On 07/01/15 22:06, Jordi Gutiérrez Hermoso wrote:
> Is there anything that could be done to convince you to try Mercurial?
> It's helpful to have a single VCS for Octave, and Mercurial is what we
> use for Octave itself.

I'll think about it.

(-) My "other upstream" (SymPy) uses git.

(-) I'm not sure I can handle the mental load of working with
    both (I use git for other projects).

(+) Maybe being on hg attracts extra help from Octave community.

(+) I do like the more patch-based philosophy of hg.

Perhaps I could experiment a bit with git-hg or hg-git.

Colin


signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: replace symbolic package on Octave-Forge

Richard Crozier
On 07/01/15 23:13, Colin Macdonald wrote:

> On 07/01/15 22:06, Jordi Gutiérrez Hermoso wrote:
>> Is there anything that could be done to convince you to try Mercurial?
>> It's helpful to have a single VCS for Octave, and Mercurial is what we
>> use for Octave itself.
>
> I'll think about it.
>
> (-) My "other upstream" (SymPy) uses git.
>
> (-) I'm not sure I can handle the mental load of working with
>      both (I use git for other projects).
>
> (+) Maybe being on hg attracts extra help from Octave community.
>
> (+) I do like the more patch-based philosophy of hg.
>
> Perhaps I could experiment a bit with git-hg or hg-git.
>
> Colin
>

Having had to learn both Mercurial and Git, all I can say is, try
mercurial, you'll never look back. It's like Git, but designed for
humans. The 'mental load' you refer to is a Git problem.

Richard

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


Reply | Threaded
Open this post in threaded view
|

Re: replace symbolic package on Octave-Forge

Jordi Gutiérrez Hermoso-2
In reply to this post by Colin Macdonald
On Wed, 2015-01-07 at 23:13 +0000, Colin Macdonald wrote:
> (+) I do like the more patch-based philosophy of hg.

If you're referring to Mercurial Queues, that's in the process of
being phased out:

   http://mercurial.selenic.com/wiki/MqExtension

There's an experimental new way to polish your commits before you push
them to a public server. It mostly provides a cleaner CLI. You can see
me preaching about it here:

    https://www.youtube.com/watch?v=4OlDm3akbqg

If you want to just fast-forward me demoing this feature, that happens
around 9:06:

    https://www.youtube.com/watch?feature=player_detailpage&v=4OlDm3akbqg#t=546

If you're used to `git rebase -i` for polishing your commits, `hg
histedit` is nearly a verbatim replacement. You can use that too, if
you prefer an interface based on editing text files instead of a CLI.

- Jordi G. H.





Reply | Threaded
Open this post in threaded view
|

Re: replace symbolic package on Octave-Forge

Carnë Draug
In reply to this post by Colin Macdonald
On 7 January 2015 at 22:01, Colin Macdonald <[hidden email]> wrote:

> On 07/01/15 20:37, Carnë Draug wrote:
>> If you are replacing the old symbolic package, It makes sense to me
>> that you continue its repository, i.e., remove all the current files
>> and replace them with your code.  Since you are using git this either
>> means converting the current repository to git or you adopting
>> mercurial.
>
> Ok, probably I'll convert it to git.
>
>> But let's wait until next week to give time for people to give their
>> opinion (and I am also a bit too busy the next couple of days).
>
> No problem, I'm not in a hurry.
>

No one commented on this so I guess it is fine.

I went ahead with this and converted the old hg repo to git and then merged
it with yours.  You can pull this merge from the octave forge clone:

  https://sourceforge.net/p/octave/symbolic/

or from my own github:

  https://github.com/carandraug/octsympy

My merge commit does not add any new code or files (my only attribution
is a commit message [1] on an empty commit) but does append all the commits
of the old symbolic package (attributed to the original comitters).  This
seems to be the best for archive purposes.

I understand you want to keep a clone on github and that is perfectly fine
but I will ask that you keep the clone on the Octave Forge project up to
date, at least before a new release.  You should now have push permissions
to all Octave Forge repositories.

Also, the last release of Octave's symbolic package was 1.1.0 so when you
make a new release of it could it be 2.0.0 (instead of octsympy 0.1.4)?

Carnë

[1] https://github.com/carandraug/octsympy/commit/0ac6fe2

Reply | Threaded
Open this post in threaded view
|

Re: replace symbolic package on Octave-Forge

Carnë Draug
On 9 February 2015 at 17:04, Nir Krakauer <[hidden email]> wrote:

> On Tue, Jan 27, 2015 at 9:15 PM, Carnë Draug <[hidden email]> wrote:
>>
>> On 7 January 2015 at 22:01, Colin Macdonald <[hidden email]>
>> wrote:
>> > On 07/01/15 20:37, Carnë Draug wrote:
>> >> If you are replacing the old symbolic package, It makes sense to me
>> >> that you continue its repository, i.e., remove all the current files
>> >> and replace them with your code.  Since you are using git this either
>> >> means converting the current repository to git or you adopting
>> >> mercurial.
>> >
>> > Ok, probably I'll convert it to git.
>> >
>> >> But let's wait until next week to give time for people to give their
>> >> opinion (and I am also a bit too busy the next couple of days).
>> >
>> > No problem, I'm not in a hurry.
>> >
>>
>> No one commented on this so I guess it is fine.
>>
>> I went ahead with this and converted the old hg repo to git and then
>> merged
>> it with yours.  You can pull this merge from the octave forge clone:
>>
>>   https://sourceforge.net/p/octave/symbolic/
>>
>> or from my own github:
>>
>>   https://github.com/carandraug/octsympy
>>
>> My merge commit does not add any new code or files (my only attribution
>> is a commit message [1] on an empty commit) but does append all the
>> commits
>> of the old symbolic package (attributed to the original comitters).  This
>> seems to be the best for archive purposes.
>>
>> I understand you want to keep a clone on github and that is perfectly fine
>> but I will ask that you keep the clone on the Octave Forge project up to
>> date, at least before a new release.  You should now have push permissions
>> to all Octave Forge repositories.
>>
>> Also, the last release of Octave's symbolic package was 1.1.0 so when you
>> make a new release of it could it be 2.0.0 (instead of octsympy 0.1.4)?
>>
>> Carnë
>>
>> [1] https://github.com/carandraug/octsympy/commit/0ac6fe2
>>
>
> is it time then to strike out
> http://wiki.octave.org/SoC_Project_Ideas#Rewrite_symbolic_package ?

I think so. And maybe replace it with some new project for the symbolic
package?

Carnë

Reply | Threaded
Open this post in threaded view
|

Re: replace symbolic package on Octave-Forge

Colin Macdonald
On 09/02/15 17:35, Carnë Draug wrote:
>> is it time then to strike out
>> > http://wiki.octave.org/SoC_Project_Ideas#Rewrite_symbolic_package ?
>
> I think so. And maybe replace it with some new project for the symbolic
> package?

One possible project would be to make it more robust by using a library
call to python instead of a pipe.  Current approach is pretty fragile
when things go wrong.

I'll try to remember to edit the wiki to add this.  And a pointer to my
bugs tagged "help-wanted" on github.

Colin


signature.asc (484 bytes) Download Attachment