Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
On 4/2/15 6:28 PM, Hans Petter Selasky wrote: I hope this is not one more of those April fools :-) yep --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
On 04/01/15 18:55, Eitan Adler wrote: 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. Hi Eitan, Before you speak so nicely about how Linux is doing things, have you ever tried to submit a patch to Linux yourself? I have a bunch of candidates in /usr/ports/multimedia/webcamd/work/webcamd-3.18.0.1/patches (Use this latest tarball: http://home.selasky.org:8192/distfiles/webcamd-4.0.0.2.tar.bz2) which you can start with as a fun experiment ! And then write back when your done. I'm starting counting right now. I have ported a lot of Linux USB drivers to userspace in FreeBSD through the webcamd project, and quite frequently I need to make patches to make the code compile which really should be up-streamed. Sometimes I also find real bugs. Sending the patch to Linux-USB is easy. Getting attention to the patch is hard. Frequent roadblocks in the Linux-USB: - patch must be styled correctly - patch must be send using a certain e-mail program - patch must apply cleanly to the Linux GIT - patch must have a signed-off-by before it can be committed Speaking about USB I don't want FreeBSD-USB to become what Linux-USB is. There are so many mails flowing into Linux-USB every day that no-one is caring to read it all. Getting a decent reply from someone can take months, because of the huge amount of e-mails. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
On Wed, 1 Apr 2015, Eitan Adler wrote: Hi all, 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), As much as I love github - please try to go to http://github.com/freebsd/freebsd-ports and try to view history of one particular port. Example task I am facing right now: I need to compile iojs 1.0.4 using older version of FreeBSD port. Github web interface says to me: Sorry, this commit history is taking too long to generate. Refresh the page to try again, or view this history locally using the following command: git log master -- www/iojs/Makefile Sure one might argue every ports should be a separate repository and we should use git submodules. No, thank you. 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. I am pretty frustrated I can't login to Phabricator without @freebsd.org address. This is something that should be addressed _ReallySoonNow_ I don't follow FreeBSD intrastructure discussions but I don't understand while we jumed from gnats onto bugzilla instead of going straight to Phabricator Maniphest. Also from my Phabricator experience it is still a bit better suited for svn-centralized model than git (although it supports git as well). Today I hope we turn ourselves from the cathedral into a truly open and democratic project! I'd love to have a Phabricator account but despite using FreeBSD since I think version 2.1 and contributing very little I never aspired to get a commit bit. //Marcin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
On Apr 2, 2015 9:44 AM, Chris H bsd-li...@bsdforge.com wrote: IMHO I believe that the height of the bar, is directly proportionate to the quality of the product. We were all new once. There are many reasons - language, social fluidity, economic background, etc. - for which a too-high initial hurdle can make a high bar so insurmountable as to prevent valuable contributors from getting in at all. Mentorship needs to take this into account. The trick is maintaining quality control at higher volumes, without quashing newbie enthusiasm. :) There are tools for managing this somewhat, but open source needs to grow more in this area. Royce ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
On 4/2/15 6:53 AM, Julian H. Stacey wrote: Hans Petter Selasky wrote: I hope this is not one more of those April fools :-) I've been thinking that since Eitan's first post of Wed, 1 Apr 2015 09:55:11 -0700 (18:55 CEST) self-serve commit access I kept wondering what would keep looneys out ? :-) Your experience feeding back to Linux was interesting, I suppose we assume the grass is greener till we hear someone tried it :-) Agreed. Contributing to the git project itself was quite eye opening. They are very particular about the patch format and a few processes involved were very long. They also don't use github. That said, the community was pretty open to the patches (once I got the format correct) and it took about average amount of work to get my code submitted. -Alfred ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
I hope this is not one more of those April fools :-) --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
El 02/04/2015 11:03, Hans Petter Selasky h...@selasky.org escribió: On 04/01/15 18:55, Eitan Adler wrote: 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. Hi Eitan, Before you speak so nicely about how Linux is doing things, have you ever tried to submit a patch to Linux yourself? I have a bunch of candidates in /usr/ports/multimedia/webcamd/work/webcamd-3.18.0.1/patches (Use this latest tarball: http://home.selasky.org:8192/distfiles/webcamd-4.0.0.2.tar.bz2) which you can start with as a fun experiment ! And then write back when your done. I'm starting counting right now. I have ported a lot of Linux USB drivers to userspace in FreeBSD through the webcamd project, and quite frequently I need to make patches to make the code compile which really should be up-streamed. Sometimes I also find real bugs. Sending the patch to Linux-USB is easy. Getting attention to the patch is hard. Frequent roadblocks in the Linux-USB: - patch must be styled correctly - patch must be send using a certain e-mail program - patch must apply cleanly to the Linux GIT - patch must have a signed-off-by before it can be committed I suppose no project is perfect, but all of the above make sense to me. The only thing I disagree is about the mail client. I've never seen that restriction in the documents in the documentation directory of the kernel. I've read restrictions about the format of the mails though. Speaking about USB I don't want FreeBSD-USB to become what Linux-USB is. There are so many mails flowing into Linux-USB every day that no-one is caring to read it all. Getting a decent reply from someone can take months, because of the huge amount of e-mails. Getting attention to the patch being hard is probably because of the amount of patches sent every day, but with a fairly smaller stream of patches in FreeBSD, we have some of them sitting in bugzilla for a really long time. Cheers. --HPS ___ freebsd-hack...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
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 li...@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-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
Hans Petter Selasky wrote: I hope this is not one more of those April fools :-) I've been thinking that since Eitan's first post of Wed, 1 Apr 2015 09:55:11 -0700 (18:55 CEST) self-serve commit access I kept wondering what would keep looneys out ? :-) Your experience feeding back to Linux was interesting, I suppose we assume the grass is greener till we hear someone tried it :-) Fernando, Your mailer software auto fold mechanism is bad, best turn it off. It corrupted quote from Hans Petter. It inserted repeated \n not \n Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Indent previous with . Reply Below as a play script. Send plain text, Not quoted-printable, HTML, or base64. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
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 s...@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 li...@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
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
On Thu, 2 Apr 2015 08:20:57 -0700 Samuel Cassiba s...@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 .. 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. OK. I'll bite... IMHO I believe that the height of the bar, is directly proportionate to the quality of the product. --Chris -Samuel On Wed, Apr 1, 2015 at 9:55 AM, Eitan Adler li...@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-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
On 01/04/2015 19:55, Eitan Adler wrote: 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. Your proposal is incomplete because itd oesn't say anything about booking a mentor. Even if it's a bazaar a neophyte still has to get themselves a mentor, JIMHO. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Bazaaring the cathedral (Lowering the Barrier to Entry)
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-unsubscr...@freebsd.org
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
On Wed, Apr 1, 2015 at 9:55 AM, Eitan Adler li...@eitanadler.com wrote: 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. I support the creation of accounts.freebsd.org. I suggest that we use PWM ( http://code.google.com/p/pwm/ ) as a web-based front-end to a back-end LDAP database. The FreeBSD cluster already has LDAP ( https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#kerberos-ldap ) The FreeBSD cluster LDAP + Kerberos back-end infrastructure is something developed by clusteradm (most likely Peter Wemm). It works quite well. I succeeded in using the FreeBSD cluster LDAP system for Jenkins authentication, and it just worked like a champ. The FreeBSD cluster LDAP system just needs a better front-end that is more user friendly, and easier to manage. If you log into hub.freebsd.org and look at /etc/aliases, you will see that there are 12 people who receive clusteradm e-mails. My experience working with Jenkins is that only about 2-3 people actively do clusteradm work, and they are *way* overloaded. If we could have accounts.freebsd.org which streamlines a lot of the account creation and management, and works across many modern web applications, that would be super cool, and would hopefully reduce the load on clusteradm! -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Bazaaring the cathedral (Lowering the Barrier to Entry)
You mean, like sourceforge offered in 2000? :) -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
