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?
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.
