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