[development] An alternative to common thinking in 5- > 6migration
larry at garfieldtech.com
Thu Mar 12 01:36:28 UTC 2009
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
> 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
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 at garfieldtech.com
More information about the development