[ncc-services-wg] Pre-PDP discussion: "All published documents and PDPs are maintained with git"

On 15 Mar 2013, at 21:55, Richard Hartmann <richih.mailinglist at gmail.com> wrote:

> On Fri, Mar 15, 2013 at 10:46 PM, Jim Reid <jim at rfc1035.com> wrote:
> 
>> First, git may well be the flavour-of-the-month as a version control repository/system today. It won't be in the future. What happens then?
> 
> What always happens: We migrate. I strongly disagree with your
> assessment that it's "of the month", though.

I exaggerated (a little) for effect. So shoot me.

I'm an Old Fart and have lived through far too much of new version control software snake oil and hype. IMO in a few years git will be as dead as SCCS, RCS, CVS, and subversion are. YMMV.

> Most if not all major FLOSS projects (which allow GPL software) use git or are migrating to it. Even Microsoft is starting to support it. git will not go away for a long time. And if it does, it will have provided real benefit to everyone within RIPE.

By this argument, we'd do Track Changes in Word because that's what "everybody does".

> Point in case: Do you know what RIPE NCC's canonical policy document
> storage is? Do you care as long as you get to access the files via
> www, ftp, etc?

>> Just because some people have a git-shaped hammer doesn't mean every problem in the area of version control and document management has to be made to look like a git-shaped nail.
> 
> While that statement is true in and as of itself, I fail to see how it
> relates to the discussion at hand.

Because you strongly suggested git was the way to fix something before it's clear what needs fixing or what the requirements are.

>> You also appear to be defining outcomes before the requirements are agreed. Or even clear. Let's first understand what problem needs solved and then decide what's the best way to solve them.
> 
> That's what we are doing. To arrive at that, we need something to base
> our discussion on. If I hadn't proposed the above, we would not be
> having this conversation.

So let's stop this meta-discussion and get back to what should be getting discussed: a clear problem statement and identification of requirements.