On Wed, Feb 23, 2011 at 10:13 AM, slabbe wrote:
> Hi,
>
>> I'm going to still wait a few days before starting, so feel free to
>> pile on if you would like to add to the discussion.
>
> At Sage Days 28, I gave a talk about how to contribute to Sage. The
> philosophy I choose to present was to crea
Hi,
> I'm going to still wait a few days before starting, so feel free to
> pile on if you would like to add to the discussion.
At Sage Days 28, I gave a talk about how to contribute to Sage. The
philosophy I choose to present was to create one personnal branch
using queues for managing many tick
Hi Kwankyu,
This is exactly what I have just written into the documentation (see
trac #10782 ) and posted about on this list a couple of days ago
(
http://groups.google.com/group/sage-devel/browse_thread/thread/b18d052bf057d465
).
Hope that helps!
-Keshav
On Feb 22, 3:13 pm, Kwankyu Lee wrote
Hi,
I would like to see a section on "rebasing patches" with mercurial
queues, in the Developer's Manual. It is a frequent task to rebase a
patch for a new version of Sage. I myself do this one way, but I am
not sure if I am doing it the right way. My way is simply:
1. hg qpop -a
2. upgrade Sage.
I agree with the second point. This information is useful.
On Feb 21, 10:07 pm, "D. S. McNeil" wrote:
> (1) I just started playing with this stuff, and found queues much
> nicer than cloning; it's worth It might be good to add a few
> explanations to the page of what to do in common-screwup cas
(1) I just started playing with this stuff, and found queues much
nicer than cloning; it's worth It might be good to add a few
explanations to the page of what to do in common-screwup cases (at
least for me): e.g. unapplying everything (even though there are
uncommitted changes), undoing an accid
Thanks, everybody, for the great suggestions - this is just what I
hoped to see.
I'm going to still wait a few days before starting, so feel free to
pile on if you would like to add to the discussion.
Rob
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from
I used the developer's guide to get started with Sage about a year
ago, and I still refer back to it from time to time. I'm
enthusiastically in support of improving it!
Pros for mercurial queues:
* quicker to get started
* easier to understand (for some)
* easy to transition from just reviewin
On Feb 21, 5:47 am, David Kirkby wrote:
> On 21 February 2011 10:36, Keshav Kini wrote:
>
> > I also wonder why the development guide recommends that we use
> > mercurial from inside a Sage session. It seems considerably more
> > tedious than just using it from the command line. Is there some
>
On 21 February 2011 10:36, Keshav Kini wrote:
> I also wonder why the development guide recommends that we use
> mercurial from inside a Sage session. It seems considerably more
> tedious than just using it from the command line. Is there some
> advantage I'm not seeing?
>
> -Keshav
I would say
On Feb 21, 4:45 pm, "Johan S. R. Nielsen"
wrote:
> I'm _only_ using queues at the moment. As far as I can see, clones are
> neat if you have "projects" of patches. However, the beginner will not
> usually have this but only a few scattered fixes here and there and
> patches for review, with none o
On Feb 21, 2:27 am, Rob Beezer wrote:
> I'm inclined to update the "Walking Through the Development Process"
> section of the Developer Guide.
>
> I've had some feedback (in-person) and have seen a few thoughtful
> comments in various places in sage-devel. Other than mentioning new
> features (li
I think this: http://www.sagemath.org/doc/developer/producing_patches.html
should be merged into the "Walking through the Development Process"
section. I found it a much better guide for patch creation.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from thi
13 matches
Mail list logo
