JDT committers, please
express your opinion on this if you have one,
+1 for adding
[stale] to the subject 0 on whether get
rid of auto-closing
Herrmann <stephan.herrmann@xxxxxxxxx> To:
Re: [jdt-dev] Buffer overflow Sent
Now that Eclipse PMC asks for a vote
among JDT leads / committers, I propose the following compromise:
- stop auto CLOSING
- keep MARKING bugs as stale, PROVIDED that notification mails have a prefix
for local filtering (e.g., "[stale]").
- if notification emails cannot be marked like this: stop stale-marking
I still think that auto closing is counter-productive because searches
for unresolved bugs will no longer find these bugs, although they are not resolved.
So every bug search needs extra fiddling to include WONTFIX stalebug bugs,
but not bugs explicitly marked WONTFIX.
On 14.05.20 15:24, Stephan Herrmann wrote: > Thanks, Dani, > > before reading your responses here I wrote this > > https://www.eclipse.org/mhonarc/lists/eclipse-pmc/msg03833.html > > :) > > On 14.05.20 15:19, Daniel Megert wrote: >> Hi Stephan, >> >> I'm with you. I have hundreds of unread bugs ;-( >> >> I have two ways to work around this: >> 1. I tell people to ping me if something really requires my attention
or >> feedback. >> 2. I add a personal tag for bugs which I'm interested in or need
my attention. >> That way I can actively query them without reading all the e-mails. >> >> HTH >> Dani >> >> >> >> From: Stephan Herrmann <stephan.herrmann@xxxxxxxxx> >> To: "Eclipse JDT general developers list." <jdt-dev@xxxxxxxxxxx> >> Date: 14.05.2020 14:19 >> Subject: [EXTERNAL] [jdt-dev] Buffer overflow >> Sent by: jdt-dev-bounces@xxxxxxxxxxx >> -------------------------------------------------------------------------------- >> >> >> >> 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. >> _______________________________________________ >> jdt-dev mailing list >> jdt-dev@xxxxxxxxxxx >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/jdt-dev >> >> >> >> >> >> _______________________________________________ >> jdt-dev mailing list >> jdt-dev@xxxxxxxxxxx >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/jdt-dev >> > > _______________________________________________ > jdt-dev mailing list > jdt-dev@xxxxxxxxxxx > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jdt-dev