On Wednesday 11 March 2009 4:03:34 pm Marcel Partap wrote:
To Marcel: The stifle innovation argument is valid although you've called it invalid several times. You have proposed that 10 (not high profile) developer reviews would be required in order to commit code. Assuming you mean what you say and the overloaded developers (high profile) don't have an increased workload, then that means i need 10 reviews to get my code committed.
No that was not exactly what i proposed. The proposal (!) was to have a patch get autocommitted (if style checks run fine and no tests break) by a bot after receiving 10 RTBC vote 'points' and no veto status. The fact that needs to be taken into account here is the level of coding skills and experience of the reviewing person, f.e. by giving people like merlinofchaos chx dries karens etc. (i.e. who have proven to be capable working even on especially complex code) a voting weight of 10 (or 9 maybe.. or whatever) to allow for quicker commital. That'd of course be an arbitrary decision - i'm sure though we could come up with something that worked.
So those "uber devs" with veto status would STILL have to police the rest of the issues to prevent auto-commits after ten people who don't know what they're talking about randomly +1 an issue. Fail. If chx saying +1 on a patch against one of my modules makes the patch commit without me agreeing, then I will not upload any of my modules to CVS. Period. That's not territoriality, that's basic software architecture. Any body of code needs some sort of directed design so that it maintains some level of consistency and coherence. What you're proposing would actively prevent that. Moreover, I may be working toward one particular architectural design decision and some other random patch would break it. Poof, it gets committed and breaks what I'm working on. That is unacceptable. Period. Besides, even uber-devs screw up big time now and again (more often than most people think), and auto-committing in those circumstances just breaks things. Voting on issues to give maintainers feedback on what users think is a high priority? Sure, that's useful information and I've openly said I'm in favor of that before. But the actual commit process MUST be done by a human, not a bot.
The solution i described means that you'd post your code to a drupal-patches mailing list, which would in turn create a patch queue entry. Now anyone just watching could quickly review the code from their mail reader and if they feel like making a decision, do so on the respective, or leave their comments either by replying to the mailing list post or the tracker item, which would in turn be sent to the respective other channel. Now once that piece of core - or a modified version that gets posted later to the tracker item - receives its 10 RTBC points and passes the mentioned checks, it gets committed automatically. That at least was my basic idea which of course might have plenty space for improvement.
Explain to me how having to email patches to a mailing list and then writing a mechanism to parse the patch out and create an issue for it, and then figure out if the patch is a follow-up to another patch (which the vast majority of patches are), and then losing all of the back and forth discussion that happens in the issue queue now is an improvement on having a central location for patches and discussion and screen shots that can be easily tracked, to which you can already subscribe via RSS or email and have been able to do so since long before I was involved in Drupal. No, on second though, don't explain it. Just stop. Your proposal gets worse every time you restate it.
I like mailing lists. Wine-patches is just great for watching code that passes by. It'd be really useful as a tool by itself imho, although those other options already exist. You have to agree there is a slight but notable difference in actively subscribing/seeking something or passively get pushed the new code to your inbox.
You like mailing lists. Great. I hate spam. So do most people. I don't think you realize just how many patches are submitted every single day just against core, to say nothing of contrib. Just because you like mailing lists doesn't mean we should gut a very effective patch management process. You want the patch firehose? Click the subscribe link on any project's issue queue and you can get all the push-based notifications your heart desires. You can do this *right now*, without having to create a few hundred hours work for other people that will just make it more difficult to develop for a project this size. Really, Marcel. Do yourself and everyone else a favor and just let it go. Your proposal was read, considered, and rejected. Reasons have been given. All you're doing is making yourself look like a crybaby because your pet idea was rejected by the people it would affect the most. Since I'm sure that's not what your intent is, I strongly urge you to simply let it go and find some other way to contribute. This proposal is not it. -- Larry Garfield larry@garfieldtech.com