On Tuesday, July 30, 2013 6:16:48 PM UTC+2, Volker Braun wrote:
>
> We are in the process of updating the developer guide for the new git 
> workflow. The current state is here:
>
> http://sagemath.github.io/git-developer-guide/
>
> Help is of course welcome, the github project page is here: 
> https://github.com/sagemath/git-developer-guide
>
>
This is great news, it should simplify things considerably. Will there be a 
specific switchover day, or are contributors already invited to follow this 
procedure?

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.


Reply via email to