#16030: Use "git trac" in the developer guide
-------------------------------------+-------------------------------------
Reporter: vbraun | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.2
Component: documentation | Resolution:
Keywords: | Merged in:
Authors: Volker Braun | Reviewers: Ralf Stephan
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/vbraun/use__git_trac__in_the_developer_guide|
49ee6a57ca0520b8b279bc185b3410056dcdc747
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by kcrisman):
I agree with rws that it's not 100% clear why this is necessary, and I
won't be looking for typos or syntax errors (though it mostly looks fine
assuming `git trac` does the same thing as `sage -dev` in some sense), but
did find one things that should be fixed even if one agrees with "the
author".
{{{
This section gives an example how to review using the ``sage``
}}}
One of the times that shows up you actually have used `git trac` - toward
the end of the diff.
----
Long comment addressed (presumably) to Volker, though of course anyone
else who has been writing things like the `sage -dev` or `git trac` stuff
is more than welcome to join in:
The overly dismissive tone about the `dev` scripts is unnecessary, and to
be honest seems a little insulting to the people who worked hard on
creating those - which doesn't include me, and t think might even include
said author of the guide, which confuses me?
In any case, relegating the dev script part to something that isn't really
even mentioned seems... odd. I think that "the author" has an overly
optimistic view of how easy it is to overcome all the hurdles associated
with development. And yes, Virginia, some open source projects don't
collaborate using git. It would be helpful to have this discussion on
sage-devel about this, rather than a somewhat combative tone in what is
supposed to be an educational document providing the easiest path to doing
things like reviewing a patch. A new reader will be really confused by
this - imagine someone who is starting to use a terminal for the first
time encountering the vim/emacs debate; it would just turn them off.
Honestly, not having to do things like install git (which is, after all,
*in* Sage) or all the other stuff involved really helps a true newcomer.
I mean, look how much one has to do before getting to reviewing. (That is
a problem with the current layout of the devel guide as well, but is made
more egregious by this change). I am going to be teaching Sage and its
development to mathematicians (not students) soon, many of whom are
"completely new to programming" (quote from the director of the program).
I totally understand that one wants to use git for serious developing,
just like before using hg and its queues directly were the right thing to
do. But I really hesitate to try to prepare a syllabus for this without
having the "first step mentioned" be the very easiest, even if some non-
trivial percentage abandon it later for directly interacting with git.
I'm willing to help work on a different layout for the devel guide that
addresses your concerns about not having enough git resources and mine
about making sure the most basic interface is prominent (and correct,
which as you note the documentation isn't always, or complete). It will
take some time, because I have very limited Sage time right now, but I
hope you'll be willing to work with me on this.
--
Ticket URL: <http://trac.sagemath.org/ticket/16030#comment:7>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
