[tei-council] F2F Duke

[Hugh Cayless]

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