[development] An alternative to common thinking in 5- > 6migration

[Marcel Partap]

>>  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