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
On Mon, 29 Jul 2019, Mohamed Fouad wrote: fossil is interesting! what - if anything - you don't like about it Roderick? As said, I like it very much, but for bigger projects I would preffer CVS. That fossil is used for bigger projects, is for me a proof of the good quality, reliability of sqlite3. Rod.
Re: SCM
On 7/29/19 1:47 PM, Roderick wrote: What I like of CVS: rcs textfiles, transparency, no strange db. Yep. Fully agreed. git is faster when branching and merging, but if something's wrong in its db/refspecs, you're gonna have a hard time. It's also possible to screw up the svn db (been there, done that). With hg I have no experience. regards, chris
Re: SCM
fossil is interesting! what - if anything - you don't like about it Roderick? On Mon, 29 Jul 2019, 8:51 am Roderick > On Sun, 28 Jul 2019, Nathan Hartman wrote: > > > *IF* the OpenBSD devs ever wants to change SCMs--I said **IF**--then I > > root for Subversion. Subversion offers the following advantages: > > If wants to change just for changing, then there are reasons to select > something else? I realy do not understand this logic that drives this > discussion. > > What I like of CVS: rcs textfiles, transparency, no strange db. That > is a reason for which I would decide for CVS and nothing else for a > bigger project. > > I use fossil for my small programs, better said, misuse, because I > do not use it as a real SCM, but just for backuping history. And I > like it very much. > > Rodrigo > >
Re: SCM
On Sun, 28 Jul 2019, Nathan Hartman wrote: *IF* the OpenBSD devs ever wants to change SCMs--I said **IF**--then I root for Subversion. Subversion offers the following advantages: If wants to change just for changing, then there are reasons to select something else? I realy do not understand this logic that drives this discussion. What I like of CVS: rcs textfiles, transparency, no strange db. That is a reason for which I would decide for CVS and nothing else for a bigger project. I use fossil for my small programs, better said, misuse, because I do not use it as a real SCM, but just for backuping history. And I like it very much. Rodrigo
Re: SCM
Hi, Aaron Mason wrote on Mon, Jul 29, 2019 at 11:21:37AM +1000: > On Mon, Jul 29, 2019 at 3:25 AM Nathan Hartman wrote: >> 9. Apache license. Not BSD but much closer than any GPL revision. > Yeah, hard pass. The Apache license is full of encumbering legalese. > They stopped including Apache in base (after supporting a 1.x tree for > years) for this very reason. Not exactly; the reason for dropping the Apache 1.3 HTTP daemon wasn't licensing, but rather that 1.3 proved a dead end, 2.0 would hardly have been considered no matter the license, whereas nginx looked useful and viable back in the day; nobody expected that nginx would also become unmaintainable within less than three years. But all's well that ends with httpd(8)... :-) You are right, though, that "closer" is not "close enough" in this case: see https://www.openbsd.org/policy.html for details, search for "Apache" in that page. Yours Ingo
Re: SCM
On Mon, Jul 29, 2019 at 3:25 AM Nathan Hartman wrote: (snip) > * Hg does not mean Au. I see what you did there :) > 9. Apache license. Not BSD but much closer than any GPL revision. Yeah, hard pass. The Apache license is full of encumbering legalese. They stopped including Apache in base (after supporting a 1.x tree for years) for this very reason. -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Re: SCM
On Sun, Jul 28, 2019 at 3:27 PM Stefan Sperling wrote: > On Sun, Jul 28, 2019 at 01:24:02PM -0400, Nathan Hartman wrote: > > *IF* the OpenBSD devs ever wants to change SCMs--I said **IF**--then I > > root for Subversion. > > Vetoed, for 3 simple reasons: > (snip) > 3) I don't want to be held responsible when it breaks on Theo > THAT is definitely a valid reason!
Re: SCM
On Sun, Jul 28, 2019 at 01:24:02PM -0400, Nathan Hartman wrote: > *IF* the OpenBSD devs ever wants to change SCMs--I said **IF**--then I > root for Subversion. Vetoed, for 3 simple reasons: 1) Wrong licence 2) FreeBSD uses it 3) I don't want to be held responsible when it breaks on Theo -- Stefan Sperling V.P., Apache Subversion ASF member (https://www.apache.org/foundation/members.html) PGP fingerprint: B1CF 1060 A1E9 34D1 9E86 D6D6 E5D3 0273 F59D 25F0
Re: SCM
On Fri, Jul 26, 2019 at 8:31 PM Австин Ким wrote: > 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). One can cut one's teeth on git and believe whatever one wants to believe but SCMs are not one-size-fits all. * Distributed does not mean better. * Centralized does not mean worse. * CVS does not mean "stuck." * Git does not mean smart. * Hg does not mean Au. Every project has its own requirements and should use the tools that fit best. *IF* the OpenBSD devs ever wants to change SCMs--I said **IF**--then I root for Subversion. Subversion offers the following advantages: 1. CVS's closest relative; fixes all of CVS's shortcomings. 2. Very easy to learn and use. You practically can't screw it up. 3. Immutable history, i.e., SAFE to use. 4. Handles a giant repository with ease. (Many git projects fracture into numerous repositories to work around git limitations, so you lose atomic commits and get a maintenance headache instead.) 5. Sparse checkouts. 6. Versioned properties attached to files and directories (git can't version directories). 7. Follow history through copies, moves, and renames. 8. Coded in C89. Very few dependencies. 9. Apache license. Not BSD but much closer than any GPL revision. I'm sure you've heard bad things about Subversion. These old myths and facts stopped being true a decade ago.
Re: SCM
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
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
Re: SCM
Hi Nathan, Nathan Hartman wrote on Mon, Jul 22, 2019 at 04:25:14PM -0400: > I always assumed that the OpenBSD devs have audited the heck > out of CVS for security issues While many parts of the tree received auditing - and some even get re-autited - that doesn't mean that *all* parts of the tree got audited. In particular, stuff living in the subtree /usr/src/gnu/, an acronym which stands for "Gigantic and Nasty but Unavoidable", is much less likely to receive auditing. For stuff there that is indeed Gigantic, the reason is obvious. But even smaller /gnu/ stuff is less likely to receive auditing for several reasons: 1. It's harder to audit. If you don't apply KNF and don't change the way the code is organized to match OpenBSD conventions, it is obvious why it is hard to audit. If you do, that implies forking. And applying KNF and cleaning up code organization is really a lot of work. 2. With a bad license, it's hardly worth it. Who would want to waste their time auditing GPL'ed code? Who would want to waste their time forking GPL'ed code? It will never become free anyway. So rewriting it from scratch is better - if you have the time. 3. It's less fun. Auditing is (1) easier, (2) more effective, (3) and the more rewarding for the auditor the better the code quality already is. Auditing low-quality or poorly written code is a real pain: slow, tedious, and it constantly keeps you wondering "yeuch, yet another bad habit - should i expunge that one, too, or would that mean going down a rabbit hole and never completing this audit at all?" The latter point no. 3 may scare you. Am i saying that work may not get done because it is not fun? Am i saying that code may not get audited precisely because it is bad quality? Yes, i am. But isn't bad quality code in *more* need of auditing than good quality code? Yes, it is. But we are talking about volunteer work here. Many eyes only make bugs shallow if the code is appealing enough to look at. To a certain degree, we do take importance of work work into account when deciding what to work on. But the fact is, only about 17.8% of us are true masochists (mostly those attending certain ports hackathons, easily reconizable by their explicit T-shirts). That's not nearly enough for getting all of /usr/src/gnu audited. > and are sticking to it for that reason. No, i never heard anyone say that they audited GNU cvs, and it doesn't seem very likely that i missed it. Looking at the commit history, e.g. https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.bin/cvs/src/?sortby=date doesn't suggest it either. There are many bug fixes and it was touched by several specialized tree sweeps (like the "%s" tree sweep a year ago), but i see nothing that looks like an audit. It looks like Stefan Esser & Sebastian Krahmer did some auditing of CVS in 2004, but that was not work done in the context of the OpenBSD project. Besides, sometimes software does get forked for OpenBSD and then thoroughly audited, like Apache 1 was, and then replaced by something leaner anyway, httpd(8) in the case of Apache 1. And as far as i know, henning@ and reyk@ are still on friendly terms with each other. ;-) Yours, Ingo
Re: SCM
The problem with tags/branches is on the input side (parsing RCS files), at least we haven't had good results with cvsps-based tooling or rcsparse-based. I don't think it will make much difference whether conversion is by way of svn or not (except there will be extra conversion-related artefacts going by way of svn). It could likely be fixed on a one off conversion by repo surgery, but as the master repo is unlikely to be switched (various reasons already mentioned in this thread), conversion would need to be on an ongoing basis without constant tweaks.. -- Sent from a phone, apologies for poor formatting. On 23 July 2019 19:42:24 Adam Thompson wrote: On 2019-07-23 12:43, Stuart Henderson wrote: On 2019-07-22, Stefan Sperling wrote: If your university class prefers using git, I'd recommend the repository at https://github.com/openbsd/src. However, it doesn't include branches/tags, because we haven't found anything that is able to successfully convert the OpenBSD CVS repository to git unless it ignores these. I haven't tried this with the OpenBSD code base, but in a previous life I did a CVS to Git conversion starting with a repo that resembled OpenBSD's in many ways. The "solution" was to get to git by way of SVN. SVN was able to preserve branches/tags/etc. from CVS into SVN, and was then able to in turn be converted to git through SVN's git-compatibility layer (IIRC). Whether this helps anyone out there... *shrug* -Adam
Re: SCM
On 2019-07-23 12:43, Stuart Henderson wrote: On 2019-07-22, Stefan Sperling wrote: If your university class prefers using git, I'd recommend the repository at https://github.com/openbsd/src. However, it doesn't include branches/tags, because we haven't found anything that is able to successfully convert the OpenBSD CVS repository to git unless it ignores these. I haven't tried this with the OpenBSD code base, but in a previous life I did a CVS to Git conversion starting with a repo that resembled OpenBSD's in many ways. The "solution" was to get to git by way of SVN. SVN was able to preserve branches/tags/etc. from CVS into SVN, and was then able to in turn be converted to git through SVN's git-compatibility layer (IIRC). Whether this helps anyone out there... *shrug* -Adam
Re: SCM
On 2019-07-22, Stefan Sperling wrote: > > If your university class prefers using git, I'd recommend the repository at > https://github.com/openbsd/src. However, it doesn't include branches/tags, because we haven't found anything that is able to successfully convert the OpenBSD CVS repository to git unless it ignores these.
Re: SCM
Den mån 22 juli 2019 kl 17:05 skrev Австин Ким : > 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. 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! > As Nick Holland wrote here on the same topic: https://marc.info/?l=openbsd-misc=136724343006024=2 the last quote is kind of telling it all: --- Want to sell OpenBSD on an alternative? Find a product that was really crappy, switched development tools, and suddenly started rivaling OpenBSD for quality for no reason other than the switch of development tools. --- -- May the most significant bit of your life be positive.
Re: SCM
On 23/7/19 6:25 am, Nathan Hartman wrote: > I always assumed that the OpenBSD devs have audited the heck out of > CVS for security issues and are sticking to it for that reason. > > KISS is a very valid reason though. Security as a by-product of the KISS principle perhaps? When I see the security track record of OpenBSD, it's hard to argue there's no point in their KISS approach. Especially when you consider the house of horrors that Linux is slowly morphing into. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: SCM
On 23/7/19 1:48 am, Ingo Schwarze wrote: >> Mercurial > Not free software either (same viral license), never used it > personally, and never heard any developer propose it. I believe Mozilla use it heavily. I tried it and frankly, I prefer git. There's also bazaar (used by Canonical), which is aptly named. git does have some nice features for instance being able to 'bisect' change sets when you strike a bug, and 'rebase' for migrating a patch-set to another branch; but given how OpenBSD development appears to operate, some of these features probably don't bring much to justify the distraction of switching. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: SCM
On Mon, Jul 22, 2019 at 11:49 AM Ingo Schwarze wrote: > Avstin Kim wrote on Mon, Jul 22, 2019 at 10:58:50AM -0400: > > > CVS for source code management. > > That's kind of a frequently asked question. > > Some of us (including myself) actually prefer CVS over git for tasks > where it is suffiecient because KISS. > I always assumed that the OpenBSD devs have audited the heck out of CVS for security issues and are sticking to it for that reason. KISS is a very valid reason though. If the project ever did decide to switch, the closest cousin of CVS is SVN, not hg, git, fossil, etc. Apache license...
Re: SCM
On Mon, Jul 22, 2019 at 05:48:13PM +0200, Ingo Schwarze wrote: > Avstin Kim wrote on Mon, Jul 22, 2019 at 10:58:50AM -0400: > > > CVS for source code management. > > That's kind of a frequently asked question. > > Some of us (including myself) actually prefer CVS over git for tasks > where it is suffiecient because KISS. > > Other developers prefer git for various reasons. > > > I am curious why the Project continues to use CVS > > The most important reasons are: > > (1) Switching from CVS to git is extremely hard. Even with the > best tools available, and even when you improve them further, > it is hard, almost impossible, to avoid destroying part of the > history during the conversion of the repository. OpenBSD > values correctness very highly, and it also highly values the > abilty to audit code, including forensic auditing of code > history to determine, once bugs are found, how they were able > to happen. So correctness and completeness of history matters. > > (2) Git is fragile and easy to misuse with surprising consequences. > Well, admittedly, some aspects of CVS are also fragile, but > the number of traps is smaller and developers are already > used to the quirks of CVS, while the more numerous quirks > of git would likely cause surprise and disruption. > > (3) Not all developers are convinced switching is even desirable, > and never change a system that is working well unless there > are strong reasons to change it. I admit, though, that for > very large commits, in particular for Perl updates and for > sweeping infrastructure changes in the ports tree, there > would be undeniable benefits from switching to git. > > (4) 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. > > > if developers have in the past considered migrating the codebase > > to a distributed SCM system > > You can safely bet that they did. > > Actually, switching to git has been considered very seriously > multiple times in the past and may or may not happen one day. > > However, it requires rewriting git from scratch because the reference > implementation of git is not free software. It comes infected with > a viral license. > > That's another reason why switching implies a large effort and an > inevitable distraction from other, arguably more important OpenBSD > development. > > Admittedly, the implementation of CVS we currently use isn't free > software either, it's GPLv1. But we do not introduce any new > non-free software into the tree if there is any way to avoid that. > > > Mercurial > > Not free software either (same viral license), never used it > personally, and never heard any developer propose it. Mercurial would require python in base and maybe someday it will require also Rust. https://www.mercurial-scm.org/wiki/OxidationPlan > > > make branching and merging easier on developers, > > Branching and merging ist strictly prohibited in the OpenBSD > repository. Our development process simply neither needs nor allows > use of these features (except in a trivial way for -stable branches, > which novice developers never work on in the first place), so that's > not an argument at all. > > Yours, > Ingo > > P.S. > Regarding what Raul Miller said: > Git does not require a particular development process but can support > a wide variety of different processes. In particular, you can > require review of patches before push, and you can ban sending out > patchsets and require individual OKs for each indivual patch. So > what you said does not qualify an an argument against using git. > -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: SCM
On 22/07/2019 16:13, Raul Miller wrote: Both git and OpenBSD run on patches. 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. Does that help make sense of the current situation? Raul, Австин, I hope you don't mind me jumping in. Raul's answer raises fascinating questions about the nature of software development and SCM. Using _any_ SCM system and having meaningful discussion among developers before integrating changes is much more important than the choice of actual SCM system. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
Re: SCM
On Mon, Jul 22, 2019 at 10:58:50AM -0400, Австин Ким wrote: > 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 > CVS is good enough for the project for various reasons: - CVS runs on old platforms with very low resources - CVS scales reasonably well enough to the size of the source tree - CVS allows updating individual subdirectories or files; this feature is used by machines building snapshots 24/7 across several CPU architectures from a single source tree - CVS allows developers and users to update their source trees to -current - CVS allows bad commits to be reverted - CVS can cherry-pick commits to -stable branches - Theo would know how to quickly fix a broken CVS repository if needed - Assuming the version control system should be part of base (I would say it should): CVS is GPLv2 and has been in base since the beginning but new GPL software is not allowed in base. The only well-known system with a BSD licence would be fossil which doesn't scale to the size of the source tree. Finding another version control system that satisfies all the above without demanding changes in the environment and processes presently surrounding CVS would not be trivial. Migrating to a different system would be very time-intensive and costly in any case as it would disrupt active developers, build machines, mirrors, and the release process. That said, OpenBSD developers aren't only using CVS. Many are using some complementary version control system locally to keep track of their own changes. They then mail out patches which get committed to CVS and synced back to their private version control systems in some way. There are various workflows developers have come up with to manage their changes: some simply save diffs generated with CVS; some use hg, git, fossil, etc. If your university class prefers using git, I'd recommend the repository at https://github.com/openbsd/src. This should be good enough for educational purposes, even though, officially, it is not supported and could break at any given moment.
Re: SCM
Avstin Kim wrote on Mon, Jul 22, 2019 at 10:58:50AM -0400: > CVS for source code management. That's kind of a frequently asked question. Some of us (including myself) actually prefer CVS over git for tasks where it is suffiecient because KISS. Other developers prefer git for various reasons. > I am curious why the Project continues to use CVS The most important reasons are: (1) Switching from CVS to git is extremely hard. Even with the best tools available, and even when you improve them further, it is hard, almost impossible, to avoid destroying part of the history during the conversion of the repository. OpenBSD values correctness very highly, and it also highly values the abilty to audit code, including forensic auditing of code history to determine, once bugs are found, how they were able to happen. So correctness and completeness of history matters. (2) Git is fragile and easy to misuse with surprising consequences. Well, admittedly, some aspects of CVS are also fragile, but the number of traps is smaller and developers are already used to the quirks of CVS, while the more numerous quirks of git would likely cause surprise and disruption. (3) Not all developers are convinced switching is even desirable, and never change a system that is working well unless there are strong reasons to change it. I admit, though, that for very large commits, in particular for Perl updates and for sweeping infrastructure changes in the ports tree, there would be undeniable benefits from switching to git. (4) 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. > if developers have in the past considered migrating the codebase > to a distributed SCM system You can safely bet that they did. Actually, switching to git has been considered very seriously multiple times in the past and may or may not happen one day. However, it requires rewriting git from scratch because the reference implementation of git is not free software. It comes infected with a viral license. That's another reason why switching implies a large effort and an inevitable distraction from other, arguably more important OpenBSD development. Admittedly, the implementation of CVS we currently use isn't free software either, it's GPLv1. But we do not introduce any new non-free software into the tree if there is any way to avoid that. > Mercurial Not free software either (same viral license), never used it personally, and never heard any developer propose it. > make branching and merging easier on developers, Branching and merging ist strictly prohibited in the OpenBSD repository. Our development process simply neither needs nor allows use of these features (except in a trivial way for -stable branches, which novice developers never work on in the first place), so that's not an argument at all. Yours, Ingo P.S. Regarding what Raul Miller said: Git does not require a particular development process but can support a wide variety of different processes. In particular, you can require review of patches before push, and you can ban sending out patchsets and require individual OKs for each indivual patch. So what you said does not qualify an an argument against using git.
Re: SCM
Both git and OpenBSD run on patches. 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. Does that help make sense of the current situation? -- Raul On Mon, Jul 22, 2019 at 11:04 AM Австин Ким wrote: > > 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: SCM SCR335 SmartCard reader works OK with GnuPG 2 (was Re: [New] gnupg2)
On Sun, Nov 07, 2010 at 10:15:54PM +1100, Olivier Mehani wrote: Ahoy, On Wed, Nov 03, 2010 at 07:31:38AM +0100, David Coppa wrote: It could be fun if someone could test this port with a gnupg smartcard. Hum, I actually have a card reader that I just set up under Linux [0]. My 4.7 is on a remote machine, but I'll try to track down a spare machine and put a fresh 4.8 on it to try it all. It doesn't work. At least the OpenPGP SmartCard V2 I have. This card requires pcsc-lite and ccid. I've ported both and they worked. My work stopped trying to make scdaemon working: threading issues made me give up. I just found time, over the week end, to install 4.8 on said spare machine. My SCM SCR335 USB reader works nicely out of the box with just gnupg-2-0-15. No need for pcsc-lite nor ccid. After starting the GPG agent, I could list and use the keys, both for signing, decryption AND remote SSH login. I jotted down some doc here [0]. Next step is trying to see how to do system auth as well! (; [0] https://www.narf.ssji.net/~shtrom/wiki/tips/openpgpsmartcard#doing_the_same_with_openbsd_48 Nice :) Thanks for your report. Regards, -- Pierre-Emmanuel Andri pea at raveland.org GPG key: 0x7AE329DC
