Johan S. H. Rosenkilde wrote: > > 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.
Well, making changes doesn't necessarily imply fetching branches, nor [immediate] (re)compilation. Also, occasionally I just "manually" grab changes, i.e., patches or even only hunks, and apply them temporarily, later creating a "clean" branch, probably elsewhere, in order to push or just properly do final testing. What would have to get rebuilt of course also varies broadly, depending on what you change (or what a fetched or pulled branch brings with it). >>> 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). One Sage installation means one machine (you "always" have access to / can currently use), with a specific processor, operating system/distro version, and a single tool chain. > 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. Then you know what "upgrades" /can/ bring. >> 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? (Re)build time and time for docbuilding and testing isn't the only issue (besides history); betas are betas, and pretty regularly bring new issues you don't want to deal with / be disturbed by when working on something else. (Which doesn't mean stable releases would always be better in that regard.) -leif >> 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.
