Please excuse the following rant. As usual, it is ill-informed, and if some 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. 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 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.
