qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darryl L. Pierce" <dpie...@redhat.com>
Subject Re: improving cross language maintainability
Date Fri, 20 Dec 2013 16:43:38 GMT
On Thu, Dec 19, 2013 at 04:07:38PM -0500, Rafael Schloming wrote:
> On Thu, Dec 19, 2013 at 9:01 AM, Darryl L. Pierce <dpierce@redhat.com>wrote:
> > On Thu, Dec 19, 2013 at 08:49:59AM -0500, Rafael Schloming wrote:
> > <snip>
> > > I would love to hear thoughts and/or alternative ideas on how to improve
> > > things. I would like to start addressing this early in the 0.7
> > development
> > > cycle.
> >
> > In a similar way, I'm trying to keep our Ruby and Perl bindings in
> > parity as best I can with what's going on in the C and Python code. Can
> > we use JIRA to create umbrella tasks for when new features are added,
> > with subtasks that are binding specific? Or if there's a change to the C
> > code that would require a change in the bindings, have the C code be the
> > top JIRA and the language bindings be subtasks to that? That way I
> > wouldn't need to look through commits to see what's changed in C to know
> > what should be added to the other languages.
> >
> > Also, could we add a component for each of the language bindings? It
> > doesn't feel right to add a JIRA for something in Ruby that's at the
> > Ruby level but have its component be "proton-c".
> >
> 
> It certainly makes sense to make it as easy as possible to track what is
> going on, and I can see how that would help keep bindings up to date where
> there is interest and resources to do so. However we do this though, I
> don't want to just brainlessly duplicate each C jira across every binding
> (not that you're necessarily suggesting this).
> 
> The problem I have with that approach is that there isn't equivalent
> interest/resources associated with each binding, so e.g. if we were to make
> every JIRA a full umbrella that depends on sub tasks for each binding we
> would continually accumulate php jiras that never end up getting closed off
> because we don't keep php as up to date as the other bindings, and this in
> turn would cause the umbrella JIRAs to never get closed off. Jira is really
> a task oriented tool, and I think JIRAs should really only be created when
> there is intention/interest to actually complete the task they represent,
> otherwise they usually end up being noise/clutter that will eventually be
> irrelevant and out of date. I'd suggest that perhaps a more document
> oriented description of those features for which we are trying to keep
> parity would possibly be helpful.

Definitely. Maybe a wiki page that lists the set of feeatures being done
in C can be used as a backlog for the other language bindingss. Not
necessarily a full blown, prioritized scrum backlog. But minimally a
central list of what's done in C/Python that can be used as a guide?

> All that said, I'm certainly sure we can improve our usage of JIRA, and
> I've gone ahead and added ruby-binding, python-binding, perl-binding, and
> php-binding components as you suggest.

Thank you! :D

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/


Mime
View raw message