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 <[email protected]>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/
pgpdNTqveVHxm.pgp
Description: PGP signature
