Hi, Thanks for the description David. Sounds very familiar - projects I've been involved with at Apache work very similarly. I'd say they work completely naturally - this is how people behave - they earn or don't earn trust through their actions.
Otis -- Performance Monitoring * Log Analytics * Search Analytics Solr & Elasticsearch Support * http://sematext.com/ On Mon, Dec 16, 2013 at 2:52 PM, David Lang <[email protected]> wrote: > On Mon, 16 Dec 2013, Brian Knox wrote: > > Any contribution protocol that goes beyond acceptance by a very tight >> knit team of core maintainers is going to have available exploits I'm sure. >> I was putting the document out there more as a nice way to spur some >> conversation than as a suggestion for rsyslog's process. >> >> How to scale an open source project on a social level I think is a more >> interesting (read: difficult) problem than scaling the actual software >> itself! >> > > I strongly suggest that people take a very close look at what the Linux > kernel does for this. There are a lot of studies on this, but it bilds down > to a chain of personal trust > > Linus accepts pull requests from lots of people. Requests from people with > good track records get pulled with no review. Requests from other people > get more review, or he tells the person to submit the patch to the > maintainer of that area (who is supposed to do the review and merge it into > that maintaier's tree before sending it upstream). Some areas of the kernel > have multiple tiers of maintainers. > > In each case, the person sending things upstream is responsible for > everything they send, so they need to either trust the people who are > sending them patches, or they review the patches to their satisfaction > before sending them upstream. > > If someone isn't doing a good enough job of reviewing patches before > sending things upstream, the upstream maintainer starts loosing trust and > slows down accepting patches from that person as they all end up needing > more review. > > > And by the way, a problem patch isn't nessasarily one that causes a > security problem, it can just introduce bugs that make things less reliable > (usually in cases that the patch author was not working on when creating > patches) > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com/professional-services/ > What's up with rsyslog? Follow https://twitter.com/rgerhards > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad > of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you > DON'T LIKE THAT. > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
