Hi Dave, I like to think votes are a factor in determining what needs doing - but balanced with a view on what will get the most bang-for-the-buck given the limited resource. The team working on it will be expanding shortly and that should make a big difference. However, I do find it annoying that adding votes to a bug doesn't trigger an email but adding a comment does (can I make bugzilla do that? Honestly I've not checked). So new votes can slip by and I'm not aware of the importance people are placing on a feature until i manually go and check it. This happened last week when someone mentioned a problem they were having, I found the related issue in bugzilla and found it had picked up more votes than I thought (it was actually the one related to groovy integration with AspectJ). If I see comments get attached to bugs (triggering emails to me), I do get a feel for what is becoming more important to everyone - and I do see every comment attached to every AspectJ bug/enhancement.
Obviously I'm not going to say the fact that I'm a SpringSource(VMware) employee doesn't influence things - but they have such a diverse set of requirements that I rarely find what they want doesn't line up with what the community is asking for. Three examples right now: - Spring Roo makes massive use of ITDs. This drives requirements on the alternative neater syntax, possibly reviewing name mangling, optimized compilation of ITD based projects and (i'm about to explore this) optimizing reloading of AspectJ woven apps into app servers without requiring them to restart. AJDT also needs to be great to support Roo project development. - Spring Insight makes intense use of load time weaving. It has all the requirements you'd expect: incredibly fast matching, fast weaving, and all whilst using very little memory. - Spring dmServer is implemented as a large number of AspectJ/Java projects. So the behaviour of AJDT and AspectJ incremental compilation needs to be top notch. My day-to-day TODO list is as follows. It is any bug or enhancement assigned the target of the next release (right now, 1.6.7) - anything on that list I will at least review once for the forthcoming release and see if I can get it addressed. If your issue doesn't have a target release, I'm afraid it is off my radar - sometimes deliberately (perhaps it is something I think I'll get to when everything else is 'done', hence it isn't closed), sometimes I've forgotten to attach a target (oops). Bring it back to life by making a comment and I'll review it again. There is an eclipse planning process that I try to follow but I'm a bit lax at times unfortunately. Our planning procedure right now would be that after each release we review the themes we want to look at for the next release. The themes are determined by things that are long overdue to be done, coupled with features that have been voted on that we think make sense this time around. Themes might include 'memory usage' or 'incremental compilation speed'. But obviously things also come up mid cycle that have to brought into plan. The active plan is here: http://www.eclipse.org/projects/project-plan.php?projectid=tools.aspectj and I try to mark bugs that I really want to solve in the forthcoming release with the '[plan]' tag in the bug title. Let me do a quick review of some of those voted bugs - maybe the community will find it interesting. >> Consider extending type pattern matching to support hasmethod(), hasfield() >> votes:33 hasmethod(), hasfield() can't be default until some limitations are addressed. These limitations are not hit by many people but prevent me making it default, and it is so easy to just use the flag -XhasMember to switch it on. I've not seen many complaints about this lately so it hasn't received much focused effort. >> Integrate extension to allow groovy compilation votes:14 A relatively new requirement. I'm actively thinking about this right now but it is HARD to do right. Needs more thinking before keyboard bashing. This is likely to happen within the next few months. >> [tools] AST support for resolving type bindings votes:11 Unfortunately this issue tends to impact those building on top of AJ rather than those actively using it for project development - so that unfortunately drops it down my TODO priorities. It is incredibly hard to fix (in a nice way) due to the way the AspectJ extensions have been made to the underlying compiler. Unfortunately, right now, I can't justify taking a month of my time to get this done. >> Parameter annotation matching to select a subset of arguments votes:11 I would love to do this! I really would! I just can't come up with a syntax/design that doesn't suck. I encourage everyone to have a read and let me know their thoughts. The design must not involve massive changes to the core of AspectJ, and that is what makes it tricky. >> Support Load-Time Weaving and HotSwap votes:5 actively working on this, I just committed a patch to enable it, but it needs further field testing by willing volunteers. >> Add ability to associate user object to join point votes:4 A basic mechanism has been implemented as described in that bug, I need to decide if it is sufficient for now and I can perhaps close this. >> [plan][groovy]Weaving groovy votes:4 Somewhat hand-in-hand with the other groovy item. I need to decide on what it means to weave groovy bytecode. Some people are already doing it (eg. Spring Insight) but AspectJ does not police what does or does not get woven right now in groovy bytecode so they may well accidentally weave groovy infrastructure unintentionally. >> Introduction should not unnecessarily change the public interfaces of >> classes 1 Hope to pick this up as part of my ITD naming review, however I'm not sure anything will change for this *particular* issue, I will just end up with a correct set of documentation available saying why it is how it is. So there you go, a bit of insight into what is being looked at right now. I would encourage everyone to use voting/comments to raise the importance of issues. cheers, Andy 2009/11/19 Dave Whittaker <[email protected]>: > I'm curious about the internal process. I just did a quick bugzilla search > and noticed there are 177 open feature requests and only maybe 10 of them > have any votes. Let me put out the disclaimer that I realize you guys are > under no obligation to prioritize things based on the feelings of us > non-contributing freeloaders, I'm just interested in whether there is a > formal/informal process of determining which feature has the most merit, > whether it has anything to do with votes, and I guess in whether others who > participate on the list actually use the votes to let the developers know > what they'd like to see done next. > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
