leif writes: > Well, probably it's just me, but I always (also) review tickets on trac > (i.e., via what git-o-lite gives); the whole branch, but also each > individual commit. You just need a browser to do so.
I use git-o-lite a lot too, but often switch back to my Emacs and git log using Magit :-P > Having a Sage installation at hand, it's even more tedious to do so on > the command line when the relevant commits are "out-of-order" / mixed > with unrelated commits. I mostly take the commit id from trac. But yes, without git-o-lite it can get difficult to find the commits you need. I'm sure there are "git log" flags for it, but I'm not an expert. It just hasn't come up enough for me to really try and find a solution. >> "whatever head" is always develop, so I'm always pulling into the newest >> beta release. > > Well, that doesn't make much of a difference, unless the ticket is > incidentally based on the same (which is rarely the case, since most > tickets live longer than a single beta-release cycle). I just wanted to stress that it's not a random choice. Indeed, barring the "history becomes difficult to read", I don't see any argument against all devs always working on latest beta, in which case it would always make sense to update all tickets to that. We could even automatically upgrade all tickets to latest beta on releases. Though based on this discussion, I'd guess many of you would get angry due to "history becomes more difficult to read". > For trivial changes, you can also put inline patches onto trac the owner > of the ticket / branch can easily apply, and for more complex changes, > you can always create a new branch on trac *without* changing the > ticket's branch to that. Then the owner of the original branch can > cherry-pick from your branch, if it's based on something else. This is a good idea that would allow me to continue using my current workflow, without annoying other devs. > (With different Sage installations, you could do similar locally of > course, i.e., "backport" the changes you made on top of your develop to > master+fetched original branch, say, and push the resulting branch. I > personally often first make changes in some random Sage installation, > then moving them around, later pushing to trac from a "suited" one.) Aha, sort of like what Daniel wrote, except that fetching the branch into "random Sage installation" means you don't get the low compilation time benefits. >> I don't see why all developers shouldn't always be on the latest beta. > > Time? Resources? > > Note that many, I guess, have Sage installations here and there, and > most likely don't or cannot keep each of them always what you'd call > "up-to-date", but rather at one of the previous "stable" releases, or > something inbetween. What time? What resources? My dev model needs only a single Sage installation and no extra software to achieve overall very low compilation time. The other suggestions I've heard need multiple Sages, extra software and/or does not minimise compilation time. Checking out a ticket takes a whopping extra 3 seconds (if it takes longer it's because of merge errors which I would have to fix anyway). Note I have one extra Sage tree to ensure that I have a working Sage at any time. It's on latest stable and I never develop on it. > [Random insertion: Wasn't it you who [had to] upgrade[d] to Ubuntu > 16.04 just to get the next version of Emacs? ;-) ] Hmm, no. I've used Arch linux for 3 years now because Ubuntu has too old software. But I've twice had major compilation issues due to Arch upgrading to a new release of some dependency (e.g. ranlib or gcc) long before any other distro. > Obviously, there are more "recent" beta releases than stable ones. And > as mentioned, tickets and their branches age. > > So you'll never have all tickets (not even a large percentage) based on > the latest beta. > > It's easier if you keep one Sage installation at master, and another at > some later beta. The problem (if tickets are based on the latest beta) > IMHO is that one is too often forced to "upgrade" for no reason, at > least if one forgets to first check what release a branch was based on. > If people keep pushing back "rebased" branches, the situation just worsens. OK, but I just still don't really see the problem of being "forced to upgrade". I don't see how it hurts me that I'm always working on the latest beta - my patch has to work with that anyway. Except for the "history is more difficult to understand" argument. But is that really enough of an argument to jump through hoops and rings for achieving low compilation time in another way? > More seriously, different Sage installations, trying to pick the most > suited when going to actually build a fetched branch. But sometimes at > least, you also want to test on a specific machine (hardware, OS/distro, > compiler, whatever). OK, thanks for describing your workflow. Best, Johan -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
