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! Brian -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Rainer Gerhards Sent: Monday, December 16, 2013 8:35 AM To: rsyslog-users Subject: Re: [rsyslog] contribution policy On Mon, Dec 16, 2013 at 12:38 PM, Brian Knox <[email protected]> wrote: > Rainer - the pull request model works very well for us on the various > ZeroMQ projects. We have a very defined process we follow, but the > heart of it is simply: > > 1) Making a pull request that gets accepted gets you acceptance rights > for the pull requests of others > 2) Once you're on the project, you are allowed to approve pull > requests for anyone other than yourself. > > This ensures that at least one other person than the submitter at > least eyeballed each pull request to make sure there was some level of > sanity to it. > > mhhh... isn't that prone to very simple social engineering? I mean a team of two black hads, where the first does a decent request, maybe more, and the second one introduces the malware? Rainer For the fine details of our process see http://rfc.zeromq.org/spec:16 . > > Note - not suggesting C4 for rsyslog - it would be a pretty drastic > change. I just thought you might get some ideas reading it. > > Brian > > -----Original Message----- > From: [email protected] [mailto: > [email protected]] On Behalf Of Rainer Gerhards > Sent: Sunday, December 15, 2013 4:12 AM > To: rsyslog-users > Subject: Re: [rsyslog] contribution policy > > On Sun, Dec 15, 2013 at 7:27 AM, Otis Gospodnetic < > [email protected]> wrote: > > > Hi, > > > > Btw. why such "fear" around people with different skills? It's not > > like somebody with poor skills will go dabble in the source code and > > force his/her changes on rsyslog dev(s). Why not opt for the route > > that enables and lowers the barriers and worry about issues when and > > IF > they arise? > > > > > I assume you comment on "why not let anyone commit to the code > repository". The reason simply is security. Of course, most people > are honorable, but there are also enough folks out there that would > try to put malware bits into the code. It's easy to contribute via a > pull request, so that should be no show stopper. In fact, I think many > more people would stop using rsyslog if we enabled this way to commit without > required review. > > Rainer > > Otis > > -- > > Performance Monitoring * Log Analytics * Search Analytics Solr & > > Elasticsearch Support * http://sematext.com/ > > > > > > On Sat, Dec 14, 2013 at 3:31 PM, Rainer Gerhards > > <[email protected]>wrote: > > > > > On Sat, Dec 14, 2013 at 8:19 PM, Pavel Levshin > > > <[email protected]> > > > wrote: > > > > > > > > > > > 14.12.2013 22:21, David Lang: > > > > > > > > On Sat, 14 Dec 2013, Rainer Gerhards wrote: > > > >> > > > >>> I've also thought a bit more about the separate repo question. > > > >>> I am > > now > > > >>> again of the view that this is not a problem, but indeed desirable. > > The > > > >>> only thing we need to make sure is that it follows the same > > maintenance > > > >>> policies (regarding versions) that rsyslog does. And that's > > > >>> not very hard. > > > >>> > > > >>> Indeed, the whole doc version issue is not so much a real > > > >>> issue > IMHO. > > > In > > > >>> fact, we just have two of them > > > >>> > > > >>> a) the old legacy stuff used in v5 > > > >>> b) the new stuff used in v6+ > > > >>> > > > >>> That's the main source of confusion. Otherwise, rsyslog always > > > >>> keeps backward-compatibility very high on the priority list. > > > >>> So actually > > all > > > we > > > >>> need is "this parameter/module" is available since ... and you > > > >>> are > > all > > > >>> set. > > > >>> > > > >>> > > > > This is simply wrong. From end user perspective, an user wants > > > > to get accurate and applicable documentation. He cannot > > > > configure 7-stable > > using > > > > docs from 7-devel. It is simple: any "devel" branch has many > > > > cool > > > features > > > > which everyone wants to use, but they are not in "stable". > > > > Everytime > > the > > > > user tries to configure such a feature, he gets feeling that > > > > docs are inaccurate and untrusted. Believe me, I am that user. > > > > > > > > > > > Thanks for the reality check. I honestly never had anticipated that. > > > But you are right, that's my failure. Glad to learn that. > > > > > > > > > > There are some docs which are not version-critical. FAQs, your > > > > blog > > posts > > > > (I mean, this kind of information), etc. They can be maintained > > > separately. > > > > But do they deserve a repository? > > > > > > > > > > > > Back to the repo question: I think a separate repo is of big > > advantage, > > > as > > > >>> access to it, especially commit access, follows quite > > > >>> different > > > paradigms > > > >>> than the main code repository. So I am back to the "let's do a > > separate > > > >>> one" PoV - maybe better earlier than later (so that other > > > >>> folks can > > see > > > >>> what's going on). > > > >>> > > > >>> > > > >>> David, all: anything I overlooked? > > > >>> > > > >> > > > >> My only real concern is that this means that the patch/pull > > > >> request > > for > > > a > > > >> feature and it's documentation now get split up and take two > > > >> different paths. > > > >> > > > >> just from a conceptual level this strikes me as very wrong. It > > > >> may not end up being that bad in practice (again because things > > > >> are fairly > > > small), > > > >> but it will make things harder for people writing new things to > > > >> do the documentation for their changes, and this is an area we > > > >> are already > > > weak in. > > > >> > > > > > > > > This is indeed a big problem, which should not be taken lightly. > > > > You > > > could > > > > make /doc a git submodule, if you want to have it as a separate > > > repository, > > > > while still having it in your working tree. Then, you need to > > syncronize > > > > two repositories everytime. But this way, you can give out /doc > > submodule > > > > to someone, leaving core source under your control. (I did not > > > > use git submodules, but this is how they are used in theory.) > > > > > > > > > > > this sounds interesting, I have to admit not only for doc ;) > > > > > > As a contributor, do you think committing doc to a (totally > > > separate but clearly identifieable) respository is really a big > > > deal? It's a honest question. I admit I would really like to have > > > this separate, as the folks primarily working on it would probably > > > be different (different skill > > set). > > > > > > Thanks again, > > > Rainer > > > > > > > > > > > -- > > > > Pavel Levshin > > > > > > > > _______________________________________________ > > > > 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. > > > > > _______________________________________________ > > 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. > _______________________________________________ > 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. _______________________________________________ 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.
