Subject: sr.ht --- "sir hat" --- alternatives to Github

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Jan 2019 13:52:13 -0500

https://lwn.net/Articles/775963/ has an article about sr.ht.
In particular, it says:

As mentioned, sr.ht has not taken the approach of being yet another GitHub
clone. Instead, it is geared toward a mailing-list-centric approach, possibly
using the sr.ht mailing list component. The sr.ht-dev mailing list (seen at
right) provides an example of the user interface for that component. Unlike
some other forges or mailing-list replacements, it is not JavaScript-heavy—in
fact, sr.ht uses no JavaScript at all, so pages are small (less than 10KB on
average) and load quickly.

-----

I think that there may be many IETFers who will see some major advantages.
JavaScript-free, component based, email focused.  Probably also software
we can run ourselves.

I haven't had time to try it yet (just signed up for an account), but I will
put a draft or two on it, and see how I like it.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Richard Barnes <[email-masked]>
Date: Thu, 17 Jan 2019 15:43:13 -0500

This hardly seems like a serious competitor, given that it doesn’t even
really seems to be a thing yet.

Also, a major reason for using Github is going where the audience is.  (The
social network effect mentioned in the article.)  Unless there were some
other serious projects using whatever alternative, it’s hard to see how it
would be compelling.

—RLB

---

From: Leif Johansson <[email-masked]>
Date: Thu, 17 Jan 2019 23:18:23 +0100

> really seems to be a thing yet. 

github wasn't a thing before it was

something about running code and whatever comes to mind

	Cheers Leif

---

From: Lars Eggert <[email-masked]>
Date: Fri, 18 Jan 2019 09:51:20 +0200

On 2019-1-17, at 22:43, Richard Barnes <[email-masked]> wrote:
> Also, a major reason for using Github is going where the audience is.

+1

If it weren't for that, there are a boatload of alternatives.

And of course nobody is stopping a WG to use something other than GitHub.

Lars

---

From: Randy Bush <[email-masked]>
Date: Fri, 18 Jan 2019 06:19:24 -0800

> If it weren't for that, there are a boatload of alternatives.

the problem is that `git clone` is brand conscious

randy

---

From: Richard Barnes <[email-masked]>
Date: Fri, 18 Jan 2019 09:21:46 -0500

> the problem is that `git clone` is brand conscious

Not really?

> git remote rename origin eww-github
> git remote add origin $GITLAB_OR_SIRHAT_OR_WHATEVER

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 18 Jan 2019 09:26:01 -0800

I haven't had time to really take a look at sr.ht, but that's not going to
stop me from commenting!

First, as Lars says, nothing stops people from using some !Github
toolchain, and if it's good, then I'm sure people can vote with their feet.
In general, the workflow here for getting started with a project is to go
to the repo (via URL) git clone it, and then work, so if there were
something !Github that people liked, it would be a pretty straightforward
transition for contributors, modulo the network effects of their
familiarity with Github, existing accounts, etc. The current efforts at
systemization of Github are just paving the cowpaths.

With that said, the design philosophy Michael describes (no JS, mailing
list focused) seems to me to abandon a bunch of what people like about
Github. I know that Linux (for instance) has a mailing-list based process,
but most open source projects I am familiar with prefer a Web-based
process, in particular for code/change review. For instance, both Firefox
and Chromium lean very hard on their online code review tools for patch
development, interdiffs, etc., and wouldn't really want to go back to
e-mail. So, from that perspective, this seems like it might be kind of a
regression in features.

-Ekr

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 21 Jan 2019 06:31:56 +0000 (UTC)

Rather weird to read an entire article talking about 'forges'

that doesn't mention SourceForge, the granddaddy of them all
and originator of the 'forge' thing, which also supports this
fashionable git-du-jour along with other revision control methods.

http://sf.net/

(necessary disclaimer: I've been using SourceForge for projects

 since 2001. As opposed to having just signed up to test the
 waters.)

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...

L.

oh, it's an *IPv6* internet-draft? Ah, right. Do carry on, then.
 
Lloyd Wood [email-masked] http://about.me/lloydwood

________________________________
From: Michael Richardson <[email-masked]>
To: [email-masked]; [email-masked] 
Sent: Friday, 18 January 2019, 5:52
Subject: sr.ht --- "sir hat" --- alternatives to Github

In particular, it says:

-----

we can run ourselves.

--

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 21 Jan 2019 08:18:14 +0100

> 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.)

> 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.)

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 21 Jan 2019 02:41:56 -0500

Carsten, I think you seriously overstate teh case.

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.

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 
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

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 21 Jan 2019 08:47:25 +0100

> On 18 Jan 2019, at 18:26, Eric Rescorla <[email-masked]> wrote:
> 
> I haven't had time to really take a look at sr.ht, but that's not going to stop me from commenting! 
> 
> First, as Lars says, nothing stops people from using some !Github toolchain, and if it's good, then I'm sure people can vote with their feet. In general, the workflow here for getting started with a project is to go to the repo (via URL) git clone it, and then work, so if there were something !Github that people liked, it would be a pretty straightforward transition for contributors, modulo the network effects of their familiarity with Github, existing accounts, etc. The current efforts at systemization of Github are just paving the cowpaths.

+1 to this. 

What we have to be careful about in building processes around repositories in the git WG -- and I haven't yet seen any evidence that would raise concerns that we won't be -- is making sure those processes wrap around GitHub-shaped entities in the ecosystem, as opposed to specifically GitHub itself, and that they provide guidance for the use of features provided by said entities as options, 

If we saw BCPs coming out of the WG that, for example, mandated the GitHub Webhook API for integration with the datatracker as a matter of policy (*), that would be a problem. I trust us not to go there.

Cheers,

Brian

(*) even this would not be all that high a barrier to non-GitHub repository providers, because glue code is easy to write and host, but something like this would be a pretty clear indication to me of too deep an external dependency on a single entity.

> 
> With that said, the design philosophy Michael describes (no JS, mailing list focused) seems to me to abandon a bunch of what people like about Github. I know that Linux (for instance) has a mailing-list based process, but most open source projects I am familiar with prefer a Web-based process, in particular for code/change review. For instance, both Firefox and Chromium lean very hard on their online code review tools for patch development, interdiffs, etc., and wouldn't really want to go back to e-mail. So, from that perspective, this seems like it might be kind of a regression in features.
> 
> -Ekr
> 
> 
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 21 Jan 2019 09:26:16 -0600

> Carsten, I think you seriously overstate teh case.

I agree with this, but not with all of your note.

> 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.

> 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.

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 21 Jan 2019 09:51:40 -0800

> our eixisting archival version control does not seem to pay off.

FWIW, I have been involved in a number of documents where I am the only pen
holder (i.e., I had no co-authors and I was entirely responsible for the
contents of the document) and I still found Git/Github to be a huge
advantage, for several reasons:

- It lets you easily float proposed changes to the document for WG review.
- It allows others to propose changes to you in a fashion which is easy to
review and accept or reject
- It allows you to recover from your own editing mistakes (in the same way
as it's useful to use source code control even on your own projects)

Obviously, others may differ.

> doing that.  Pretty hard to argue with that

This is my understanding as well.

> .  But to the degree that

Yes, I agree with this, and I don't think that this proposed WG is or
should be about pushing people to adopt Git/Github.

However, with that said, if someone came to me and asked me what toolchain
I thought they should use to write an I-D, I would advise them to use
Github.

-Ekr

Yours,
> > 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
> >

---

From: tom petch <[email-masked]>
Date: Tue, 22 Jan 2019 09:56:04 +0000

----- Original Message -----
From: "Benjamin Kaduk" <[email-masked]>
Sent: Monday, January 21, 2019 3:26 PM

> 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.

Tom Petch

> > > 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?

---

From: Richard Barnes <[email-masked]>
Date: Tue, 22 Jan 2019 08:32:51 -0500

> implementing something that executes that design.

That seems like a rather limited approach.  Real design entails
understanding not just the requirements, but also the tools available, and
the costs and benefits of deploying those tools in different ways.

--Richard

---

From: tom petch <[email-masked]>
Date: Tue, 22 Jan 2019 16:50:09 +0000

----- Original Message -----
From: "Richard Barnes" <[email-masked]>
Sent: Tuesday, January 22, 2019 1:32 PM

On Tue, Jan 22, 2019 at 4:56 AM tom petch <[email-masked]>
wrote:

> > > There are costs for using any tool.  In some cases, those costs
are
> more
> > > revision and update control is very helpful.  Git seems to be a
good
> match.
> > 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

That seems like a rather limited approach.  Real design entails
understanding not just the requirements, but also the tools available,
and
the costs and benefits of deploying those tools in different ways.

<tp>
and the really expensive projects, the ones that go off the rails, are
the ones that did not get the requirements right to start with.

My time gets wasted because of the (ab)use of the tools by editors who
are less than considerate and if they are like that with I-D and e-mail,
then they are likely to carry that behaviour over to the use of more
sophisticated tools, unless and until those tools provide a check to
that behaviour.  Often a more automated approach allows the user to
churn out time-consuming material at a faster rate:-(

Tom Petch

--Richard

---

From: Nico Williams <[email-masked]>
Date: Tue, 22 Jan 2019 11:20:44 -0600

> JavaScript-free, component based, email focused.  Probably also software

I don't mind JS, but pages (including the JS they use) must be small.

In fact, I prefer web services to be build as a REST JSON API for
accessing data and performing operations, and a static HTML and JS
front-end that uses that API.  The reasons I like that approach:
a) users immediately get an API they can call from non-browser-based
utilities, b) third parties get an API they can call from their apps,
c) this design greatly reduces page reloads, d) this simplifies
implementation of the service.

I very much like the email focus.  GitHub has a rather limited e-mail
interface that leaves much to be desired (can't use markdown in email,
users don't get email copies of their own comments, no way to create
issues or PRs by e-mail, no way to manage issue metadata via email,
...).

Also, for the IETF we very much need immutable archives, but GitHub and
alike allow editing of comments.  An e-mail gateway would be a good tool
for providing archival of commentary.

> put a draft or two on it, and see how I like it.

I look forward to your report.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 22 Jan 2019 11:25:31 -0600

> going to stop me from commenting!

:)

> toolchain, and if it's good, then I'm sure people can vote with their

My concern is that IETF business conducted off IETF lists might be
problematic.  We have an answer to that: confirm consensus on IETF
mailing lists.  I'm OK with that.  But I would prefer to have a better
e-mail interface from GitHub/GitLab/BitBucket/etc.

> [...]
> 
> With that said, the design philosophy Michael describes (no JS,
> mailing list focused) seems to me to abandon a bunch of what people
> like about Github. I know that Linux (for instance) has a mailing-list
> based process, but most open source projects I am familiar with prefer
> a Web-based process, in particular for code/change review. For
> instance, both Firefox and Chromium lean very hard on their online
> code review tools for patch development, interdiffs, etc., and
> wouldn't really want to go back to e-mail. So, from that perspective,
> this seems like it might be kind of a regression in features.

+1.

I like services that give me a nice REST JSON API and which use JS
judiciously to reduce page reload events.

Nico
--

---

From: "John Levine" <[email-masked]>
Date: 22 Jan 2019 14:51:28 -0500

>e-mail interface from GitHub/GitLab/BitBucket/etc.

It's more than that.  IETF business is supposed to be all subject to
the Note Well which affects patents and other issues. We have a
reasonably well agreed way to put the Note Well on the front page of
github repositories doing IETF work.

If we have random subgroups doing work on other random platforms with
random notices or non-notices, it potentially creates complex messes
that will be hard to clean up.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Tue, 22 Jan 2019 15:51:51 -0500

On 1/21/2019 12:51 PM, Eric Rescorla wrote:
> However, with that said, if someone came to me and asked me what
> toolchain I thought they should use to write an I-D, I would advise
> them to use Github.
>
> -Ekr

Practical.  But why GITHUB?  Why not push for an IETF Git server? 
Full control. Not dependent on 3rd party and you don't have to wait on 
Microsoft/GitHub for any advanced integration with other parts of the 
IETF RFC review/editing/publishing system. Like you indicated, I would 
think most work is under one editor, so it's really an overkill.

I understand the pressure to use what's comfortable with many today, 
so I don't like the idea its being used more and more, sort of forcing 
others to do the same.

PS: We are still using CVS for our products! Very old school, but it 
does the job and no money wasted on duplicity.

That said, is there an RFC on using GitHub for publishing?

-- 
HLS

---

From: Richard Barnes <[email-masked]>
Date: Tue, 22 Jan 2019 16:03:27 -0500

> Practical.  But why GITHUB?  Why not push for an IETF Git server?

Because GitHub > git.  Pull requests, diff views, review requirements, etc.

If you'd said GitLab, maybe more plausible.  But still not a good use of
IETF resources.

> That said, is there an RFC on using GitHub for publishing?

I believe that a WG has been proposed to develop such a thing.  In the
meantime, there's https://github.com/martinthomson/i-d-template/

--RLB

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Jan 2019 13:26:01 -0800

> 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.

-Ekr

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Jan 2019 17:04:11 -0500

(Wow, what a lot of emails about how everyone should have choice, as long as
they choose github.)

The reason I posted about sr.ht is that I strongly feel that authors should
be using some kind of revision control for your xml or markdown files, and
that they should have some automation for formatting them (whether Richard's
wonderful Makefile, five line ones, or a shell script).  I don't care what
people use, but it's hard to host CVS, ClearCase, Mercurial, SVN, etc. unless
you have some routable public address space of your own.  Finding places
that support

There are some people who like git, but don't like the social networking
aspects and issue tracking portion, and want all of this to happen on our
mailing lists.   There are some for whom the lack of native IPv6 is really
embarassing.   (I use NAT64 and DNS64 to access github...)

I saw sr.ht as an answer for those people.  (It doesn't have an IPv6 yet either)
There are also a bunch of people who use bitbucket, as basically storage.

I have personally been using git and a simple Makefile to manage my drafts
for more than a decade.  I have taught quite a few people this process.
I'm really glad that this part has taken off.

While I use github an aweful lot as a way to keep track of things with my
co-authors, I don't particularly like or want to accept new issues that way.
I *way* prefer to have a cogent email on the WG ML, *followed* by a pull
request, ideally with the core of the suggestion in the ML.
While I'm not as old as some, I'm clearly not young anymore.

I see the web interface as often a distraction.  Semi-technical
(i.e. writers with a non-developers background, and young developers who
never left an IDE) think that github *is* git, and don't take the half a day
to actually learn to use git.  I've been through this *repeatedly* in other
fora.  Having said that, let me repeat that I *do* use github for many
things.  But not all things.

---

From: Nico Williams <[email-masked]>
Date: Tue, 22 Jan 2019 16:16:49 -0600

+1

---

From: Hector Santos <[email-masked]>
Date: Tue, 22 Jan 2019 18:31:43 -0500

My opinion.

My only concern is the perception that the IETF is now "requiring" to 
learn a new suite of 3rd party tools for a single purpose - RFC Draft 
submissions publishing.   For people doing this all the time, and 
probably also using the same tools for other parts of their career, I 
can understand it would be productive, but not for the occasional author.

After several decades, I believe an application level IETF online RFC 
publishing tool should be available.  In the past, I used XML2RFC (a 
java app) to outline, produce and publish my drafts. Isn't this 
available any more?   I would think a HTML5 version would be doable 
today, and of course, some vcs would be integrated at the backend.

I personally don't want wish to be learning git details and all the 
other scripting tools and text formats for a single purpose.  I would 
if I have to at some top level rudimentary level just to get the job, 
but it is not desirable, and certainly not a career requirement for me.

I entered this thread only because I do plan to write a few drafts and 
so it was interesting to see the discussion and more people using 
GitHub not only for IETF drafts publishing but also for other things 
like as a common web site to illustrate ideas and concepts.  I rather 
not see that become the norm, but it does shows people need sharable 
tools and web sites within the IETF for IETF purposes.

-- 
HLS

---

From: Christian Huitema <[email-masked]>
Date: Tue, 22 Jan 2019 14:03:20 -1000

>> that will be hard to clean up.

Let's not overdo these process issues. The original proposal by Michael
Richardson was to let draft editors use a source control tool of their
choice, and rely on the working group mailing list for raising and
discussing issues. That was pretty much the norm before many groups
started using GitHub. I don't see how that could possibly be a violation
of the IETF rules.

-- Christian Huitema

---

From: Richard Barnes <[email-masked]>
Date: Tue, 22 Jan 2019 19:20:05 -0500

On Tue, Jan 22, 2019 at 6:32 PM Hector Santos <hsantos=
[email-masked]> wrote:

> submissions publishing.

We already ask people to learn tools!  Have you tried working with a
newcomer through the arcana of xml2rfc?

On the contrary, when I've been working with newcomer coauthors on a draft
in GitHub, and I mention making a new I-D, they're like "Why do we need to
make a special version for IETF?"

To Michael's point, this doesn't advocate for GitHub in particular.  But
clearly wherever possible, we should prefer the tools that contributors
know.  That's how we get the bottom-up contributions we're supposed to
value in this organization.  Personally, my experience is that the people
who are contributing to the stuff I'm working on know GitHub.

--Richard

> For people doing this all the time, and

---

From: tom petch <[email-masked]>
Date: Wed, 23 Jan 2019 10:07:51 +0000

----- Original Message -----
From: "Eric Rescorla" <[email-masked]>
Sent: Tuesday, January 22, 2019 9:26 PM

are
good
existing
am

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

> > > (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
> > > > (Yes, we did projects on Sourceforge when they were the only
play
> in town.
> > > > Yes, they have new management, but I have no idea why one would
go
> back.)

---

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Jan 2019 11:15:28 -0500

Richard Barnes <[email-masked]> wrote:
    > know.

Agreed. And for HTML/web developers, they know github, and should go with
that.  It's a good choice.

The CELLAR WG guys are actually *TOO FAR* onto github, and as co-chair,
I have to ask them to bring things back to the list.

In particular, as noted here and in the WUGH BOF (there isn't a ML by that
name...) that discussion in a pull request does not work well.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Yoav Nir <[email-masked]>
Date: Wed, 23 Jan 2019 21:10:38 +0200

> On 23 Jan 2019, at 12:07, tom petch <[email-masked]> wrote:
>> 

I’m no big fan of GitHub, but it is possible to “watch” a repository and get a web or email notification for every issue or conversation.  It’s not quite the same as having the conversation actually be over email, but it still gets you the conversation delivered in email.

Yoav

---

From: Lars Eggert <[email-masked]>
Date: Thu, 24 Jan 2019 08:56:26 +0200

> I’m no big fan of GitHub, but it is possible to “watch” a repository and get a web or email notification for every issue or conversation.  It’s not quite the same as having the conversation actuall…

And for the QUIC WG, we have created the [email-masked] mailing list that folks can subscribe to, and then receive all the GitHub discussion in email: https://mailarchive.ietf.org/arch/browse/quic-issues/

Lars

---

From: Fernando Gont <[email-masked]>
Date: Thu, 24 Jan 2019 12:23:19 -0300

On 22/1/19 20:31, Hector Santos wrote:
> other scripting tools and text formats for a single purpose.  I would if
> I have to at some top level rudimentary level just to get the job, but
> it is not desirable, and certainly not a career requirement for me.

Don't worry: https://xkcd.com/1597/  (yes, there's a lot of truth to it
:-) )

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Matthew A. Miller" <[email-masked]>
Date: Thu, 24 Jan 2019 08:53:17 -0700

All,

Please direct all further discussion on using GitHub to <
[email-masked] >.

Thank you,

-
Matthew A. Miller
IETF Sergeant-at-arms

---

From: Nico Williams <[email-masked]>
Date: Thu, 24 Jan 2019 10:30:06 -0600

On Wed, Jan 23, 2019 at 09:10:38PM +0200, Yoav Nir wrote:
> I’m no big fan of GitHub, but it is possible to “watch” a repository
> and get a web or email notification for every issue or conversation.
> It’s not quite the same as having the conversation actually be over
> email, but it still gets you the conversation delivered in email.

And if you could get an e-mail for every comment or action you yourself
take, that would be great, and if they all had useful In-Reply-To
headers, then it would be even better, as you could then read all the
traffic in an MUA.

But GH does NOT send you email copies of your comments and actions.

I've considered creating a second GH account to watch all the same repos
that I participate in just so I could get those emails.  But this isn't
user-friendly.

It's such a tiny thing that I'm asking for...

Nico
--

---

From: Bob Hinden <[email-masked]>
Date: Thu, 24 Jan 2019 08:44:46 -0800

Matthew,

Please explain why this discussion shouldn’t be happening on the IETF list?  Seems relevant to me.

Bob

> On Jan 24, 2019, at 7:53 AM, Matthew A. Miller <[email-masked]> wrote:
> 
> All,
>

---

From: "Matthew A. Miller" <[email-masked]>
Date: Thu, 24 Jan 2019 10:48:19 -0700

As per RFC 3005, the general list is intended for initial discussion
until there is a more focused venue.  Since this discussion has evolved
into "to GitHub, or not to GitHub", the appropriate venue is <
[email-masked] >.

This request should have gone out sooner, and I apologize for that
tardiness.

- m&m

Matthew A. Miller

---

From: Lars Eggert <[email-masked]>
Date: Fri, 25 Jan 2019 09:36:52 +0200

> But GH does NOT send you email copies of your comments and actions.

The [email-masked] setup we use does get email for everyone's actions.

How we did this is described in https://larseggert.github.io/github-bcp/#rfc.section.2.2, which was at some point slated to become an appendix in one of the other active drafts, but I think that never happened.

Here is the relevant part:

> In order to allow WG participants to follow the activity on GitHub without needing to check the GitHub web site, we have set up a separate “quic-issues” mailing list at the IETF. It was a deliberate decision to use a list other than the regular WG mailing list. First, because we are intensively using GitHub, a lot of notifications get generated (dozens per day), which would drown out other list traffic, Second, the issues list is configured as a read-only list, where all incoming email is rejected, except for some whitelisted senders. The intent is to keep all discussion on the regular WG mailing list, or on GitHub tickets. (While GitHub will correctly reflect email replies to issue notifications, they seem to loose sender information, which is useless.)
> Getting GitHub notifications to go to this list was mildly painful, and involved creating a dummy “IETF QUIC WG” GitHub user account, whose subscription email address is the quic-issues list address. The dummy user was made a member of the QUIC GitHub organization, and will therefore by default “track” all repo activity. This will cause GitHub to create the desired stream of notification emails to an IETF list. One caveat here is that GitHub uses the email address associated with the user who is interacting with the web site as the sender address of notification emails, which requires regular whitelisting in mailman. It also means that these users are allowed to otherwise email the issues list; we trust they don’t. This email integration is rather dissatisfyingly complex; we’d be interested to learn of a better way.
> 

Lars

---

From: Nico Williams <[email-masked]>
Date: Fri, 25 Jan 2019 10:19:10 -0600

On Fri, Jan 25, 2019 at 09:36:52AM +0200, Lars Eggert wrote:
> How we did this is described in
> https://larseggert.github.io/github-bcp/#rfc.section.2.2, which was at
> some point slated to become an appendix in one of the other active
> drafts, but I think that never happened.
> 

[snip -- a dummy GH user posts notifications to a list]

That's better than what I had in mind (a dummy GH user for _me_), and it
works.  GH needs a better email interface, but this will do.  Perhaps
this should be a standard setup for WGs that use GH a lot, and perhaps
there could be a single dummy GH user doing this for all IETF WGs.

Thanks,

Nico
--

---

From: [email-masked]
Date: Fri, 25 Jan 2019 22:49:25 +0000 (UTC)

+1 to Bob's unanswered question. and why is this new list ietf-and-github and not ietf-and-git? github is but one provider, backed by a proven monopolist... and that was the choice? that's a question suitable for this general list. So, on this thread topic, what viable alternatives are there?
it also strikes me that setting up a mailing list to discuss use of github is not really entering into the spirit of the thing, or showing github's strengths and weaknesses. it's very much the nice face of the idea.
Create a textfile with the mailing list charter, commit it to github, and then have discussions in the commit comments as everyone commits added trailing spaces to that file. if you're going to embrace github in discussions, do it properly...

Lloyd [email-masked]
learn git? if I wanted to learn terse unmemorable commands that do arcane things, I'd learn unix.

On Friday, January 25, 2019, 3:44 am, Bob Hinden <[email-masked]> wrote:

Matthew,

Bob

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 25 Jan 2019 17:12:06 -0600

On Fri, Jan 25, 2019 at 10:49:25PM +0000, lloyd.wood=[email-masked] wrote:
> +1 to Bob's unanswered question. and why is this new list ietf-and-github
> and not ietf-and-git? github is but one provider, backed by a proven
> monopolist... and that was the choice? that's a question suitable for
> this general list. So, on this thread topic, what viable alternatives are
> there?

Suitable perhaps, but hardly timely (nor the list "new") -- per
https://mailarchive.ietf.org/arch/msg/ietf-and-github/S5nDGwYKMOCe7l3ghcCeZItHExk
the list is three years old tomorrow.

-Ben

---

From: Randy Bush <[email-masked]>
Date: Fri, 25 Jan 2019 19:46:43 -0800

> +1 to Bob's unanswered question. and why is this new list
> ietf-and-github and not ietf-and-git? github is but one provider,
> backed by a proven monopolist... and that was the choice?

github, the choice of hipsters flying the open source flag trying to
tell us the one true way.

randy, who runs gogs for when he wants a gui around git

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 26 Jan 2019 13:44:52 -0800

On Fri, Jan 25, 2019 at 2:50 PM <lloyd.wood=[email-masked]>
wrote:

> and not ietf-and-git?

Because Github is what people are actually using, and most of the things
that need to be documented as common practices are not generic to git but
rather to systems like Github and to some extent to Github itself.

github is but one provider, backed by a proven monopolist... and that was
> the choice?

As I said earlier, we're paving the cowpaths. You should of course feel
free to try go get people interested in some alternate solution.

To be honest, I'm not really sure what we're arguing about here. The
situation is this:

1. A bunch of people decided to use Github and felt that it worked well
2. There are now enough people using Github and enough interest from other
people in using it that it seemed like it would be good to have some common
conventions/practices about using it.
3. A WG was proposed to do (2).

Exactly what about this do you object to?

-Ekr

that's a question suitable for this general list. So, on this thread topic,
> what viable alternatives are there?
>
> it also strikes me that setting up a mailing list to discuss use of github
> is not really entering into the spirit of the thing, or showing github's
> strengths and weaknesses. it's very much the nice face of the idea.
>
> Create a textfile with the mailing list charter, commit it to github, and
> then have discussions in the commit comments as everyone commits added
> trailing spaces to that file. if you're going to embrace github in
> discussions, do it properly...
>
>
> Lloyd Wood
> [email-masked]
>
> if

---

From: Alissa Cooper <[email-masked]>
Date: Sat, 26 Jan 2019 21:15:17 -0500

Hi Lloyd,

> On Jan 25, 2019, at 5:49 PM, lloyd.wood=[email-masked] wrote:
> 
> +1 to Bob's unanswered question. and why is this new list ietf-and-github and not ietf-and-git?

Mailing lists are cheap. If people felt that creating a separate one for ietf-and-git would be worthwhile, it wouldn’t be hard to do. As it stands both GitHub and git get discussed on the existing list, and that’s not a problem IMO.

Before initiating chartering of the GIT WG [1] I asked on the ietf-and-github list if people wanted separate lists for the WG and for more general discussion. There was one comment in favor of using ietf-and-github for the WG. That is the current plan.

Alissa

[1] https://datatracker.ietf.org/doc/charter-ietf-git/

> github is but one provider, backed by a proven monopolist... and that was the choice? that's a question suitable for this general list. So, on this thread topic, what viable alternatives are there?
> 
> > On Jan 24, 2019, at 7:53 AM, Matthew A. Miller <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > All,
> > 
> > [email-masked] <mailto:[email-masked]> >.
> > 
> > 
> > Thank you,
> > 
> > -
> > Matthew A. Miller
> > IETF Sergeant-at-arms
> > 
> >> Don't worry: https://xkcd.com/1597/  <https://xkcd.com/1597/>(yes, there's a lot of truth to it
> >> :-) )
> >> 
> >> Thanks,
> >> 
> >

---

From: Alissa Cooper <[email-masked]>
Date: Sat, 26 Jan 2019 21:24:03 -0500

Hi Randy,

> On Jan 25, 2019, at 10:46 PM, Randy Bush <[email-masked]> wrote:
> 

I doubt that anyone who has read the list traffic on the ietf-and-github list would be able to identify the behavior you’re describing there. Please be more considerate of your fellow IETF participants before characterizing them in this way.

Thanks,
Alissa

---

From: [email-masked]
Date: Mon, 28 Jan 2019 11:49:12 +0000 (UTC)

The charter explicitly calls out Github, rather than the more general git.
This is, I think, depending on how you look at it, either an attempt to focus the group or a category error, rather akin to the charters for the DTN groups deciding from the outset that bundling was all that DTN was, and now github is all that git is.
Further category error examples welcomed...
"How can the IETF take advantage of Windows 10? We'll need a wg charter. No, Clippy is not in scope!"

Lloyd [email-masked]
really looking forward to Clippy for GitHub and the Office Git assistant, changing how reviewing is done.

On Sunday, January 27, 2019, 1:15 pm, Alissa Cooper <[email-masked]> wrote:

Hi Lloyd,

Matthew,

Bob

---

From: "John Levine" <[email-masked]>
Date: 28 Jan 2019 14:17:58 -0500

>The charter explicitly calls out Github, rather than the more general git.

Github is not the same as git.  It does all sorts of stuff that a
generic git server does not do.  People use github because they use
the features generic servers don't have. 

I don't see how it is useful to conflate the two.

R's,
John

PS: I run a generic git server on my own system so I speak from
experience here.

---

From: Randy Bush <[email-masked]>
Date: Mon, 28 Jan 2019 13:43:50 -0800

> Github is not the same as git.

which is why lloyd is questioning it being cemented in teh charter

> It does all sorts of stuff that a generic git server does not do.

yep, a whole gui.

but, we're say we're flying the open source flag, and github is closed
source owned by a well-known monster monopoly known for bending and
breaking standards (i have to bleeping use exchange in $dayjb) and a
paperclip avatar.

> People use github because they use the features generic servers don't
> have.

there are open source alternatives, e.g. gogs.

randy

---

From: [email-masked]
Date: Mon, 28 Jan 2019 22:40:50 +0000 (UTC)

is there an open-source alternative to Clippy?
if there is, bet it requires gnome...

Lloyd [email-masked],uk

yep, a whole gui.

randy

---

From: "John R Levine" <[email-masked]>
Date: 28 Jan 2019 17:43:33 -0500

Um, Clippy was completely gone from MS software by 2008, eleven years ago.

Can we complain about something else, like HTML e-mail?

> if there is, bet it requires gnome...

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 28 Jan 2019 22:45:32 +0000

https://www.smore.com/clippy-js

Is there nothing the internet can't deliver?

Nick
(no excuses offered for html + top-posting)

> lloyd.wood=[email-masked] 
> <mailto:lloyd.wood=[email-masked]>
> 28 January 2019 at 22:40
> Randy Bush <mailto:[email-masked]>
> 28 January 2019 at 21:43
> John Levine <mailto:[email-masked]>
> 28 January 2019 at 19:17
>
> lloyd.wood=[email-masked] 
> <mailto:lloyd.wood=[email-masked]>
> 28 January 2019 at 11:49
> This is, I think, depending on how you look at it, either an attempt 
> to focus the group or a category error, rather akin to the charters 
> for the DTN groups deciding from the outset that bundling was all that 
> DTN was, and now github is all that git is.
>
> really looking forward to Clippy for GitHub and the Office Git 
> assistant, changing how reviewing is done.
>

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 28 Jan 2019 23:37:57 +0000 (UTC)

But Linus wanted gnome! and the alternative Vigor runs in Vi...

https://www.businessinsider.com/clippy-microsofts-talking-paperclip-is-back-and-linus-torvalds-loves-it-2013-5

(using IETF discussions as examples to get yahoo to improve its text editors
and offer a text option on mobile is not going as well as I'd hoped.)

On Tuesday, 29 January 2019, 09:46:27 GMT+11, Nick Hilliard <[email-masked]> wrote: 

Nick

>  
>   lloyd.wood=[email-masked]  28 January 2019 at 22:40 
> 
>   Randy Bush  28 January 2019 at 21:43 
> 
>   John Levine  28 January 2019 at 19:17 
> 
> 
>   lloyd.wood=[email-masked]  28 January 2019 at 11:49 
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 28 Jan 2019 18:19:32 -0800

> The charter explicitly calls out Github, rather than the more general git.

Yes, because as I noted previously, most of the conventions that are being
documented depend on the Github UI (e.g., naming, PRs, issues, continuous
integration) or something like it, and are nonsensical in the generic case
of Git

This is, I think, depending on how you look at it, either an attempt to
> focus the group

As I noted previously, it's an attempt to pave the cowpaths of what people
actually use. If you want to invent some non-Github based Git workflow,
then we can have a WG to discuss that too.

-Ekr

or a category error, rather akin to the charters for the DTN groups
> deciding from the outset that bundling was all that DTN was, and now github
> is all that git is.
>
> On Jan 25, 2019, at 5:49 PM, lloyd.wood=40yahoo.co.uk@dmarc..ietf.org
> <lloyd.wood=[email-masked]> wrote:
>
> Mailing lists are cheap. If people felt that creating a separate one for
> ietf-and-git would be worthwhile, it wouldn’t be hard to do. As it stands
> both GitHub and git get discussed on the existing list, and that’s not a
> problem IMO.
>
> Before initiating chartering of the GIT WG [1] I asked on the
> ietf-and-github list if people wanted separate lists for the WG and for
> more general discussion. There was one comment in favor of using
> ietf-and-github for the WG. That is the current plan.
>
> Alissa
>
> [1] https://datatracker..ietf.org/doc/charter-ietf-git/
> <https://datatracker.ietf.org/doc/charter-ietf-git/>
>
> the choice? that's a question suitable for this general list. So, on this
> thread topic, what viable alternatives are there?
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 28 Jan 2019 21:10:01 -0600

> https://www.businessinsider.com/clippy-microsofts-talking-paperclip-is-back-and-linus-torvalds-loves-it-2013-5

Hi all,

We seem to be getting a bit off-topic here.

(And do recall that discussion of the "IETF and github" topic was requested
to be moved to the [email-masked] list.)

-Ben

---

From: Hector Santos <[email-masked]>
Date: Mon, 28 Jan 2019 22:52:13 -0500

On 1/22/2019 7:20 PM, Richard Barnes wrote:
>
>
> On Tue, Jan 22, 2019 at 6:32 PM Hector Santos
> <hsantos=[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     My opinion.
>

I didn't but long ago I had to roll up my sleeves to finally get it 
setup as a tool for the drafts I wrote.  My only point, at this point 
in time, at the application level, it should be available as an editor 
at ietf.org, but online and offline. Higher Bandwidth and Web 3.0 
allows for it.

If GitHub is going to be a new tool WG participants need to learn, 
then write it up. I guess I have to get use to writing README.MD 
files. <g>

> On the contrary, when I've been working with newcomer coauthors on a
> draft in GitHub, and I mention making a new I-D, they're like "Why do
> we need to make a special version for IETF?"
>
> To Michael's point, this doesn't advocate for GitHub in particular.
> But clearly wherever possible, we should prefer the tools that
> contributors know.  That's how we get the bottom-up contributions
> we're supposed to value in this organization.

Of course.

>  Personally, my
> experience is that the people who are contributing to the stuff I'm
> working on know GitHub.

Well, its the "thing" for now.  That's good, it should be written up.

I always felt the IETF was 3rd party independent.  The big elephant in 
the room is no longer a surprise.  Git is a common cvs now and GitHUB 
is the current go-to service.

In a write up, can we do our own GIT server with IETF publishing or 
some other servers?  Maybe we can design a protocol that is 
improvement over GitHub, but I suppose the big productivity 
improvement is the GutHub GUI.

Let's point out, GitHUB is free when your drafts are public storage. 
It is not free if you desire a private repository.  I don't want my 
early non-public drafts appearing in GitHUb Public Repositories.  So 
it is a separate storage -- Local and GitHub.  Git in general allows 
for this peer to peer, peer to server, operation.

Anyway, now I have to find this new list and sign up to learn IETF 
GitHub operations. :)  Here is the subscription page URL:

https://www.ietf.org/mailman/listinfo/ietf-and-github

-- 
HLS

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 28 Jan 2019 21:14:07 -0800

On Mon, Jan 28, 2019 at 7:53 PM Hector Santos <hsantos=
[email-masked]> wrote:

> It is not free if you desire a private repository.

This is no longer true: https://github.blog/2019-01-07-new-year-new-github/

I don't want my

---

From: Hector Santos <[email-masked]>
Date: Wed, 30 Jan 2019 07:08:24 -0500

On 1/29/2019 12:14 AM, Eric Rescorla wrote:
> This is no longer true:
> https://github.blog/2019-01-07-new-year-new-github/

That should change things. Thanks for pointing it out.

-- 
HLS

---

From: [email-masked]
Date: Wed, 30 Jan 2019 21:14:43 +0000 (UTC)

So IETF draft development behaviour is changed by the whim of github corporate policy?

that's nice...

On Wednesday, January 30, 2019, 11:08 pm, Hector Santos <hsantos=[email-masked]> wrote:

-- 
HLS

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Jan 2019 13:17:59 -0800

> So IETF draft development behaviour is changed by the whim of github

Uh, no, because once IETF drafts become drafts, they are developed in the
open.

This change affects how people develop their documents *before* they become
drafts and when they want them to be private.

-Ekr

that's nice...