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.
