On Thu, May 29, 2014 at 10:01 AM, kcrisman <kcris...@gmail.com> wrote: > Please excuse the following rant. As usual, it is ill-informed, and if some
I appreciate it, and I'm glad we're having this discussion. (It's a rant, but it isn't a flame. Yeah!) > of the points are due to ignorance, I have no problem with that being > pointed out. But from reading the lists, I'm not the only one experiencing > difficulty with this sort of thing. At the very least I think it shows it's > not that easy to do everything right now. > > <rant> > Git workflow. > > The goal was to reduce work for some developers and make things more > modular, but in fact what happens is that people are basing their "branches" > on all kinds of different starting points, forcing constant recompilation > for even the most trivial changes. I'm told "ccache" will help with this, > but it's still not in the developer guide, and I'm not sure it will help > with [s]pkgs anyway, which also change frequently. There were arguments last year by various people that our patch-based workflow was bad, at least as opposed to using branches. There was little in the way of arguments back for patches. I personally wasn't really paying attention then, and I frankly didn't know which was better, having only had experience with patches. I'm glad that you're presenting some of the arguments below in favor of the value of a more patches-based workflow. I recently listened to an interview with the release manager for the stable linux kernel. Linux is of course a big project that uses git -- in fact, as we all know, Linus invented git for Linux development. They use *patches* rather than branches. In fact, their workflow is email + patches. He argues in the interview (in response to questions, etc.) that this is far more efficient than the branch model. Evidently, git has extremely good support for sending patches via email and applying them from email (at least in a local mail spool). Another project I'm involved in called bup (https://github.com/bup/bup) does the same thing -- all code contributions are patches to the mailing list, so I've seen this work. I'm not arguing for replacing trac by patches to a mailing list! I'm just pointing out that some people's assertions that using patches instead of branches is not properly using git can't be right, since the Linux kernel devs use of git is just as "proper" as anybody else's. Basically, I'm trying to argue that there is merit to your rant. > In addition, a web-based interface just like github pull requests was > promised, but I don't see it. Since we don't use the github version to > allow people to just "edit" (see e.g. > https://github.com/grant/sage/commit/27c97d376a956a05c6e4abd97102f80195bda4c0 > for one request that apparently has been ignored), we are actually in a > *worse* place than we were with patches, where at least those could be > applied more or less independently of the state of Sage. > > As another example, in attempting to review one patch which relies upon the > new Maxima update: where that is, one cannot learn easily from git log, > since > > $ git log | grep maxima | less > $ git log | grep Maxima | less > > both do not tell me that in fact, even though Trac says "closed", #13973 > apparently is not yet in a merged release, and so I just wasted a lot of > time figuring that out. Since "Merged in" is no longer updated. You would > think that I could learn this by doing > > $ git log | grep 13973 > > but since Trac #s are no longer in commit messages, that isn't foolproof > either. And indeed, the standard output of "git log" is kind of scary, > because while some entries look like this, roughly as in the old one > > commit 3ea4f9bfc3c1acb6cb9eaa8e7a8ffa41779a6181 > Author: XYZ > Date: Thu May 22 08:37:36 2014 +0200 > > 16199: documentation cosmetics > > > others look like this > > commit e9352062ad7fedbe00ad62d397672203824e0267 > Merge: cc54f6e 80e319d > Author: XYZ > Date: Thu May 22 08:01:19 2014 +0200 > > Merge branch 'develop' into > t/16199/improve_docs__add_doctests_in_power_seri > > * develop: (606 commits) > Updated Sage version to 6.3.beta1 > trac #16237: Typos > Use lazy_import instead > Use point collections more directly. > trac #15036: fix late import of is_Matrix to avoid startup problems > Fixes to normal_form_pc to work with point collections properly. > Fixed failing doctests. > trac #16277: A typo > minor fixes > Trac 15099: numeric evaluation of zetaderiv > trac 16211: Review reviewer patch. > Added a category parameter to Module > change raise syntax to python3 style > > and still others look like this > > commit 9a4b0b83fa06a113c485f22f37af02c24ef35e90 > Merge: f4cbb5f b8fea1c > Author: Release Manager <rele...@sagemath.org> > Date: Wed May 21 16:40:31 2014 +0100 > > Trac #15921: work around Maxima fpprintprec bug and other ARM-specific > probl > > [https://groups.google.com/d/msg/sage-devel/oRpkswzpK38/rNVbVN2RyEcJ > Maxima uses CL FORMAT function wrongly], resulting in outputting wrong > number of digits for floats (one extra), and > contradicting its own manual on fpprintprec. In particular it outputs > too many digits on ix86 and ix86_64, which got in Sage's doctests. As a > result, doctests fail on ARM. > > The fixes are to convert the results into `RealField(prec)`, with > appropriate `prec` > (at least 54, or sometimes more). This ticket also fixes ARM-specific > numerical noise stemming > from various other upstream problems, such as `eglibc` loss of precision > in `lgamma`. > > I don't know why the description of a ticket is ending up in the log. We > want a description of what actually was done, and the description in the > ticket is often full of brainstorming etc. > > Oh, and this all assumes that one knows about pipes and grep. Perhaps "git > trac" deals with these kinds of situations, which is great, but one > shouldn't really have to use git or the command line at all to find out some > of this information. Particularly not as a beginner. > > Anyway, in order to use git properly to do trivial change, one still really > has to learn at least as much as before with hg_sage or hg or sage -dev or > whatever the flavor of the month is. For instance, for this one I guess I > need to first do #13973, and then somehow add #13712 on top of it - which > sounds like a more advanced operation of "merging", and we are many times > warned not to do unnecessary merges. A hint from Travis S. and some Google > helped me eventually figure out how to do this but it's certainly no easier > than what I would have done before. > </rant> > > Okay, done ranting, and foolish stuff it probably was. At first I thought > this wasn't all a regression, but by the end of writing this I'm not so > sure. I appreciate Robert's input on this a lot, though. I actually think > that using Github per se would be worse, definitely, because you have to > interact with all their stuff; I find helping with sagenb very tiresome for It depends. If one wanted to add a docstring in github, a person could do this in a minute: (0) get account on github (1) browser to a file, e.g., https://github.com/sagemath/sage/blob/master/src/sage/calculus/calculus.py (2) click edit, which in 1 click (and 1 second) creates a fork of the repo, and opens that file in an editor in your browser. (3) make changes and click the big green button "Propose file change" at the bottom of the screen. Github has solved some real technical problems regarding lowering the barrier to entry for people to contribute to projects, which we haven't solved, and I think we shouldn't just ignore/dismiss this... Of course, the above is only reasonable for certain very limited types of contributions. For us, we would want to be able to use the modified version of Sage online as well, so one could test/develop code, then "Propose change". If only there were a good way to use Sage online with a code editor... > that reason. So here are a few concrete proposals. Obviously I am not > capable of doing them myself, or I would, and clearly #3 is hard. > > 1) Put "Merged in" back. > 2) Fix just how much crazy stuff shows up in "git log", presumably by > merging things differently or with different messages or something. > 3) Wherever the web interface idea went to, bring it back. Or create a > workflow where github pull requests create a ticket, or something. (I do > like that we have "issues" disabled, since otherwise that would keep things > in too many places.) > 4) Get http://trac.sagemath.org/ticket/14372 in. > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
