On Tue, Dec 17, 2013 at 6:28 PM, David Lang <[email protected]> wrote: > 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.
That's a good point. I need to say, though, that not all patches go through the list in any case. If I receive a decent patch, I try to make it easy for the contributor and act on it. I think that's ok - but I wanted to bring it up. Rainer > 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. > _______________________________________________ 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.
