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 No no everyone would have be able to vote veto, only clearing would need response from a 'veteran' developer.
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. Of course, only people who have landed code in the repo at least once do have a vote. Others can only comment, otherwise the code voting would be pretty useless.
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. Well i think you quite didn't get that another point of the proposal was to take out the concept of individuals as module ow.. maintainers. You can submit code, if it's good it gets committed, if not it gets improved. Obviously the prospect of loosing ownership of 'their' code has brought up some fierce opposition though.
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. And to facilitate it, making the community design frameworks for stuff common to many modules' detailed functionality would be a start. That means that in the next few months, we would take part in this process and together engineer those frameworks, as basis for expanding them by our pet code later one.
What you're proposing would actively prevent that. Duh i thoroughly failed to get people to understand my proposal.
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. So you go and veto it, explaining that you are working on something, reasoning why it is the better approach to the problem at hand. 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. So auto-committing stuff after it received 10 vote 'points' and still passing the criterion of breaking no tests and having no coding standard collisions is more dangerous than just committing. Sorry, i do not follow.
Voting on issues to give maintainers feedback on what users think is a high priority? Totally not part of what i proposed. a) no more module maintainers, just (top) contributors. b) no users voting on code.
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. So other devs acknowledging the code before it gets auto committed does not qualify for that description?
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. Well obviously it's not, that's why i proposed something different: a cleverly integrated solution, where the discussion is synced on the mailing list and the patch tracking item.
No, on second though, don't explain it. Just stop. Your proposal gets worse every time you restate it. Maybe people dig deeper and deeper into misunderstanding it, despite me correcting that every single time. It does surely seem useless.
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. So don't frigging subscribe and use the channels you're used to, sheesh.
I don't think you realize just how many patches are submitted every single day just against core, to say nothing of contrib. a) yes i do and b) so because of the sheer amount of code that flows by, quality checks before committing would be a mistake. Sorry that does not convince me.
Just because you like mailing lists doesn't mean we should gut a very effective patch management process. Repeating myself does get ridiculous at some point but anyways: i never proposed to kill working operational procedures, because obviously that'd be stupid.
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. Which makes me miss all the other code that is trying to get into the repo, what a great idea.
Really, Marcel. Do yourself and everyone else a favor and just let it go. I've already given up on making it happen, i'm just fighting for correcting the misunderestimation of the concept. Your proposal was read, considered, and rejected. No, it was read, misunderstood, considered and then rejected. Reasons have been given. Mostly either based on misunderstanding or emotions. And by the way i always get aroused by good points in a rational debate so i am actually looking for them.
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. Really, i'm not. And how many people do have SVN accounts currently? How many of those have voiced their opinion? Does an idea being rejected based on gross misunderstanding actually correlate with the idea?
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. My intent was to propose a solution to the problems i listed in the original posting, i am not going to repeat them.
This proposal is not it. What your idea of it is is definitly not.
-- "Obstacles are those frightful things you see when you take your eyes off your goal." -- Henry Ford (1863-1947) Change the world! Vote: http://hfopi.org/vote-future