I vote to get rid of auto-closing.
If auto-closing remains, then at least add [stale] to mail subject
Gesendet: Donnerstag, 14. Mai 2020 um 16:34 Uhr
Von: "Daniel Megert" <daniel_megert@xxxxxxxxxx>
An: "Eclipse JDT general developers list." <jdt-dev@xxxxxxxxxxx>
Betreff: Re: [jdt-dev] Buffer overflow
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
Dani
From: Stephan Herrmann <stephan.herrmann@xxxxxxxxx>
To: jdt-dev@xxxxxxxxxxx
Date: 14.05.2020 15:48
Subject: [EXTERNAL] Re: [jdt-dev] Buffer overflow
Sent by: jdt-dev-bounces@xxxxxxxxxxx
Now that Eclipse PMC asks for a vote among JDT leads / committers, I propose the
following compromise:
- stop auto CLOSING
but
- keep MARKING bugs as stale, PROVIDED that notification mails have a prefix for
local filtering (e.g., "[stale]").
or
- if notification emails cannot be marked like this: stop stale-marking altogether
WDYT?
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.
Stephan
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
_______________________________________________
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
