Hi, On Mon, Dec 16, 2013 at 8:35 AM, Rainer Gerhards <[email protected]>wrote:
> 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? Brian - http://rfc.zeromq.org/spec:16 is great! It's pretty much exactly what I've been talking about here over the last week or so (stuff under Goals)! It's nice to see somebody formalized what I felt purely as instinct. :) Rainer - I agree, 2) sounds extreme and I would avoid that. In Apache (and I'm guessing in some other communities) people earn merit over time. Once they earn it they are invited to become committers. Existing committers (actually PMC members in Apache, but that's not important here) vote for or against inviting. Anyone can vote -1 (against) and thus veto a new person becoming a committer. Merit is earned though things like: * solid code patches * documentation contribution * participation in community * non-destructive, collaborative attitude * .... you get the idea... It seems to work well. :) Otis > 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.
