The recommended workflow for Sage is the "Simple Workflow". You can use github or any other repo to collaborate, but you'll have to push the final result to the Sage trac server to add it to a ticket. You should base your edits on the most recent Sage version. You can already use git, we'll support both mercurial patches and git branches during a transition period.
I made http://trac.sagemath.org/ticket/14986 to deal with the locale issue (Andrew, please have a look). Though the ssh gitolite commands don't really allow you to do anything besides checking that your public key is set up correctly. I've added your fixes to the git developer manual (note that it is for now developed on github, so pull requests are fine). On Tuesday, July 30, 2013 4:43:06 PM UTC-4, martin....@gmx.net wrote: > > I submitted a pull request with various minor fixes, but what I'm really > interested in is the big > holes<http://sagemath.github.io/git-developer-guide/workflows.html#github>. > For example, what will be your relation to github? Will you accept issues > filed there, or pull requests submitted there? If so, will you import these > into trac? Should contributors make an effort to learn the trac workflow, > even if they know github very well? > > I also tried this out, cloning the repo from the trac machine. I noticed > that I get a number of perl warnings due to unsupported locale settings, > particularly for the “info” command, but also one while cloning. This is > probably due to the fact that my distro sends locale info over ssh by > default <https://bugs.gentoo.org/show_bug.cgi?id=367017>, and there > appears to be no way to override > this<https://bugzilla.mindrot.org/show_bug.cgi?id=1285>. > And the locale in question isn't installed on the server. Perhaps you can > remove the AcceptEnv setting from the ssh server configuration to avoid > these issues. I guess git doesn't really require locale settings in any > case, does it? > > I know many projects encourage contributors to write bug fixes against the > revisions which introduced a bug. That way they can be integrated into > multiple lines of development simply by merging that branch. But > identifying the relevant base revision may take some work. Do you have any > policy on this issue? Do you want to describe it, or encourage users who > know how to do this, or would you rather have all commits against a recent > code base to obtain a simple and more linear line of development? > -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
