Ok, I just answered my question : the information must be put in a
comment, not in the description of the ticket.
The release manager already asked to put the information about which
patch to apply in which order in the description instead of hidden
somewhere in a comment.
So, could the Buildbot
Hi Sage-devel,
How should I say to the BuildBot which patches to apply and in which
order ? Following the information available on the buildbot page [1]
on the Sage wiki, I am not able to make the BuildBot understand how to
apply patches on the ticket #11379 where two of the patches should not
be
On Wednesday, July 20, 2011 9:36:22 AM UTC-7, William wrote:
>
> On Wed, Jul 20, 2011 at 9:29 AM, John H Palmieri
> wrote:
> > On Wednesday, July 20, 2011 12:14:09 AM UTC-7, Maarten Derickx wrote:
> >>
> >> Maybe since we already mark doctest as #optional or #random or #long or
> >> something we
How about one adds a file with "bugs" in the name that lists the doctests
together with their _wrong_ output and corresponding trac link. That way,
we'll find out immediately which tickets are fixed by some upstream spkg
update...
--
To post to this group, send an email to sage-devel@googlegro
On 07/20/11 13:26, Burcin Erocal wrote:
> On Tue, 19 Jul 2011 14:44:10 -0400
> Michael Orlitzky wrote:
>
>> 2. Subject to #1, where is the most appropriate place to add the
>> tests? My first guess would be in the "TESTS:" section of
>> sage/calculus/calculus.py, but there appear to be some stand
On Tue, 19 Jul 2011 14:44:10 -0400
Michael Orlitzky wrote:
> 2. Subject to #1, where is the most appropriate place to add the
> tests? My first guess would be in the "TESTS:" section of
> sage/calculus/calculus.py, but there appear to be some standalone
> tests defined in sage/tests, too.
If you
On Wed, Jul 20, 2011 at 9:29 AM, John H Palmieri wrote:
> On Wednesday, July 20, 2011 12:14:09 AM UTC-7, Maarten Derickx wrote:
>>
>> Maybe since we already mark doctest as #optional or #random or #long or
>> something we should add another marker which say's #known bug.
>
> Apparently you can alr
On Wednesday, July 20, 2011 12:14:09 AM UTC-7, Maarten Derickx wrote:
>
>
>
> Maybe since we already mark doctest as #optional or #random or #long or
> something we should add another marker which say's #known bug.
Apparently you can already do this, but it's not documented in the
developer's g
Are there good reasons you need to use that specific version of the LLL
algorithm?
If you just need some result fast (before the deadline) it might be easier
to just use one of the other LLL algorithms.
The NTL wrapper object has a lot of .LLL methods to chose from.
And appart from that you mi
Maybe since we already mark doctest as #optional or #random or #long or
something we should add another marker which say's #known bug.
Unit tests being slightly different should have a different solution. But
some pythonic way of marking unit tests as known bugs would also be usefull.
Kind Re
10 matches
Mail list logo
