For the this metamodel work, you have a very valid point. But taken to the extreme, not really sure average users care about the details of this beyond a single catch all "redesign metamodel". There is obviously a balance here. Also, keep in mind that there is just inherently a difference in granularity for "changelog" versus a "release announcement". All that said, again, I think you are right for this metamodel work. I just want to make sure we dont get into that other extreme or lose sight of the fact that being as granular as possible outside of "broad refactoring work" is generally a good thing. On Thu 01 Mar 2012 10:18:27 AM CST, Hardy Ferentschik wrote: > Hi, > > I noticed that recently we create a lot of "micro" jira issues (just as > an example "missing ; in class xyz"). > Most issues are related to the current metamodel work. I am wondering how > useful that is? > > The metamodel is under heavy development and I think liras should stay on > a functional level, > eg "Implement collection binding", etc. Imagine what's going to happen > once we start running the existing > integration tests against the new metamodel. We will have to change > things left, right and center. Does it make > sense to create Jira issues for each change? I don't think so. > > Also, Jira is not only used by us, but also by our users. They see the > resolved Jiras in the change log > and they also use Jira to find out whether bugs see experience are > already reported. Having all these > micro issues does make this harder imo. > > Is it just me feeling this way? > > --Hardy > ______________________________**_________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/**mailman/listinfo/hibernate-dev<https://lists... > -- steve(a)hibernate.org http://hibernate.org

On Mar 11, 2012, at 2:49 AM, Steve Ebersole wrote: > Another though occurred to me is that one of the really nice things about Jira is keeping track of my todos. If I am working on some piece of code and realize I need to do some work it is much nicer to create a Jira rather than (a) adding a todo comment or (b) getting side-tracked from my current task. > > In the end not sure there is really a right answer here. But ultimately Jira is first and foremost a development team tool. In the end, I am not sure creating less-granular issues is the best choice. In retrospect maybe a separate project for tracking the granular issues might have been better. We would commit work against both a single high-level HHH issue and the particular granular one. Just a brain storm. I think distinguishing between granular and less-granular makes sense. As I already said, I think our public Jira should be more on a less-granular. I remember (back in the days) when I was a Hibernate users and tried to hunt down a problem X. My search chain would be, Google, Forum, Jira. When using Jira I would then often find a bug report for the problem I was seeing. By creating issues on a too  granular level you are making the latter harder imo. Personally I use a different tool for todos, e.g. RememberTheMilk. I don't think that a separate Jira project would be needed for that, nor am I convinced that Jira is the best tool for this type of things. However, if given the choice I would prefer the two Jira instances approach over the single instance one. Or at least give it a try. --Hardy _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev