Re: New Non-WG Mailing List: Ietf-and-github -- Discussion of using GitH

On 01/27/2016 03:34 PM, Phillip Hallam-Baker wrote:
> On Wed, Jan 27, 2016 at 4:51 PM, Doug Barton <dougb(_at_)dougbarton(_dot_)us> 
> wrote:
> > On 01/26/2016 02:50 PM, Melinda Shore wrote:
> > > I am not a fan of making IETF processes dependent on
> > > technologies that don't "belong" to the IETF and I don't
> > > think it's a trivial concern, but if the IETF tools
> > > aren't working for us it makes sense to look outside for
> > > tools that do.
> >
> > The IETF is two decades behind on using revision control in a systematic
> > way, nowhere more significantly than in the area of drafts. At this point,
> > anything reasonable we can do to improve the situation should be embraced.
> >
> > Github is well established, and well respected (as others have pointed out
> > already). While git is not my favorite VCS, it has the advantage of being
> > able to trivially clone the repo, making any IETF "investment" there a safe
> > bet.
> >
> > There is a different, longer term question about whether the IETF should
> > host its own services in this area. Given the perpetually constrained
> > resources of our organization I think that if we can safely "outsource"
> > functions where the potential benefits are great, and the risks are small,
> > we should do that.
> >
> > As for the concern about needing to learn how to use revision control
> > creating a new barrier to entry for ID authors, at this point it's a
> > marginal cost compared to nroff, xml2rfc, etc. You can do everything you
> > need to do for something like this with git in 5 or 6 commands. The basic
> > instructions for cloning a repo, checking in changes, etc. will fit on one
> > sheet of paper (speaking from experience).
> >
> > We should be doing everything we can to make progress in this area.
> I find git a pain in the patootie.
I'm not sure how to respond to that. :)

> Every revision control system I
> have ever used has had severe code NAZI issues.
I seriously don't know how to respond to this, as I have no idea what 
you mean here.
> Git periodically gets
> terminally confused and the only solution seems to be to blow
> everything up.
Yes, git comes with a fully loaded, semi-automatic, foot-shooting gun. 
That's why it's not my favorite VCS.
That said, I have twice now successfully created and administered git 
repos which were aimed at people who are reasonably smart and 
technically proficient, and who had no previous experience with a VCS. A 
key element of our success was to publish clear instructions with the 
minimal command set that 99% of our users needed to do their jobs. 
Anyone venturing off-script was warned that they would not be supported, 
and would be responsible for cleaning up their own mess.
If I were creating a system for IETF I'd choose subversion instead of 
git, since it is in many regards simpler, and significantly less likely 
to succumb to "creativity" for the simple reason that there are 
dramatically fewer knobs to twist.
> No, you don't have to learn xml2rfc either. I haven't used it in ten
> years. I moved to HTML, then people suggested Markdown instead so I
> did that and then I found a package that extracts everything I want
> from Word documents.
I think you missed my point, which was that ID authorship already comes 
with a choice of toolchain ... there is already a learning curve 
associated with it. The marginal cost of adding a VCS to that is small.
But requiring users to 'do' the VCS isn't our only option. If all we did 
was have the tracker check in the latest revision when submitted it 
would make so many things easier. I can elaborate if desired for anyone 
who isn't a software developer who hasn't experienced the many benefits 
of a modern VCS.
Doug