Re: [tei-council] Test GLs repo on GitHub

30 Jul 2015


      On 30/07/15 15:21, Raffaele Viglianti wrote:
...
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).
Hurrah. I seem to understand the basics of version control. 
Quick, let me add it to my linkedIn profile. ;-)
...
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.
Good.  I like simple. (Not just TEI 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.
If we have a continuous integration environment set up (whether 
external like Jenkins or in-built like whatever it was called), 
then wouldn't that happen on any git push?
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.
That sounds idea and the combined form that Hugh suggests seems 
to make most sense to me. While you're on council (or some list 
of approved committers working on a particular thing) then you 
can push directly. For large but discrete changes that are likely 
to break a lot of things we use branches for ease of review. For 
members of the public, they can either submit issues directly, or 
as part of a pull request on a forked copy of the repository.

-James
...
Raff
On Thu, Jul 30, 2015 at 10:08 AM, James Cummings 
mailto:James.Cummings@it.ox.ac.uk> 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
    mailto:James.Cummings@it.ox.ac.uk
    Academic IT Services, University of Oxford
-- 
    tei-council mailing list
    tei-council@lists.tei-c.org
    mailto: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
-- 
Dr James Cummings, James.Cummings@it.ox.ac.uk
Academic IT Services, University of Oxford