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
On 1/22/2019 5:04 PM, Michael Richardson wrote:
(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.
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =-
