At Mon, 22 Sep 2025 18:20:30 -0700, Elliott Mitchell <ehem+netbsd%m5p.com@localhost> wrote: Subject: Re: irt: Re: Core statement on version control systems > > On Mon, Sep 22, 2025 at 09:53:31AM +0200, Martin Husemann wrote: > > On Mon, Sep 22, 2025 at 04:31:07AM +0000, David Holland wrote: > > > On Mon, Sep 15, 2025 at 08:07:25PM -0700, Elliott Mitchell wrote: > > > > > > > I was going to suggest the only way for Mercurial to have a future was to > > > > adopt Git's file formats and network protocol. > > > > > > You can't adopt Git's file format and data model without also adopting > > > its core design defects and inherent problems. Nonstarter. > > > > Indeed. > > My primary concern is security. CVS got security updates after its > development branch stalled. For Mercurial this means NetBSD will need to > track updates. This also allows for updating Python which has its own > updates. I think that's an important point, but perhaps it's only a longer-term issue. Personally I think there's another "nonstarter" aspect here that's been missed or ignored or at least not widely enough addressed. I talked to Cryo about this at the last two BSDcan conferences, but I've been lax at moving forward on his suggestions to discuss it more widely, so maybe this is a good point to jump in. That's the git(hub) "pull request" issue. If NetBSD is to hope to ever attract younger developers and keep them interested it MUST support the ability for a random stranger to sign up to some well known and easy to use public git "hub", make a clone of NetBSD, commit some changes and push those changes to their public clone on the "hub", and to create a "pull request" that will get prompt attention from the NetBSD project. No mailing lists. No patch sets. Git and only Git on some freely available public "hub". It MUST also be possible and normal and desirable for core NetBSD developers to work back and forth through this git "hub" to address any shortcomings in those changes and to get them into a form that would be acceptable for merging into NetBSD, and eventually to do such a merge. Ideally the merging of any such changes should also retain full attribution (in a line-by-line "git blame"/"cvs annotate" manner) for their original author via that author's identity on the git "hub". At the moment there's a glimmer that the first part of this PR handling will be somewhat possible with GitHub and the existing automatically created hg-to-git conversion hosted there (once there's an absolute guarantee that the hash-tree is 100% locked and stable, that is), however as far as I'm aware there still hasn't been any discussion about the PR and merging a part of the process of accepting third-party changes. From what I can see there indeed are a few "summer of code" projects working partly in this way now, but if I understand correctly this arrangement is individual, between the SofC developer and their mentor(s), and of course so long as the CVS repository is king it requires use of patches and commits "owned" by the core developer and not easily traceable back to their author. I believe this level of interfacing with git-literate developers is paramount to the long-term survival of NetBSD as a project. Git has won the attention of the vast majority of the world -- it is all most new developers from here on in will know and be comfortable with. On the other hand so long as changes can be pulled from some public git "hub" into NetBSD it doesn't currently really matter which backend version control system the official NetBSD source code is managed with by core developers. Perhaps this will become a more important issue as the old guard of developers passes on and new developers take over, but that's for the future to decide. If current developers are more inclined to use Mercurial then that's what it should be for now, provided it is made possible to easily pull changes a public git "hub". -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpWTxuvcotux.pgp
Description: OpenPGP Digital Signature