qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajith Attapattu <rajit...@gmail.com>
Subject Re: Qpid Improvement Process
Date Fri, 07 Jan 2011 15:47:41 GMT
We should probably add all QIPs into wiki.
Maybe the ones accepted could be put somewhere in the source tree or better
yet attach them to the respective JIRA(s).
Since we normally refer to JIRA's in our commit logs, one could easily refer
to a QIP to get a better idea about certain changes.

However I am not too pedantic about where it should go etc..
The important thing is to have some rational process for change management
and that everybody follows it as best as they could.

Rajith

On Fri, Jan 7, 2011 at 10:31 AM, Ken Giusti <kgiusti@redhat.com> wrote:

> Justin - I like this idea.
>
> Will only the approved QIPs be saved into source control?   Seems like a
> good idea to keep the non-approved ones around - if just to have a history
> of feature vetting.
>
> Related: I'd suggest the "Status" section of the QIP document should
> require a rational statement if the final Status is set to Rejected (or even
> Deferred/Withdrawn/Abandoned).  I don't want to have to sniff around the
> mailing list archives to determine why a particular feature was rejected...
>
>
>
> -K
>
> ----- Original Message -----
> > When I sent this I attached some top-level html files, but my mailer
> > seems
> > to have eaten them.
> >
> > The tarball made it through, however. If you look at the output dir
> > inside the tarball, you'll see the QIPs I mentioned in fully rendered
> > form.
> >
> > The other stuff in the tarball is some code to convert QIPs from text
> > format to html and generate an index.
> >
> > Justin
> >
> > On Thu, 6 Jan 2011, Justin Ross 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.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > Thanks,
> > > Justin
> > >
> > > ---
> > > [1] http://www.python.org/dev/peps/pep-0001/
> > >
> >
> > ---------------------------------------------------------------------
> > Apache Qpid - AMQP Messaging Implementation
> > Project: http://qpid.apache.org
> > Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>


-- 
Regards,

Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/

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