On 01/17/2011 08:21 PM, Marnie McCormack wrote:
I think there's a question here about how we go about introducing new
process to the project. Some of us are still discussing QIPs oon this thread
and trying to better understand the point of them, proposed just over a
working week ago.
On the dev list, however, QIP is off and running.
I don't think there is any mandated process in place. However it is
clearly useful to share information about what is planned for the next
release. I don't see that - for those willing to do so - using a
standard structure to do that has any downside. It may even start to
demonstrate some value (or indeed conversely show up any failings) to
anyone sceptical of the idea. For my part I found using the suggested
template quite useful. I could also see the information in it being
useful for others (but that is for 'others' to judge :-).
I'm not sure that having
working processes that some of us use and others don't is a great approach
for the project. I'd have expected us to vote in a new process that we can
reasonably be expected to start using for roadmap items for our next release
?
Is the release manager for the 0.10 release going to be expected to
co-ordinate the work for the release across 2 separate processes on the
project ?
In my view QIPs in *no way* replace JIRAs. Every feature or bug fix
should still have a JIRA associated with the commit(s) and should be
properly tagged for particular release.
The idea behind the QIPs is to flesh out some pertinent details and
provide clear problem statements for planned features. That information,
once refined, would indeed make the associated JIRAs more useful.
At this stage however I don't think we should get too hung up on process
or formality. Whatever works to improve information flow and ensure that
features/components are reasonably well considered and understood by
more than just the author seems like a good thing to me.
From a practical pov, having to download attachments to follow mailing list
discussions is not lightweight - so it'd be good to understand why we need
QIP and what the problem being solved by it is ?
I apologise, I should have pasted them in as plain text or pasted a
link. My mail reader shows text attachments inline anyway so I didn't
realise this was inconvenient until pointed out.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
