Hi Anne, Hi Everyone, I just wanted to share with you this message I wrote some weeks ago (on sage-devel) about my understanding of sage-combinat. I think not a lot of people have seen it (I was not able to get feeback from it at Edimbourg for instance). And also Anne asked me to forward it again to sage-combinat-devel. So here it is :
https://groups.google.com/d/msg/sage-devel/xQxQLkm-RUU/1HdTwfvjSqwJ I should reread it myself because I forgot what I wrote! Sébastien On Wednesday, January 23, 2013 11:16:17 AM UTC+1, Anne Schilling wrote: > > Hi Everyone! > > Thanks, Harald and Andrew for your answers! > > Andrew Ohana answered my questions regarding the planned move to git. > If I understand everything correctly, sage developers will be able to > pull the latest development version of sage in the future with the > git functionality (without downloading the latest release, installing > it with make (which takes many hours)). The huge advantage for us would > be that it would not be necessary any longer to maintain the sage-combinat > queue for several versions of sage (Mike Hansen (and I) spent many hours > yesterday to rebase the queue to sage-5.6 and keep backward compatibility > with earlier versions of sage). > > Since there has been some discussion lately about the sage-combinat queue, > here are some new ideas after talking with Christian Stump and > Jason Bandlow (who is now working at Google and hence has a lot of > experience with how to manage projects): > > - Instead of having a linearly ordered queue where we need to maintain > compatibility constantly by rebasing and there is no identified owner of > the > queue (rather only of individual patches), we should organize our patches > into > projects. There would be a "cluster project", "category project", "monoid > project" etc. There might be some dependencies, but not a lot more than > depth 1 or 2. For example the monoid project might depend on the category > project. Each project has an owner (or a small number of collaborators > that > own that project) and that owner keeps the project rebased against the > latest development version. Since the owner cares about his/her project, > this > is done whenever the owner works on the project (you first pull the latest > development version, rebase, and then work on your project). One would not > have to rely on others to rebase their patches first. > > - If I personally want to use the code for several projects at the same > time, > I could make my own branch by applying projects A, B, C. If there is a > conflict, in my branch I can merge them in my branch and then work on top > of this. > > The advantage of this system over the current linearly ordered queue is > that rebasing is only done when it is necessary (since ultimately we do > not know in which order patches are ready for integration into main > sage). > > Best, > > Anne > > > > -------- Original Message -------- > Subject: Re: Re: vision on moving to git > Date: Tue, 22 Jan 2013 17:21:14 -0800 > From: R. Andrew Ohana <andrew...@gmail.com <javascript:>> > To: William Stein <wst...@gmail.com <javascript:>>, Anne > Schilling <an...@math.ucdavis.edu <javascript:>> > > > > Hi Anne, > > On Tue, Jan 22, 2013 at 4:21 PM, William Stein > <wst...@gmail.com<javascript:><mailto: > wst...@gmail.com <javascript:>>> wrote: > > ---------- Forwarded message ---------- > From: "Harald Schilly" <harald....@gmail.com <javascript:> <mailto: > harald....@gmail.com <javascript:>>> > Date: Jan 22, 2013 4:10 PM > Subject: Re: vision on moving to git > To: <an...@math.ucdavis.edu <javascript:> <mailto: > an...@math.ucdavis.edu <javascript:>>> > Cc: <sage-comb...@googlegroups.com <javascript:> <mailto: > sage-comb...@googlegroups.com <javascript:>>>, "William Stein" < > wst...@gmail.com <javascript:> <mailto:wst...@gmail.com <javascript:>>> > > Hi, I'm not directly involved and William is probably not the best > person to ask. Just two links (it's late) > > https://groups.google.com/d/topic/sage-devel/z4jPFf_vlRY/discussion > > http://wiki.sagemath.org/WorkflowSEP > > Harald > > > > On Wed, Jan 23, 2013 at 12:02 AM, Anne Schilling < > an...@math.ucdavis.edu <javascript:> > <mailto:an...@math.ucdavis.edu<javascript:>>> > wrote: > > Dear William and Sage-Git developers! > > At the current conference we had some discussions regarding the > planned move to git in Sage. We have a couple of questions how you > envision the change (in particular in view of discussing the > workflow at Google that Jason Bandlow described to us). > > (1) Will the move mean that sage developers will be able to pull > the latest "release" from the merge manager with git instead of > having to download the latest version of Sage each time and having > to > recompile the code with make? This would be a huge win since in > particular this would mean for the Sage-combinat queue that we > would > not have to maintain it for various versions of Sage any longer > since > each developer can just pull and update to the latest version. > > > Yes and No. To really have this working properly with the ability to roll > back to a previously working state, we need a real package manager instead > of our current spkg system. That said, we are > planning to get rid of beta releases (while keeping release candidates) in > favor of just pulling down the latest revision along the development branch > (which the release manager(s) would have push > access to). To do that, we will have to move our upgrade system over to > what you mention, but with the caveat that if things break from an upgrade, > you can't downgrade to a previously working state. > > > Not having this feature would be a huge hurdle for the > Sage-combinat queue > since we do not know how to handle the fact that our > users/developers may be > running different versions of Sage and hence would constantly > rebase > their patches on top of their current version of sage. > It would also save a lot of time! > > (2) Will you get rid of the trac server and integrate the > submission of patches into the git workflow? This could be in the > form of a git command that submits and then makes a website with > the diffs where the reviewer can add comments. > > > I think the current general consensus is to stay on trac, but flesh out > its git functionality (which is builtin to the latest release). The main > issues with the git focused websites are that they have > very bad issue trackers. > > The git command sort of stuff can be done with trac, David Roe did a bit > of work and a few tests with this last June. The intent is to have a small > sage development library (with scripts) to handle > this stuff, which will make it possible to avoid git for newbies with > small or isolated changes, as well as automate things such as reviewing > tickets for more advanced users. > > > Harald, if you can address any of these questions in your talk > tomorrow, that would be great! > > Anne > > > > > Hopefully that answers your questions, > > -- > Andrew > > > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
