Hi, On Sun, Dec 15, 2013 at 8:19 PM, David Lang <[email protected]> wrote:
> On Sun, 15 Dec 2013, Otis Gospodnetic wrote: > > 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? >> > > if you give too many people commit authority those people are by > definition forcing their changes on everyone. That's what commit ability > means. > > This is why most successful projects have relatively few committers and > everyone else funnels their changes through that small group. > My comment was in the context of where the doc files live - same or separate repo. But regardless, docs will/can be done via PRs, so only a small number of people or even just Rainer can keep the commit rights. +1 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.
