qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <...@alum.mit.edu>
Subject Re: improving cross language maintainability
Date Thu, 19 Dec 2013 21:07:38 GMT
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.

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.


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