Date: Thu, 2 Apr 2015 11:14:51 -0500 From: "B. Estrade" <estrabd@gmail.com> To: Samuel Cassiba <sam@cassiba.com> Cc: Eitan Adler <lists@eitanadler.com>, freebsd-current Current <freebsd-current@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Bazaaring the cathedral (Lowering the Barrier to Entry) Message-ID: <CALSf6fShwKHmvxkmgAuArPzk8n1JTF1pDA_9TLaU6fx-DZ2LFQ@mail.gmail.com> In-Reply-To: <CAOqvHK9uE_LpwpH4W%2B-RskBd2y5yCfs-wmS8YJDvjZRWUCZ-cA@mail.gmail.com> References: <CAF6rxgk0GR6pj2hTQyHWPiu3c_9NyVb-JzOqPgYhWHW6QQqtmA@mail.gmail.com> <CAOqvHK9uE_LpwpH4W%2B-RskBd2y5yCfs-wmS8YJDvjZRWUCZ-cA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Joke or not, it's worth pointing out that while DragonFlyBSD's approach seems to be a fairly sane hybrid; there is no reason this can't be done within FreeBSD right now. https://www.dragonflybsd.org/docs/developer/TypicalGitUsage/ Anyone can clone, but if you can't commit to the repo then you're asked to register at http://bugs.dragonflybsd.org/ and send your patch over email. DFBSD's GItub repo is just a mirror and FreeBSD has something similar available, including a "GitWorkFlow" document: https://wiki.freebsd.org/GitWorkflow So I don't see why *now* someone couldn't basically follow the same workflow if they wanted to contribute to FreeBSD; namely: * clone mirrored repo/branch from GH * make changes * create a problem report at bugs.freebsd.org * submit patches And if this is not possible, it is likely a procedural impediment and not a technical one. Cheers, Brett On Thu, Apr 2, 2015 at 10:20 AM, Samuel Cassiba <sam@cassiba.com> wrote: > Eitan, > > This being posted on April 1 sets off my BS-o-meter, but I'll bite since > it's a topic worth shaving a yak or two over. > > WARNING: there be perceptions and opinions here > > Having been ephemerally associated with FreeBSD since early 4.x, I never > really saw FreeBSD as being cathedral-like, but the barrier to entry today > feels even higher than it did 15 years ago. I view FreeBSD as being very > much bazaar-like in terms of the actual code that comprises the OS and how > it's treated, but like I must reiterate: the wall is harder to scale today. > > I appreciate the work that everyone has done over the years to bring the > project's infrastructure up to modern times, such as the work done bringing > in CI, a modern bug tracker and an honest to goodness code review tool, but > the general workflow that I learned all those years ago for getting a > change to go live *feels* more or less still the same: > - find/fix bug > - send-pr (okay... but you get the idea) > - pester a committer with the proper access > - ??? > - profit!!! > > The arbitrary nature of how commit bits have historically been allocated > have been more of a detractor than anything, making the the barrier appear > even higher than it may actually be. The general wisdom I learned was "when > you've bugged people often enough to commit your code, they'll burden you > with that ability", which is great in terms of a pure meritocracy, but > we're people and things aren't so black and white. Commit access thresholds > shouldn't be measured in SLOC. > > Yes, the meritocratic way of handling commit access has worked well enough > so far, but it has been at a cost (see FreeBSD's standing in the > mindshare/overall market, as well as number of active FreeBSD committers vs > your favorite big name Linux flavor). Access to the tools that the project > has gravitated towards can be difficult if not impossible to obtain without > a long slog through commit hell to get that sweet @FreeBSD.org spiff. > > Is a "free commit access for anyone!" approach really the answer? It feels > like going from one extreme to the other, and we all know how extremes > work. I feel that commit access should be more transparent, so that if > someone really wants to be able to push code or act as a representative of > the project, they can learn how to work towards that, instead of some > nebulous "push enough code until we get tired of committing it". > > Again, I'm pretty sure this is just a April 1 troll, but it's all worth > saying since the topic was brought up. Lowering the barrier to entry is > good, but the act of doing so mustn't come at a detriment to quality. > > > -Samuel > > On Wed, Apr 1, 2015 at 9:55 AM, Eitan Adler <lists@eitanadler.com> wrote: > > > Hi all, > > > > FreeBSD today has a significant problem of attracting new developers. > > The lack of new developers manifests itself in a dearth of driver > > support, inadequate documentation, and trailing third party packages. > > > > One of the key reasons for the lack of people is the high barrier of > > entry to joining the FreeBSD project. While every modern project uses > > git (usually hosted on github), FreeBSD uses self-hosted subversion. > > The use of git goes beyond just the choice of version control. It > > allows for workflows that FreeBSD can't even dream of. The linux > > kernel has no concept of a committer. Instead anyone can clone the > > git tree, build a kernel, and call themselves a Linux distribution. > > > > Our wiki and code review tools are in an even worse position than our > > repository. In order to contribute you need to send an email to > > clusteradm@ and hope they deem you worthy enough of access. The bug > > tracking system is in a better shape but isn't perfect: while any user > > can create an account, their privileges are limited: they can't help > > close out bad PRs, reclassify good ones, or do other generally useful > > work. > > > > To solve this problem I propose a simple solution: self-serve commit > > access. We create a web service on accounts.freebsd.org via which > > users can create themselves a freefall account. In addition to a > > freefall account, the identical username would be created for the wiki > > and phabricator, bugzilla, and any other service we might provide. > > > > This will allow us to quickly gain large number of contributors, who > > will be able to make better progress on our missing features, and > > rectify some of the drawbacks listed above. > > > > Today I hope we turn ourselves from the cathedral into a truly open > > and democratic project! > > > > > > -- > > Eitan Adler > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALSf6fShwKHmvxkmgAuArPzk8n1JTF1pDA_9TLaU6fx-DZ2LFQ>