"Georg S. Weber" <georgswe...@googlemail.com> writes: > 1. > It can guarantee that each "official" release depends linearly on the > previous oficial release. I.e. there is a well defined (and openly > communicated/visible) series of patches, that will lead from one > official release to the next/following one, when these patches are > applied sequentially (for each of the different spkgs). > > 2. > It allows for working with/testing *in parallel* several "development" > releases, between which no such linear dependencies need to exist. > E.g. it allowed for already creating and testing Sage-5.0.alpha > development releases already at a point of time, where the "final > official" Sage-4.8 didn't even exist yet (only rc candidates) --- or > even could have existed, because for some of the few remaining > blockers for Sage-4.8, the (eventual) patches themselves simply didn't > exist yet! > > IMHO, the advantages of the current workflow (especially point 2 > above) do outweigh the disadvantages that are mentioned in this > thread. And I don't see how any "inverse/undo patching" could possibly > result in the freedom to work on several "truly independent" > development releases/branches *at one and the same time*. Thus I > believe that "easiness to anbandon changes made to previous > development releases" is an essential need!
I think that you are missing an important point, which is that version control is not for making nice lists of patches, but is for *tracking development*. If you want to see a nice list of patches you can look at http://boxen.math.washington.edu/home/release/sage-5.0.beta8/tickets.html or similar files in other versions. I think this addresses your point 1), if I'm reading it correctly. As for point 2), you say you want to make several "development releases in parallel between which no linear dependencies need to exist". Basically you're saying you want to create tentative collections of code changes, cherry-picking patches from various people's work to see how they work together. That is different from *releases*! Jeroen has explicitly told people to base their patches on the latest development branch. If the goal is to have development releases be in parallel and totally independent, this is a rather odd request. It should be up to the creator of these testing patch queues to rebase their patches. Why should individual developers care about your or my testing queues? More to the point, why should we even want new patches be based on the current development release if the next one is going to be totally independent and parallel to it? The reason that individual developers should care about rebasing or otherwise modifying their patches to be compatible with *releases* is that releases of software are supposed to be set in stone, so developers can be sure that they are actually making forward progress by doing so. Think about the very fact that there is a "latest" development release. That means that if what you are saying is true, we are currently, and *should be*, dragging authors of dozens of in-progress patches around to various totally independent sets of changes approximately once a week! Of course, in practice, nobody actually does this - they just rebase the patch when `hg qimport` is no longer able to fuzzily apply the patch to the latest development release (i.e. when someone else has touched files they have touched, and even then only sometimes). In fact, they rarely bother unless someone actually tries to apply the patch, fails, and sets the ticket to needs_work. And in practice, development releases are very rarely parallel or totally independent. For the most part, they semantically are already based on the previous development release, but just don't appear so in the actual version control history graph. If we switch to git, as I understand we eventually will, patches (commits) made from an older dev release will be considered to "not apply" (not be mergeable) a lot more often than merely the cases when other people have meanwhile touched the same files - in fact, *always* - unless we make development releases based on their predecessors. This is the point I was making in the OP. This mismatch between what developers are supposed to do / what development releases technically are on one hand and what developers actually do / what development releases are in practice on the other hand, and the fact that the latter will necessarily lean more in the direction of the former when we switch to git, are the reason I made this thread. But even leaving git aside, as they say, don't make laws you don't intend to enforce. If making parallel totally independent collections of patches to test is really what development releases are for, then I would suggest that we tell people to just base their patches on the latest official release, and ignore development releases. Which then makes development releases rather useless for anything other than testing totally independent collections of patches. In fact, I may just stop pushing Jeroen's development release branches to my github mirror of the Sage library since it is causing the problems I mentioned in the OP. > Finally, I'd like to add that in my eyes, Jeroen does a tremendously > good job in "coordinating concurrent or conflicting changes", to the > extent that more often than not, it is us fellow developers hanging > behind after him, not the other way around! (Which is a very good > thing, because it means Jeroen can attack developer jobs himself like > the OS X 10.7 Lion problem.) Absolutely. Jeroen does a lot of great work, and I applaud him for it. Certainly I have no idea of how difficult it is to be a release manager. But I don't think that should stop anyone from suggesting ways that what he does, which affects all Sage developers, could be changed. Let me hasten to point out, before someone calls me out on only having 13 rather paltry commits in the Sage library over the past year, that this is not particularly relevant to me personally, since I have only made rather trivial contributions to Sage so far :) But I still strongly believe that a lot could be done to make Sage more friendly to write code for than it currently is. In fact, I think that Jeroen would also benefit from a revamp of our workflow. Again, I absolutely don't mean any of this message or the rest of the thread to be directed against Jeroen or to make light of the huge amount of work he puts into moving Sage along. Sorry for the long rant. -Keshav @ Sea-Tac ---- Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
