Re: SCM
Hi, Thanks to everyone who contributed to this thread; it’s been hella revealing and illuminating to read all the reasoning and technical considerations that have driven the design choices and tool selections that have gone into the OpenBSD Project, especially for someone new to the Project such as myself who hasn’t had the benefit of experiencing the quarter century of context and the biases that come with that. In university courses we’ve been using Git primarily, but I cannot emphasize enough that I am not a big fan of Git; I find it overly complicated, and it would not be a good fit for the OpenBSD Project for myriad reasons. However, the more I use Mercurial, the more I love it. I think there are distinct advantages to a distributed source code management system (I prefer the term ‘source code management’ because to me terms such as ‘software configuration management’ sound not only pretentious but utterly devoid of meaning) over a centralized SCM system such as CVS or Subversion. This article, albeit old and outdated, does a good job summarizing how I feel about Mercurial vs. Git: https://www.ibm.com/developerworks/aix/library/au-mercurial/ However, as much as I personally love Mercurial (and I really think OpenBSD developers would honestly like it too for its simplicity compared to systems like Git), everyone’s thoughtful responses have helped me to appreciate the complexity of considerations (licensing, additional dependencies that would be required in base, etc.) involved. With regard to Subversion vs. CVS, I heard that Subversion was once marketed as something like “CVS done right,” but to me personally I don’t feel there is any way that CVS can be “done right,” so to me Subversion does not represent all that much of an improvement over CVS. In the end I believe the best tools for the job that both have acceptable licenses and have the biggest buy-in among all OpenBSD developers should be the ones used, and to the extent that design decisions continue to be made solely based on technical considerations and not on dogma or ideology, the OpenBSD developer community will continue to make the right decisions for the Project. Thanks for all the insightful and enlightening feedback! Austin “If you want to change the future, start living as if you’re already there.” —Lynn Conway “If you want to change the future, start living as if you’re already there.” —Lynn Conway
Re: SCM
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
SCM
Hi, As someone completely new to OpenBSD the one immediate first impression that most peculiarly sticks out like a sore thumb to me is the Project’s use of CVS for source code management. In the class I’m taking (the one for whose class project I just recently downloaded OpenBSD/macppc for the first time to install on IBM PowerPC 970/970MP-based Apple G5 hardware), we all use git for SCM which I think is typical at most universities nowadays (at least in the U. S.). I am curious why the Project continues to use CVS and/or if developers have in the past considered migrating the codebase to a distributed SCM system like Mercurial which IMHO might make branching and merging easier on developers, especially more recent developers coming out of universities. Is it because the Project prefers using a centralized versus distributed SCM system? Or is it just because that’s just the way it has always been done and why change that? And would migration to something like hg be a possibility in the future that might possibly lower the psychological barrier of entry for newer developers? (And btw this is meant as a sincere question with no intention to start a contentious debate; really just asking out of curiosity because seeing CVS diffs in the mailing lists was what visually jumped out most prominently to me for the first time; I’m sure after spending more time with OpenBSD it could be something I could just get used to.) Thanks for all the wonderful responses to my previous post which really helped me gain a better understanding of the Project! All the best, Austin “If you want to change the future, start living as if you’re already there.” —Lynn Conway
Re: OpenBSD Project
> On July 21, 2019 6:05:28 AM GMT+03:00, bkfuth <[…]> wrote: > > I have used OpenBSD, for years, in my computer security classes. I find > > it best suited for these classes. The governance has never been an > > issue. If you know what you are doing the OpenBSD community is a good > > one. > > Stephen Kolars > > Sent via the Samsung Galaxy Note� 4, an AT&T 4G LTE smartphone > > > > Original message > > From: Ingo Schwarze <[…]> > > Date: 7/20/19 21:44 (GMT-06:00) > > To: freen...@gmail.com > > Cc: misc@openbsd.org > > Subject: Re: OpenBSD Project > > > > Hi,Avstin Kim wrote:> My question is, how is the OpenBSD Project > > governance structured;There is no formal structure and no > > "governance".In day to day business, code owners in parts of the system > > decidewhat is done (for example, espie@ in pkg_add(1), myself in > > mandoc(1),claudio@ in OpenBGPD, gilles@ in OpenSMTPd, jsing@ and beck@ > > inLibreSSL, tj@ redgarding the website, and so on; in some areas,more > > than one person owns the code, sometimes up to a handful).In general, > > the people deciding ask themselves which is the besttechnical solution, > > and if there is consensus among developers, itis done.In the rare cases > > of serious disagreement that cannot be resolvedconsensually, or cannot > > be resolved without excessive delay ordiscussion, deraadt@ reserves the > > right to make a final decision,but that does not happen often.There is > > no core team and certainly, there are never any elections.There are no > > written rules whatsoever, and no introduction of anywritten rules is > > planned for the future. The OpenBSD foundationhas absolutely no say > > about any aspect of the OpenBSD project.None of all this is documented > > anywhere because it doesn't matterfor users of the system.If your > > choice of operating system depends on any kind of formalitiesrather > > than on technical quality, OpenBSD is not the project youare looking > > for.Yours, Ingo > > I can only add that ,from all the mailing lists I'm subscribed , > misc@openbsd is \ > the most active mailing list. > > This means alot for me, and I suspect for anyone else using openBSD. > > Best Regards, > Strahil Nikolov To everyone who took the time to respond, your responses were outstanding; if only a short and sweet additional page could be added to the main OpenBSD Project WWW site (e.g., under “Project Team” or “Developers") that just succinctly summarizes exactly what you all said. For “smaller” projects without formal governance I guess it all comes down to the people; I can see how if you have a dedicated core of really good, passionate developers formal by-laws and committees are superfluous, but then the question is how would that be sustainable over the long term other than just by manually and personally attracting and retaining the best on an ad hoc basis without a codified, structured process. But it seems to be clearly working here. Downloaded the macppc port of OpenBSD 6.5 to install on a couple IBM PowerPC 970/970MP-based Apple Power Mac G5 machines for a class project (I just need some decent, reliable, no-frills servers, but I wanted to try using something other than AMD64/x86-64-based machines for a change) with very low expectations (after trying to install the macppc port of a peer Noteworthy Excellent Tried-and-true BSD distribution which crashed immediately upon running ofwboot off the install ISO), but the installer Just Worked! I don’t understand how this project is able to maintain a working legacy macppc port with so few developers. All the best, Austin “If you want to change the future, start living as if you’re already there.” —Lynn Conway
OpenBSD Project
Hi, I’m trying to choose a simply and permissively licensed operating system to use for a class group project but due to the project timelines don’t have time to try out every BSD-licensed OS out there and am trying to narrow down possibilities. As far as I can tell OpenBSD, NetBSD, and FreeBSD seem comparable in terms of capabilities but Project leadership/governance is also an important consideration for me on principle. My question is, how is the OpenBSD Project governance structured; is the OpenBSD Core Team “democratically” elected as in the FreeBSD Project, or is OpenBSD Core personally appointed only by the currently serving, existing members of the OpenBSD Core Team as in the NetBSD Project? (I mean this question sincerely and was not able to find the answer in any of the online OpenBSD documentation.) Thanks so much in advance! Austin “If you want to change the future, start living as if you’re already there.” —Lynn Conway
