Hi James,
Your description of the two possible workflows are correct. Let's call the
first one "distributed" (any one can hold a copy and send pull requests)
and the second "centralized" (authorized committers can push to the
repository under the TEIC account).
If we follow the centralized system, we'd be replicating what we do on SVN,
but with the extra step of pushing after committing. This is fine by me if
we want to keep things simple.
But if we (as council members) adopt the distributed system (ie you fix the
bug you're assigned to in your copy, then send a pull request), there is a
chance not just for human review (which might be superfluous at that
point), but also for automated testing. If an error occurs, fix it, push
again and it will get tested automatically etc. I think this is useful.
Regardless of what process we adopt, anyone will still be able to send pull
requests and that's a good thing. More tech-savvy users (such as former
members of the council, among others) could send a feature request or a but
*and* a patch at the same time, saving us time and focusing our work on
review and approval.
Raff
On Thu, Jul 30, 2015 at 10:08 AM, James Cummings wrote: Can I ask what the policy for workflow will be on this? In SVN we all have
a copy of the repository, make changes and commit them back directly. I'm
told that the "right" way to do this in git is for us each to fork the
master repository, set this up as a named upstream branch, before working
pull from upstream, do our work, commit back to our repository, push this
to our repository, and then issue a pull request back to the main TEI-C
repository for review before it gets added. Or, if we have rights to do
so, could we just push directly back into the TEI-C repository. (i.e. I find the latter so much easier than the former, though understand
why the former might be technically better if I was doing a huge set of
changes. However, usually we aren't all touching the same set of files at
the same times if my svn notifications are to be believed.) -James On 29/07/15 17:23, Hugh Cayless wrote: All, I've pushed up a copy of the my own synced git-svn copy of the Guidelines
at https://github.com/TEIC/Guidelines-TEST. It's got issues and a wiki
enabled, so we can try those out as we like. Commits to SF should be synced periodically by my server, but changes you
push here will not automatically be sent back to SourceForge (so you can
try it out, with the foreknowledge that they'll probably be deleted).
Currently in-use branches have been copied, but I've not bothered to
create
the old ones (the history is there, but they're not visible as branches).
I've also not bothered to create any tags. This may be something that has
to be done manually, as git tags are not branches, unlike svn tags. I bet
there's a script for it somewhere. If not, I don't think writing one would
be hard. Request for everyone: can you try out cloning and messing with this? In
particular I'd like to know what *doesn't* seem to work, and what the pain
points are. All of them. We will obviously need to develop new
tutorials/documentation for this, so I very much want to know what's
confusing, up to and including "I don't even know where to start with this
git thing". Please don't be shy or embarrassed—you will not be judged.
This
is a new thing to many of us and will be to new members of Council in the
future. GUI clients for those who prefer them are available at
https://windows.github.com and https://mac.github.com. I've zero
experience
with them, but they may be nicer to work with if you're less comfortable
in
the command line. --
Dr James Cummings, James.Cummings@it.ox.ac.uk
Academic IT Services, University of Oxford --
tei-council mailing list
tei-council@lists.tei-c.org
http://lists.lists.tei-c.org/mailman/listinfo/tei-council PLEASE NOTE: postings to this list are publicly archived