Skip site navigation (1)Skip section navigation (2)
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>