Re: IETF Git and GitHub tutorial

[Warren Kumari <[e-mail]>]

On Sun, Oct 13, 2019 at 11:26 AM Michael Richardson <[e-mail]>
wrote:

>
> Sarah Banks <[e-mail]> wrote:
>     > If we were all engineers writing code as a day job perhaps this would
>     > be second nature (or we'd be motivated to not admit we didn't know
> and
>     > we'd figure it out). But we're not all engineers, and git is
>     > unfortunately a tool for engineers. It's not as approachable as it
>     > seems some of us think it is. Thanks for supporting the effort; I do
>     > hope documentation solves the problem :)
>
> I am a strong proponent of design teams using git (and I've used git for ID
> for a long long time, and CVS before that!!!!).
> I consider github just a way for people without public IP addresses to use
> git.  Github issues are also useful for design teams, but unless you do the
> issue full-lifecycle bi-directoinal integration with the mailing list,
> which
> seems non-trivial for WG chairs to organize (I haven't gotten it working),
> then it is hostile to the formation of consensus.
>
> Given that we believe in running-code and then rough consensus, I remain
> a bit skeptical about efforts to make it very easy for
> non-running-code-writers to be major contributors to technical
> specifications.  {Where my thinking breaks down is when it comes to
> non-bits-on-the-wire protocols, such as policy documents}
>
> So, I care less about making it easy for reviewers to be able make
> pull-requests.  I significantly prefer that non-design-team members bring
> their issues to the mailing list, and that they "send text" that way.



As a draft author, I deeply love pull requests — sure, substantive text
should go through discussions, but after 67 instances of:
O: “In other words it is better...”
P: “In other words, it is better...”
C: Nit - you are missing a comma.

Or
“In section 3.1.17.42 there is a missing ‘and’ between the twenty third and
twenty fourth word of the eight paragraph.” (I’ve had a nit report in
basically this way - what made it more fun was that the reporter didn’t
specify the version of the draft, and I’d rewritten section 3.1.17.42 many
times...)

W


>
> I think that the web interface to github is significantly more complex to
> deeply understand than the CLI interface; at least given a OSX or Linux on
> the desktop, and an having gotten over how ssh keys work. (And I consider
> learning about ssh-agent to be something every student should have learned
> before they go on their first work placement, and any 15yr old who wants to
> write code should already know today)
>
> It is only users of that other desktop that seem to have all the problems.
> So, after decades of abuse from the makers of that companies' desktop
> ("This web site is designed for browser X in 1024x768. Please click here
> download ActiveX so that we can p0wn your computer") I feel very very very
> little sympathy.
>
> And as I said in this thread, I don't think that the web interface supports
> the full editing cycle: fork/edit/pull-request/rebase.  Maybe github's new
> masters will find a good UX fix this; but I'd rather that they deployed
> IPv6.
>
> If I thought there was a full-cycle solution with a browser, I'd do a
> screencast of the web interface tomorrow.   If someone would like me to do
> a
> screencast of the CLI version, I would be happy to that this week. (I'm at
> RIPE79)
>
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on
> rails    [
>
> --
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf