Hi Keshav,
My last answer was a little rude or at least very short. Since Nicolas is on
vacation I'm the only sage-combinat coordinator keeping an eye here this week.
Anyway, we are both currently completely buried under the teaching load (eg:
for me 15 hours new lectures since Monday). So please don't feel offended by
this short answer. I had the impression that you where ready to jump on the
script and that we Nicolas and myself will suffer shortly...
On Wed, Oct 26, 2011 at 02:07:54AM -0700, Keshav Kini wrote:
> Ah, I'm sorry, I misunderstood your question. Yes, that is a problem. I see
> no way around it in general. The only way to mitigate this is to try to
> avoid changing files that sage-combinat is working on.
That's precisely what I was more or less asking... At least, please don't do
it without having a green light from our side.
> But I doubt that Sage developers want to commit to such a promise, unless
> sage-combinat wants to take ownership of parts of Sage... and certainly your
> objection applies to any broad changes to the Sage codebase. But what leif
> (I think) and I were trying to say is that at least this change he mentioned
> would be a lot easier to handle than other large-scale changes (such as,
> say, python3 migration changes which will eventually happen).
If you want some example of what has been painful in the past, here they
are. Note: I don't intend any offense against the responsible of those
changes, I'm just asking for coordination; Trivial change for you are not
trivial at all for us:
- Automatic replacement of
EXAMPLES::$
sage:
by
EXAMPLES::$
$
sage:
- tab replaced by spaces;
- bunch of typos corrections.
> If I understand correctly, sage-combinat is an project which develops
> extensions of Sage which periodically (when sage-combinat feels a
> particular ticket is ready for review?) gets included into Sage itself.
You understand correctly with "periodically" meaning when we feel that things
are stable/tested enough. So this is some kind of coordinated development and
pre-review process. Low level changes (eg: in the category system) are shaken
and tested before inclusion. Being able to do that in a relatively large scale
is quite efficient. Moreover we often need those code for research...
> The standard way to do such a thing with Mercurial is to maintain a separate
> clone of the Sage repository (or a separate branch within the Sage
> repository), and merge changes from mainstream Sage into that repo every
> time Sage releases a new version. This way you don't need to muck about with
> rebasing multiple patch files etc., and pulling from the sage-combinat repo
> back into the mainstream Sage repo is relatively painless. In particular,
> I've never heard of anyone long-term sharing a patch queue repository and
> using it for development - that sounds really painful to me!
This is going definitely off topic...
First of all, I'm not a revision control expert ! Maybe there is a better
solution. We didn't saw it with Nicolas after *quite* some thinking. If a
better working and robust solution come up, we will more than gladly adopt it.
But we won't redo this thinking again, unless we become completely stuck.
We used (with CVS) this kind of workflow when working with MuPAD. I wasn't
satisfactory. The problem is that when you are working in parallel on a stable
and a more experimental modifications of the same files, it is hard to unfold
the change sets to submit it after. More precisely, suppose that on a single
file I'm doing in sequence four modifications 1 2 3 4, I want to submit
modification 1 and 3 to trac while keeping 2 and 4 for a forthcoming
ticket. Of course change 2 and 3 must commute. With mercurial queue, this is
just moving line in the series file. With branches, you will end up with a
sequence of changeset. You need to extract those you want at the end. In my
experience and understanding, you have to follow a very strong discipline to
annotate every changeset committed with the information needed to select it at
the end. With patches, you can do it along the way commuting and folding
patches.
Anyway, the fact is that
- our development workflow more or less work (except during those big
changes);
- actually I feel that it work too well, so that we are abusing it ;-) They
are plenty of patch in the queue which are 1 or 2 hours work away from
being merged into sage and stay here for several months.
As I said, maybe we did it wrong, but it took quite some thinking to setup
properly the workflow and to write the tools (the "sage -combinat" script). I
don't see it changing unless an expert propose us streamlined solution. We
spend already quite a time explaining the workflow to contributors. I don't
think we will do any change to it, unless we are sure that the new workflow is
much easier and robust than the previous one.
> (pre-posting edit: People in the IRC channel #mercurial on freenode said
> that they have heard of this workstyle but find it "quite painful" too...)
>
> However, sadly, Sage does not really properly use Mercurial in a nice way,
> i.e. nobody touches our repository except the release manager, and there
> are scripts to handle all of that, which only expect to be merging patches
> from trac tickets and not doing anything else. So it may be a bit difficult
> to implement a nicer way for sage-combinat to collaborate with Sage, at
> least at the moment...
>
> (As you may know, I am a very junior Sage developer so take what I say with
> a grain of salt, please :) )
Don't worry ! I'm not a revision control expert either. And thanks for your
suggestions.
Cheers,
Florent
PS: there are plenty of whitespaces at the end of the lines of your message ;-)
--
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
