On Tue, 17 Dec 2013, Rainer Gerhards wrote:
Hi all,
back to the topic of commit access -- hopefully we can nail this down soon.
As I said, the base rsyslog package (that's the core C code plus the C
modules) is currently managed via the integration manager workflow.
I strongly suggest that everyone not familiar with the principal git
workflows takes two minutes (really! not more) to read this one page (no
need to follow links):
http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows
In a nutshell, "integration manager" means that one person (me currently)
accepts and merges all patches. With the current patch volume, this is no
issue for me. Not even with an increasing workflow.
IMHO this mode has several advantages, among them is security of the code
base and *easier contribution* (contributors don't need to know precisely
which branch to patch - I often receive patches for master branch, which I
redirect to the apropriate "oldest" branch where they need to be applied -
but this is just an example).
Of course, there are new contributors and contributors I know for a long
time. Depending on that, I decide the level of review I need to do. At the
extreme borders, if someone totally unkonwn to me sends a patch, I will
very carefully evaluate what it does and what the use case is. On the other
extreme, if e.g. Brian sendes me something for 0mq, I do no review at all
(why should I? Brian is the expert here!).
In spite of past days discussions, I could assign someone like Brian commit
rights. Unfortunately, I cannot do so on a granular level and I admit that
I would like to have at least the ability to review things that go into
some of the core parts of rsyslog *before* they are committed. I could now
split off those project parts where others are the prime experts.
Unfortunately, this would cause a real big mess when it comes to testing
and release building. I guess it would greatly reduce productivity. For
things that are not C, this split can be done easily -- it just happend for
the doc part. For the C work, I think it is impractical. [Even for non-C,
the release work gets a bit harder, but I currently think this price is
worth to be paid.]
Again, keep in mind that the trusted folks have more or less commit-like
access, in that I ensure their contributions get in timely, at least before
a release.
HOWEVER, for an outsider it is totally unknown who these folks are, and
what they are expert in. It's bad for the average person who maybe wants to
talk or submit a patch to one of them, and of course its also bad for these
contributors in that they miss part of the deserved good standing.
In spite of this, I strongly consider moving to an explicit "Dictator and
Lieutenants" workflow. That's what the Linux kernel does (and better
explaind in above link). I didn't consider this workflow before as it
usually is used in very large projects, and quite uncommon in a projects of
rsyslog's size.
If we implement it, I would also still be accepting code contributions
directly (except if some Lieutenant does not want me to). That's especially
important as probably I am the only one who works full-time on rsyslog
development. So in practice, it would boil down to writing a TEAM
readme-like file that simply explains who the Lieutenats are and how they
can be reached. We could (and probably should) extend that to some
important non-dev functions (like the folks who run the infrastructure).
I think this approachs make the informal project structure more visible and
may hopefully help with finding new contributors. It could also be used to
scale if rsyslog development explodes ;)
What do you think? If this is considered a good idea, I'd talk to those
folks that I think will make Lieutenants and ask if they were willing to
accept the responsibility (and I hope that when I happen to forget someone,
that someone will come and send me a friendly reminder... sometimes the
names only occur to me when a new contribution comes in and the current
"calm" xmas period doesn't help with that ;)).
But first things first: what's your opinion on this idea?
I think the most important thing for now should be that all patches should be
sent to the list rather than being sent to any individuals. I don't want us to
loose visibility to all the changes until the volume of contributions starts
getting high enough to be really annoying to go through. At that point we can
split things so that patches go to the 'right person' (or more likely, a topic
specific mailing list) instead.
I have no problem publishing who the experts are in a particular area so that if
we see patches in that area posted without a response we can call them to that
person's attention. I think it's a great idea.
I just don't want people to start sending patches to that individual rather than
to the list.
David Lang
_______________________________________________
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.
