[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[jdt-dev] Buffer overflow
|
Dear Team,
No panic, but ...
I know that several bugs and private questions are awaiting a response from me.
Unfortunately, I am at a point where I am no longer able to guarantee any time
to response. According to bugzilla emails, JDT has never before been so active
as it is currently. On the one hand this is really, really great, on the other
hand, the volume of communication is a bit overwhelming for s.o. who is not 24/7
at his JDT-desk to tick off every email the minute it arrives. Right now I have
75 unread bugzilla emails, each of which could be an urgent request for response.
I feel I've become a bottleneck, thus slowing down JDT development if only I
take a few days "off". Assumed or real I feel responsible for 100% of compiler
maintenance (= aside from feature work for new Java versions) plus several other
tasks on top.
Some possible improvements:
I could simply unsubscribe from bugzilla email, and live in peace ... :)
Identify one senior, paid developer, to gradually take over long-term
responsibility for compiler maintenance. At least partially.
For me, it would help a little bit already, if JDT would switch off genie's
auto-closing of bugs. The way this is implemented I feel obliged to check each
and every auto-closed bug in "my" area of development, whether the bug must be
re-opened. This alone takes a significant portion of the time I can allocate for
JDT.
Alternatively, if we definitely don't care about old bugs, why not in one big
blast close *all* old bugs and send notifications to /dev/null? Note that this
would certainly include bugs, where significant time has already been invested,
and bugs where we have identified that ecj violates JLS. Is it OK to send those
bugs to /dev/null???
Other ideas?
This is not about the total time spent for development. Just the ratio doesn't
feel good: too much time on trying to stay up-to-date and deciding priorities
among the set of incoming tasks. Too much task switching.
Stephan
PS: One result of the above: several times recently I gave ill advice one
patches which I only inspected in gerrit, without running the code in the
debugger. Trying to save time to the effect of causing extra churn ... sorry.
