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