Moving this out of JIRA. > Thirdly, every time someone asks, "Can it wait till it's on trunk?", all I > hear is, "Can I ignore what you just said and commit this anyway?" If I point > at something and say that its broken its because I'm expecting the patch to > change or an explanation of why I'm wrong. And I'm fine being wrong. It > happens quite often.
Paul, thanks for explaining how this ends up on your end (communication is a two way horse, yay). I can only speak for myself, but I never ever intend to ignore the feedback. Hence my latest reply in this regard to open blocking issues with the comments for the next release off the particular branch a patch goes into. I see where your frustration is coming from now, it wasn't clear before. > But this pattern of submitting patches and asking for all concerns to be > addressed after the patch is in trunk is starting to get a bit annoying. You are saying "all concerns" and I take it as a figure of speech, but the reverse, addressing all concerns (ever so vague and little) is equally frustrating. The solution is clear to me, we need to try and strike a balance. I don't think anyone argues that having a patch mature in JRIA for a few days (or weeks) is bad and equally, once it hits a sweet spot, that it can continue to simmer in a release branch or master and have further kinks worked out as they show up in broader use of that branch. Knowing when to make the cut is the tricky part of course so that we don't have patches rotting on the one side and master erode into a mess on the other. I don't think any sort of policy or process helps here, but we should collectively be aware of the trade-offs we are making and have a natural urgency to get good patches into master and stemming from that an urgency to help mature said patches in JIRA before they do hit master (all modulo this is a volunteer effort, of course :). I feel I am starting to state the obvious here, so I'll leave you with this. Cheers Jan --
