On Thu, May 29, 2014 at 10:37 AM, William Stein <wst...@gmail.com> wrote: > 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...
Exactly. I'd like to see us better integrate this workflow rather than try to replicate it. For more complex changes, one can easily "migrate" from this workflow to a local copy with git. It'd be cool to make it just as easy to migrate a branch on github (or any git hosting service) to a SMC project (and back). Personally, I find line comments and being able easily look at different diffs very useful as well compared to using trac, but I agree that it's good to have issues consolidated at one place. > 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. -- 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.
