On 7/26/19 8:29 PM, Австин Ким wrote:
Hi, all,
Sorry, been hella busy rushing to finish final graduation projects for school
and had no idea so many people weighed in with so much awesome feedback!
That said, OpenBSD has a cultural restriction of requiring people to
inspect the patches before incorporating them. Adopting git would be a
step away from that practice.
I was suggesting Mercurial (hg), not Git; I know Git would be problematic for
the OpenBSD Project in many ways. Plus I find it unnecessarily complex. And
also, regardless of which SCM was used, responsible area owners would obviously
be required to inspect patches before merging into the main branch, so I don't
see why adopting hg would necessarily be a step away from that practice.
Some of us (including myself) actually prefer CVS over git for tasks
where it is suffiecient because KISS.
I definitely appreciate the KISS argument, but I still feel that for new
developers Mercurial would present a lower learning curve than CVS; isn't that
also a fair measure of simplicity (conceptual simplicity)?
it is hard, almost impossible, to avoid destroying part of the
history during the conversion of the repository.
That argument makes sense; but on the flip side that argument also seems a
little fatalistic, basically resigning oneself to being stuck with CVS forever
because no one wants to invest the energy of activation required for migration.
I think back to how the FreeBSD Project moved heaven and earth to migrate from
CVS to SVN, a bold and technically challenging undertaking that impressed the
hell out of me personally; that was also not trivial, and I understand that the
FreeBSD Project has greater staffing and resources, but I honestly believe
OpenBSD developers could be up to the task of even a greater migration, e.g.,
from CVS to Mercurial (but only if >= 99% of the OpenBSD developer community
were all on board, i.e., a consensus of buy-in emerged from the community so
everyone would be all in so as not to engender hurt feelings or animosities).
Almost all developers prefer working on actual quality and
functionality of the system over spending time and effort on
infrastructure around it, unless the latter is really
important to make progress with the former.
I can't argue with that, and obviously code quality is infinitely more
important than what SCM you use, but I feel you run the risk of turning off
potential new developers coming out of colleges and universities who cut their
teeth on distributed SCM systems like hg and Git who might be taken aback at
why the Project is still stuck with CVS (and again, I am not advocating for
Git; though if it isn't obvious by now I really believe OpenBSD developers
would honestly like Mercurial; to me it just seems consistent with OpenBSD's
culture of cleanliness and simplicity). I understand the flip-side argument,
that I'm sure some developers might be personally proud of having arcane CVS
knowledge borne out of slogging through for years with CVS, but to me that
seems more like an issue of personal pride than an indication that CVS is
objectively better than hg.
However, it requires rewriting git from scratch because the reference
implementation of git is not free software. It comes infected with
a viral license.
Isn't CVS also GPL-licensed? Or did OpenBSD completely rewrite CVS from
scratch under a BSD license? Mercurial is still GPL v2, which is at least
better than GPL v3?
Finally my biggest argument (besides making contributing to the Project more
inviting to new developers, especially recent CS/CE/EE graduates) would be that
the bold challenge of migrating the entire codebase from CVS to Mercurial would
present a once-in-a-lifetime opportunity to start over with a fresh, clean
slate, once and for all tackle any issues that plagued working with CVS, and
have the rare opportunity to reset and redefine new processes that capitalize
on a quarter century of OpenBSD developers' working on maintaining a codebase
that is second to none. It would be a monumental, fresh, clean start, albeit
an immensely technically challenging one; but one I have no doubt OpenBSD
developers could surmount.
Mercurial would require python in base and maybe someday it will require
also Rust.
Wow, I have no counter-argument for that :/
Of all the arguments made for CVS over hg, for me this is the one sole argument
I don't have an adequate response to.
Thanks to everyone who shed light on this potentially fraught issue. I really
appreciate eveyone who took the time to write thoughtful, insightful responses,
based on technical considerations as opposed to dogma. I only wish the most
salient points could be distilled and presented on an About page for the
Project for future newbies like myself who are newly coming to OpenBSD without
the quarter century of past context and its concomitant biases and are just
initially struck by seeing a major contemporary project still using CVS.
Thanks so much again!
Austin
“If you want to change the future, start living as if you’re already there.”
—Lynn Conway
IMnotsoHO, what problem are you trying to solve?
My take:
CVS is perhaps the 'assembly language' of SCMS but it *is* simple and
reliable.
I've been hung out to dry by three or four different systems because the
database
got fried and nobody both authorized and knowledgeable was available.
Weekends, you know.
For a relatively small team with good intra-team communication, CVS
is both adequate and easy. OpenBSD has only one trunk. All branches are
private until they are merged into the trunk. This fits CVS very neatly.
The 3 versions under consideration at any time are: the current release,
the head of development, and *for serious problems* the previous release.
For someone *outside* the project, it's very easy [for some value of easy]
to download the head and put it anywhere you want and do what you want
with it. So people interested can use whatever they like. If you want
to look at history, there are no branches: just a sequence which you can
look at with cvsweb if you'd like.
If you want something adopted by OpenBSD it has to fit into current
when it is merged. Notice that diffs supplied are always against the most
recent checked-in version.
I'm not a member of the team - I've had the privilege of contributing
a few small things over the years. From watching, I believe that until
there's
either a great expansion of the project team or some other
very large incentive like cubic $$$ to hire people, CVS will still be the
software management system.
geoff steckel
