[tei-council] F2F Duke

[James Cummings]

I don't think what was being suggested is a change of version 
control system. We can discuss that again, if someone wants to 
put it on the agenda, but we did decide previously not to move 
away from Sourceforge and SVN for the maintenance of the 
Guidelines just a few meetings ago. We did decide to move the 
stylesheets and 'software' maintenance to github, and indeed we 
have done so. So, I'm against discussing that again for awhile 
since I think it just wastes lots of discussion time.

We should, however, discuss our general workflow and how to make 
it more efficient and proactive -- something I've been failing to 
do.

-James

On 11/11/14 01:11, Hugh Cayless wrote:
> Well, in Git commit != push, so you wouldn't be blocked in a per-commit basis, but I agree with you. Insisting on peer review for every change or batch of changes isn't really reasonable. One of the reasons I like Git is the cheap branching, meaning any large and/or complex changes can happen outside the main branch and could be subject to pre-merge review if we wanted.
>
> Sent from my phone.
>
>> On Nov 10, 2014, at 18:28, Martin Holmes <mholmes at uvic.ca> wrote:
>>
>>> On 14-11-10 03:13 PM, Sebastian Rahtz wrote:
>>> i think you’re assuming a hierarchy, Martin,
>>> of  One-Linus-to-bind-us-with-one-ring. I think Peter
>>> is imagining peer review, where commits from each of us
>>> are checked by someone else, and we all have equal
>>> power (with which comes equal responsibility, i believe).
>>
>> Yes, I was assuming a hierarchy; but if there isn't one, then we end up
>> with a situation where nobody can get any work done because they need
>> their last commit to be OKed by someone else before they can carry on,
>> and no-one is available. How much fun would development be for you at
>> midnight when you're on a roll, if you had to wait for someone else to
>> approve every commit to the Stylesheets repo?
>>
>> What this would encourage is that, rather than committing your work in a
>> series of sensible modules that are easily understood and debugged,
>> people would roll up a huge number of changes into one big commit; then
>> the scale of the thing would make it daunting to anyone who had to check
>> and merge it.
>>
>> Also, one purpose of Jenkins is to provide a solid testing environment
>> so that committers don't need the entire machinery of the build process
>> on e.g. their iPad to make a change; they can let Jinks do the heavy
>> lifting. Even if you wait a day for me to OK your commit, when it gets
>> to Jenkins it's only marginally less likely to break the build anyway.
>>
>>> I like the idea, not to catch people being evil or stupid,
>>> but just because its almost always the case that
>>> what one does can be improved by showing it to someone else.
>>
>> That's definitely true, but I think the time for that is during ticket
>> discussions; by the time we've decided something should be done
>> (something significant, anyway), we should also have decided how it
>> should be done, with the mechanics spelled out in as much detail as the
>> implementer needs.
>>
>>> i dont feel that strongly, tho.
>>
>> I think I do, on this one.
>>
>> Cheers,
>> Martin
>>
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford