On 15 Mar 2013, at 21:42, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
That said, while I agree that Git is a very good tool, I'm reluctant to micro-manage the NCC by saying «you MUST use Git» (or any other particular tool for that matter).
I am painfully aware of that. The community is free to shoot this down, but if it's accepted, it would be possible to change this.
Boiling the ocean is also possible. In theory anyway... That doesn't make it a good idea or a sensible use of resources. Policy development is already sclerotic. Now imagine just how difficult it will be for the community to reach consensus on a policy to replace last year's shiny version control fad with next year's model. The potential for rat-holing and shed painting will be off-the-scale scary. Let's not forget backwards compatibility issues and having to keep the old platform(s) running because people can't or won't change the stuff they already use and rely on. Locking in the PDP to particular tools or document formats is also stunningly unwise. It's the sort of thing the ITU does. A policy stating "the NCC must use git" is no different from one which states "the NCC must only use vi" or "the NCC must only write code in Java". I'll repeat what I previously said. First identify the problem that needs solving. Then come up with agreed requirements. Once that's done, trust the NCC to choose the right tools and platforms in consultation with the community to deliver the desired outcome(s). Personally, I think all that's needed is to have proposal versions published in a neutral format -- probably plain text -- which allows for the files to be imported into whatever version control tools and document management systems each individual chooses for themself and presumably fits their needs. Whatever the IETF is doing for RFCs and I-Ds might well be good enough.