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

[Larry Garfield]

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 at garfieldtech.com