William Stein <wst...@gmail.com> writes:
> Cool -- that's actually exactly what I had done before sending the
> email, thinking it was the natural thing to do.
> https://github.com/williamstein/sagelib
>
> In general, what version of the Sage library is at sagemath/sagelib on github?
>
>> I am making sure that upstream/master always points to the latest
>> development release, or stable release if there have been no development
>> releases since the last stable release.
>
> Ah, yes, that answers my main question.
Exactly what the various branches mean is pointed out on the README.rst
you see at the github page. This README.rst does not actually appear in
the file structure if you checkout the master branch, though, because
it's on an extra branch I made just in order to display that file on the
github page.
>> Finally you'll need to add in some lines at the top of foo.patch, viz.
>>
>> # HG changeset patch
>> # User William Stein <wst...@gmail.com>
>> # Date $(date +%s) 0000
>> commit message for entire patch
>>
>> Here $(date +%s) of course should be expanded by the shell. You can
>> probably write a quick shell script to insert these lines automatically,
>> maybe accepting the commit message as an argument. (I assume of course
>> that you will be consolidating multiple small commits into one patch,
>> which hopefully we won't have to do anymore once we actually switch to
>> git.)
>>
>> Hope that helps. Evidently other people in this thread do not know that
>> I have been maintaining a git version of the Sage library, so hopefully
>> it will help them too, if they're interested :)
>
> Thanks!!
>
> In particular, could you give me a step-by-step handholding
> explanation of how would I replicate (and improve on!) the following
> HG workflow:
>
> 1. Decide I want to do something awesome.
> 2. Create a trac ticket describing it.
> 3. Write code.
> 4. Post a single patch
> 5. Rewrite code.
> 6. Post a single updated patch.
>
> With queues I do "hg qinit trac12345.patch", etc, and "hg qrefresh"
> and "hg export".
>
> I would like to improve on this of course by being able to record (at
> least for my personal edification) lots of commits, even if they get
> folded later for the public.
Well, let me just give you an overview of the workflow I'm envisioning:
1. Decide I want to do something awesome.
2. $ git remote update upstream
3. $ git checkout -b something-awesome upstream/master
4. Write code.
5. Commit changes with explanatory message in commit message; no need
to refer to "something awesome" in every message. Suggestion: use
`git commit -av`, or `git commit -pv` if you don't want to commit
everything you've changed.
6. $ git push origin something-awesome # optional
7. Repeat steps 4-6 until you have something you think is ready to put
into Sage.
8. Make a trac ticket describing something awesome.
Here's where it diverges. What you would do right now:
9. Create a patch from `git diff something-awesome upstream/master`, as
I described in my previous mail, and upload it to the trac ticket.
10. Wait for patchbot to notice your patch, download it, apply it, test
it, and put feedback on the trac ticket. Hopefully this feedback is
not "patch did not apply".
11. Wait for reviewers to give you comments.
12. If more changes are necessary, repeat steps 4-6 as required, then
repeat steps 9-11, overwriting your old patch.
13. If no more changes are necessary, wait for the release manager to
merge your patch.
14. Forcibly delete your branch something-awesome because your code is
already in Sage, albeit not in the form of the commits you made.
15. Wait for your deleted branch to be garbage collected. Feel a great
disturbance in the Force.
That should more or less be all you need to know for now. But here's how
I hope we will be doing it in the near future:
9. Create a pull request on github from williamstein:something-awesome
to sagemath:master , mentioning "trac 12345" in the pull request
title. (Make sure you've done step 6 sufficiently recently.)
10. Manually tell the patchbot to test your branch by clicking a "test
me" button on the trac ticket. Wait for patchbot to arrive at your
ticket in its request queue, search pull requests on github for a
single open pull request with "trac 12345" in its title, locally
"accept" the pull request and run doctests, and finally report to
the trac ticket on the success of "accepting" the pull request and
on the success of the doctests.
11. Wait for reviewers to give you comments on the trac ticket.
12. If more changes are necessary, repeat steps 4-6 and 9-11 as
required.
13. If no more changes are necessary, wait for the release manager to
merge the pull request on github.
You'll notice that I recommend currently just creating a new patch
against upstream/master each time you update the trac ticket, rather
than uploading multiple tickets. This is just because otherwise you
might feel like making fewer commits because you don't want to have too
many patches on trac, which I think is probably a bad habit.
I also envision the patchbot being "on request" because otherwise it
will probably be quickly overloaded by the higher commit frequency we
would have in the new system.
I put making a trac ticket as late as step #8 so that if something
awesome turned out not to be so awesome after all, you wouldn't need to
bother the release manager about closing the ticket. As long as
everyone's doing step #6 frequently, people can always see what other
people are working on by looking at the `github network page`_, so that
removes the incentive to create a trac ticket early so people know what
you're doing. (Nobody reads the list of new trac tickets these days
anyway, do they? There are too many of them!)
.. _github network page: http://github.com/sagemath/sagelib/network
Anyway, this "near future" stuff is all speculation so far. It will also
be facilitated for newbies by some kind of script, and for the release
manager by another script. I still have to write up something coherent
in the SEP, but the above is a preview :)
-Keshav
----
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
