----- Original Message ----- From: "Eric Rescorla" <ekr@xxxxxxxx> Sent: Tuesday, January 22, 2019 9:26 PM On Tue, Jan 22, 2019 at 1:56 AM tom petch wrote: > ----- Original Message ----- > From: "Benjamin Kaduk" <kaduk@xxxxxxx> > Sent: Monday, January 21, 2019 3:26 PM > > > On Mon, Jan 21, 2019 at 02:41:56AM -0500, Joel M. Halpern wrote: > > > Carsten, I think you seriously overstate teh case. > > > > I agree with this, but not with all of your note. > > > > > There are costs for using any tool. In some cases, those costs are > more > > > than paid for by the benefits. In other case, not. > > > > > > We do have basic revision control and archival recovery available > > > already. So the question for using git for developing I-Ds is > whether > > > the additional complexity is warranted by the additional value. > > > > > > In some cases, it has been demonstrated to pay off. Clearly, the > cost > > > is lower if all of the folks working on the document are already > using > > > git for other reasons. Even without that, when there are multiple > > > people actively working on the document, some form of multi-user > > > revision and update control is very helpful. Git seems to be a good > match. > > > > > > Many I-Ds have multiple authors, but in practice only one > pen-holder. > > > Particularly for simpler I-Ds, the benefits of using git to > complement > > > our eixisting archival version control does not seem to pay off. > > > > I'm sure that's true for some people (presumably for you, since you > wrote > > it). But it's not true for me. Using git to complement the existing > I-D > > archive absolutely makes my life easier, even for documents where I am > the > > sole author. > > > > > As I understand it, the current state of play is to allow working > groups > > > to use git when they deem it helpful. ANd the purpose of the > proposed > > > > I think we need to let individuals and groups make their own decisions > > about what and when it is helpful. > > I have always seen the engineers' way of improving the world, as opposed > to most others, as being an approach of understanding the requirements > first, creating a design that meets those requirements and then > implementing something that executes that design. > > Here we seem to be saying that answer is Github, all you have to do is > ensure that your way of working is amended to fit that answer. No, I don't think that's accurate. A number of us found that developing drafts by email was not working for us. We had experience with revision control systems in general and Github in particular, so tried Github, and found it works, refining from there. It's not perfect, but it was close enough to win the make/buy decision. <tp> Of course it works for you but think of the arithmetic. A mailing list has hundreds, may be a thousand or more, people on it of whom a handful, less than ten perhaps, are authoring or editing; the vast majority are just trying to keep up with the proposed changes and comment thereon. What that small number of authors are now doing, at least on some of the lists I follow, is requiring everyone to go to Github to see the changes that they are proposing, perhaps discussing them there and finally coming back to the list with, more or less, a fait accompli. (I have seen an AD wanting to know what discussion there was on the list over an issue to which the answer is none - the discussion took place outside the IETF technology). So I now see e-mails tellling me "This has caused confusion in the past; see <https://github.com/httpwg/http-core/issues/103>. " or >> https://github.com/wkumari/effect-encrypt/commit/974db6cb13faecbf5b1704c 1da580b320843d0b3 or where changes were made, you can see them in the working copy at: https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netconf- subscribed-notifications-11.txt So this technology will be good for the "in-crowd" but potentially bad for peer review and wider participation.. Tom Petch -Ekr > > Tom Petch > > > -Ben > > > > > working group is to write down and agree on common good practices > when > > > doing that. Pretty hard to argue with that. But to the degree that > > > folks make arguments like yours below that seem to be using it as an > > > excuse to argue that we should all use git all the time, I will > object. > > > (To be clear, I do not think that the original proposers were asking > for > > > that, and I am not objecting to the charter as written. I am asking > the > > > folks remember that there are MANY different perspectives both in > terms > > > of tool chains and in terms of the kind of I-Ds that need to be > > > generated. NFSv4 is not the same as QUIC is not the same as the > draft > > > on fragmentation considered harmful.) > > > > > > Yours, > > > Joel > > > > > > On 1/21/19 2:18 AM, Carsten Bormann wrote: > > > >> Rather weird to read an entire article talking about 'forges' > > > >> that doesn’t mention SourceForge, the granddaddy of them all > > > > > > > > Sourceforge is the worst choice I’m aware of. > > > > (Yes, we did projects on Sourceforge when they were the only play > in town. > > > > We got rid of them when they became criminals [drive-by > installers]. > > > > Yes, they have new management, but I have no idea why one would go > back.) > > > > > > > >> My take is that, if you're contemplating using git as a necessary > > > >> tool to help you develop and maintain an internet-draft, you > should > > > >> question why you’re writing an internet-draft in the first > place... > > > > > > > > People who do software know that documents are code and need > revision control as much as the other code. Git is the consensus way to > do collaborative revision control. Why on earth would I use it for > everything else and not for my Internet-Drafts? > > > > > > > > Grüße, Carsten > > > > > > > > (Git is “not necessary” in the same way that toilets are “not > necessary”. > > > > Yes, you can do without, but it is so much cleaner with them, so > they have become the standard.) > > > > > > > > > > > > > > >
