17.12.2013 20:55, Rainer Gerhards:
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'm rather sceptical on this model when it comes to rsyslog. First of
all, this model in its traditional form implies two steps (instead of
just one) to get any change to master repo. But you have said already
that you'll be accepting contributions directly. This breaks the model,
it is no longer 'Dictator and Lieutenants'. Let's be clear on terms.
If you see sufficiently wide areas to delegate, it is a good thing to
do. Honestly, there are not so many of them.
Having a TEAM list is a good idea, but for sake of robustness the
maillist (or equivalent media) should be used as primary point of contact.
--
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.
