SageNB development
Pat LeSmithe
http://trac.sagemath.org/sage_trac/ticket/8051
=== Comment 17 ===
By the way, it seems that for the near future, I may be the only very
active SageNB developer. I'd be *very* happy to be proved (proven?)
wrong! There are many tasks to complete --- there are several cool new
notebook features to implement. It's not possible for me to cover them
all, and I'd like to avoid stalling ongoing development.
To this end, I'll try to make it easier for Sage developers to review
notebook tickets or make other contributions. Please let me know what
would help. For example, I can make experimental spkgs that contain the
latest patches in the queue. Those who wish just to test the cumulative
changes can install the package with sage -f sagenb-*.spkg. But
reviewers can also open the spkg, pop / push patches, and comment on
specific ticket(s). In either case, we'll get useful information about
how the notebook behaves in a wider gamut of browser-OS combinations.
We'll also get more end user feedback.
=== Comment 18 (acleone) ===
Experimental spkgs would be good. I think the best way to get more
testing/review would be a good guide to applying patches, testing spkgs,
etc.
Is there a mailing list or wiki page for coordinating development effort?
=== Comment 19 (mvngu) ===
Replying to acleone:
Is there a mailing list or wiki page for coordinating development
effort?
A relevant mailing is sage-devel. Most of the time, that list receives
high volume traffic on development discussion. For coordinating release
effort, the sage-release mailing list is appropriate. Some effort is
underway to expand the Sage documentation with information to help
beginners getting started with Sage development. The relevant tickets are:
1. #8108: Expand the Sage Developer Guide for newcomers
http://trac.sagemath.org/sage_trac/ticket/8108
2. #6987: reorganize section on producing patches with Mercurial
http://trac.sagemath.org/sage_trac/ticket/6987
3. #8079: Better documentation for patching spgk's
http://trac.sagemath.org/sage_trac/ticket/8079
4. #8104: developer's guide for making spkgs should specify that
patches need to be version controlled
http://trac.sagemath.org/sage_trac/ticket/8104
5. #3882: explain in the programming guide why spkg source patches
should be applied by copying entire files
http://trac.sagemath.org/sage_trac/ticket/3882
6. #7944: update Developers' Guide to reflect new process for working
on tickets
http://trac.sagemath.org/sage_trac/ticket/7944
=== Comment 20 ===
Both sage-devel and sage-notebook are good places. I suppose we should
move this discussion to sage-notebook.
One source for ideas is SageTasks
(http://wiki.sagemath.org/devel/SageTasks), but it may be getting old.
Addendum: Of course, we should also try to attract energetic developers
who'd contribute fresh ideas, techniques, etc., to the SageNB project.
=== Comment 21 ===
While I'm here, I'd also like to suggest using alpha.sagenb.org or
creating ouch.sagenb.org to test a bleeding-edge SageNB. This could be a
notebook with all positively reviewed patches applied or, more
interestingly, an experimental spkg.
We could also set up a corresponding repository, different from
http://boxen.math.washington.edu:8100/, to which to push experimental
features and from which to backport what works. A potential problem here
is that Mercurial changesets are immutable. But we might not care about
keeping the history of this repository clean.
Just some thoughts.
William Stein
> The following is transplanted from #8051
>
> http://trac.sagemath.org/sage_trac/ticket/8051
>
> === Comment 17 ===
>
> By the way, it seems that for the near future, I may be the only very
> active SageNB developer. I'd be *very* happy to be proved (proven?)
> wrong! There are many tasks to complete --- there are several cool new
Just so people know, by "near future" he means February and March. I
think Tim Dummol and I both plan to be very active again starting in
April.
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
Stan Schymanski
There is lots of talk about reviewing tickets everywhere, but I haven't
been able to find out what it takes to do such a review. Does one have
to be an experienced sage developer first, or is the reviewing process a
routine to test whether a patch does what it promises without stuffing
up other things? I read somewhere that part of the review is to assure
that a patch follows some established sage conventions, but I did not
find out what they actually are. I think that a brief guide to reviewing
would be very helpful.
Cheers
Stan
Stan Schymanski
Thanks for your very helpful response! I will have a look at the places
you recommended and come back if something remains unclear.
Cheers
Stan
On 1/02/10 18:53, Minh Nguyen wrote:
> Hi Stan,
>
> On Mon, Feb 1, 2010 at 11:51 PM, Stan Schymanski<schy...@gmail.com> wrote:
>
>> Dear all,
>>
>> There is lots of talk about reviewing tickets everywhere, but I haven't been
>> able to find out what it takes to do such a review.
>>
> The Developers' Guide has a section on reviewing tickets [1]. Ticket
> #8108 [2] adds an introductory chapter to the Developers' Guide that
> covers a general process for Sage development. This new addition also
> covers some issues relating to reviewing tickets.
>
>
>
>> Does one have to be an
>> experienced sage developer first,
>>
> I don't think so. Many tickets don't require that you are an
> experienced developer, e.g. documentation patches that fix typos and
> expand on the Sage documentation. Other tickets require more
> specialized knowledge such as a specific area of mathematics.
>
>
>
>> or is the reviewing process a routine to
>> test whether a patch does what it promises without stuffing up other things?
>>
> It's more than that. As you know, one is encouraged to write patches
> that adhere to certain coding conventions, e.g. the Python coding
> standards [3].
>
>
>
>> I read somewhere that part of the review is to assure that a patch follows
>> some established sage conventions, but I did not find out what they actually
>> are. I think that a brief guide to reviewing would be very helpful.
>>
> Please refer to the Developers' Guide [4]. In any case, please don't
> hesitate to ask if something is missing from that guide or something
> isn't well explained.
>
>
> [1] http://www.sagemath.org/doc/developer/trac.html#reviewing-patches
>
> [2] http://trac.sagemath.org/sage_trac/ticket/8108
>
> [3] http://www.sagemath.org/doc/developer/conventions.html
>
> [4] http://www.sagemath.org/doc/developer/
>
>