qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jr...@redhat.com
Subject Re: Qpid Improvement Process
Date Mon, 10 Jan 2011 14:39:42 GMT
Hi, Martin.

On Mon, 10 Jan 2011, Martin Ritchie wrote:

> Hi Justin,
>
> I very much like the QIP proposal my only concern is about its
> potential for endless discussion. I understand that the QIPs have
> timeframes but if discussion has not reached a satisfactory conclusion
> there is an option to defer. Would we have rules on how often we could
> defer a QIP before we had to stop and deal with the issue?

It's my hope that formalizing the proposal document will help to align the
discussion with our goals for upcoming releases.  I don't know if that 
will focus discussion, but I feel like it should at least help.

I'm having trouble imagining a reasonable set of rules for repeated 
deferment.  I do think that if we believe a QIP is complete but not a good 
fit for Qpid's direction, we should reject it, not defer it.  If something 
is a good fit, but we're not ready to accept it, then I don't see a reason 
to limit deferment.

For example, if we accepted a QIP to revamp HA in the next release, we 
might decline to accept another QIP that refactored federation, just 
because these are two far-reaching changes likely to collide.  In a 
scenario like this, I think we'd defer one or the other.

> How are such difficulties addressed by the Gnome and Python projects?

That's a good question, and I don't have an answer.  I'll ask some of the 
folks involved in those projects.

> The proposal suggests to me that a QIP must first be approved before
> any code is written. I think that this would potentially be a bad move
> as ideas often need prototypes to either prove out the idea or to get
> community buy in. How would we address the need for a QIP to have some
> initial development work done in svn?

Ah!  That means I need to be clearer about the intent.  I very much agree 
with you: prototypes or even nearly complete implementations are all to 
the good.  There's no need to wait on an implementation until after your 
QIP is accepted.

As to initial development work in svn, I think branches are the way to go. 
The new time-based release plan makes branches more important, and as you 
point out, so do QIPs.

Justin

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message