qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Godfrey <rob.j.godf...@gmail.com>
Subject Re: Qpid Improvement Process
Date Mon, 10 Jan 2011 15:38:45 GMT
Hi Justin,

On 6 January 2011 15:42, Justin Ross <jross@redhat.com> wrote:

> Hi, everyone.
>
> I'd like to propose a new way to communicate about the major changes going
> into our releases.  The goal is to help us make decisions early in the
> process, coordinate when a change in one place impacts another, and engender
> a broader sense of direction.  It should also help to document the work that
> we do.
>
>
So, I have a few questions / comments about this.

Firstly I think we need to be clear whether QIPs are describing an end state
(an implied specification), or the act of making the change to the codebase
to achieve the end result (which is what a JIRA is for - surely)?.
Secondly, I think we need to have a better definition of when a change
should be a QIP or not: what constitutes "major"? does a purely internal
refactoring count? what about removing an unloved component?
Next I think we need to understand better how QIPs would relate to JIRAs.
 I'm firmly of the opinion that nothing should be getting in to the codebase
without a JIRA that explains the reason for the change.  That doesn't
necessarily remove the need for a system for recording proposals to change
the "definition" of Qpid... but if I had to chose either a "proposals"
system or a change/defect tracker, I'd choose the latter.

I certainly see a lot of value in tracking "proposals" separately to actual
work tasks (which is what we predominantly have in JIRA right now).  However
I think it is work tasks that make up a release, so it is those (rather than
QIPs) which would be scheduled and tracked.  I'm less sure about using svn
as tool for storing in-process QIPs - it seems unnatural.  Using a wiki or a
workflow (such as JIRA the tool rather than our current instance of it)
seems more obvious.  There is utility in capturing completed QIPs as part of
our documentation if they define an interface or feature that is to be
exposed to our users (or possibly define why a specific feature or interface
has not been defined (or has been removed)). Wiki and JIRA both preserve a
similar level of source control and history to svn.


> To do this, I've imitated an approach that's been used in other community
> software projects.  The Python project, for instance, uses Python
> Enhancement Proposals (PEPs) to review important changes to the Python
> language [1].
>
> I've attempted to produce something very similar here and tie it into our
> release process.  It's my hope that during the 0.10 cycle some contributors
> will opt to describe their major changes using the QIP process.  This is,
> however, entirely optional.
>
>
As above, I'm not sure that QIPs should be what releases are based on.  If a
given QIP can be broken into two (or more) discrete pieces of work which can
then be defined as JIRAs, then it would seem to me that at the point the
release was being cute, then it could be OK (depending on the precise
details of the changes) for it to go out with only some, but not all, of the
JIRAs completed.



> The attached QIP 1 and QIP template should provide an overview of how this
> might work.  This is very much in an early and unrefined form, so I hope
> you'll take a look and share your thoughts.
>
>
As a group I think we need to do a lot more work on trying to define our
goals (whether for an individual release, or more generally in terms of what
we are trying to make Qpid be). And we need to be much better at
understanding how each release is getting us closer to our goal.

As an example, what is it that we are trying to achieve in our next (0.10)
release?  And how will it help our end users?

It is against these goals that I think QIPs need to be evaluated.  I think
the process of planning release priorities may be in terms of QIPs, but more
likely in terms of a mix of QIPS and JIRAs... and every piece of work should
have a JIRA for it before it gets checked in.  If we use the JIRA system
properly we can get a much better overview of the state of the trunk and
(eventually) the release itself.

(As an aside, I'm not sure "Qpid Improvement Process" is a good name to give
these things, they seem more like proposals and an "Improvement Proposal"
still seems more like a task - i.e. a JIRA... )

-- Rob

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message