Buffer overflow

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Buffer overflow

stephan.herrmann
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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Buffer overflow

stephan.herrmann
On 14.05.20 14:18, Stephan Herrmann wrote:
> [...]  Right now I have
> 75 unread bugzilla emails, each of which could be an urgent request for response.

While writing this email, the count rose to 89 :-X
_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Buffer overflow

Manoj Palat-2
Hi Steephan,
I am guilty of most of that addition 14 since I am on a marathon of looking at our huge 4.16 targeted bugs and moving out selectively :(

Switching off the auto-close of JDT bugs, I feel is better that *just* closing the old bugs especially as you pointed out significant effort on analysis had gone into many of those bugs.

Regards,
Manoj

-----[hidden email] wrote: -----
To: "Eclipse JDT general developers list." <[hidden email]>
From: Stephan Herrmann
Sent by: [hidden email]
Date: 05/14/2020 05:51PM
Subject: [EXTERNAL] Re: [jdt-dev] Buffer overflow

On 14.05.20 14:18, Stephan Herrmann wrote:
> [...]  Right now I have
> 75 unread bugzilla emails, each of which could be an urgent request for response.

While writing this email, the count rose to 89 :-X
_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev


_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Buffer overflow

Andrey Loskutov
In reply to this post by stephan.herrmann
Same for me.

Thanks to auto-closing my inbox overflows every day.
I also receive ~100 "closing" mails from all SDK projects I'm participating, and I physically have no chance to look into any of them.
I've tried to complain (https://www.eclipse.org/lists/platform-dev/msg01997.html) but then I was told it is good so and since then I directly move all such mails to trash.

I feel the practice to auto-closing "stale" bugs is wrong, even if PMC decided it is good.
It doesn't help anyone, it just adds more stress to few active people left on project.

So from my POV this practice must be stopped - for all projects.

Unfortunately, my mail provider doesn't allow mail *body* filters, so a big help for me personally would be if mail *header* would include [stale/closed] string - I could add a filter in my inbox and move them automatically to /dev/null.

Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov


> Gesendet: Donnerstag, 14. Mai 2020 um 14:18 Uhr
> Von: "Stephan Herrmann" <[hidden email]>
> An: "Eclipse JDT general developers list." <[hidden email]>
> Betreff: [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.
> _______________________________________________
> jdt-dev mailing list
> [hidden email]
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
>
_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Buffer overflow

Paul Pazderski
If you can filter by any header field (and by more than one per filter)
the combination of
  X-Bugzilla-Who: [hidden email]
  X-Bugzilla-Status: CLOSED
  X-Bugzilla-Resolution: WONTFIX
and maybe
  X-Bugzilla-Changed-Fields  /contains/  status_whiteboard
should be enough to only match the auto close mails.

Paul

Am 14.05.2020 um 14:52 schrieb Andrey Loskutov:

> Same for me.
>
> Thanks to auto-closing my inbox overflows every day.
> I also receive ~100 "closing" mails from all SDK projects I'm participating, and I physically have no chance to look into any of them.
> I've tried to complain (https://www.eclipse.org/lists/platform-dev/msg01997.html) but then I was told it is good so and since then I directly move all such mails to trash.
>
> I feel the practice to auto-closing "stale" bugs is wrong, even if PMC decided it is good.
> It doesn't help anyone, it just adds more stress to few active people left on project.
>
> So from my POV this practice must be stopped - for all projects.
>
> Unfortunately, my mail provider doesn't allow mail *body* filters, so a big help for me personally would be if mail *header* would include [stale/closed] string - I could add a filter in my inbox and move them automatically to /dev/null.
>
> Kind regards,
> Andrey Loskutov
>
> Спасение утопающих - дело рук самих утопающих
>
> https://www.eclipse.org/user/aloskutov
>
>
>> Gesendet: Donnerstag, 14. Mai 2020 um 14:18 Uhr
>> Von: "Stephan Herrmann" <[hidden email]>
>> An: "Eclipse JDT general developers list." <[hidden email]>
>> Betreff: [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.
>> _______________________________________________
>> jdt-dev mailing list
>> [hidden email]
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
>>
> _______________________________________________
> jdt-dev mailing list
> [hidden email]
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
>

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Buffer overflow

Daniel Megert
In reply to this post by Andrey Loskutov
I'm with you guys on this. I just want to mention that the auto-close is not causing extra notifications compared to what we had for years where the stale notification was sent but the bug remained open.

Andrey, can you file a bug against bugzilla requesting that [stale] is added to the front of the subject? That also helps to identify such bugs in bugzilla lists. Please share it here.

Dani



From:        "Andrey Loskutov" <[hidden email]>
To:        [hidden email]
Date:        14.05.2020 14:53
Subject:        [EXTERNAL] Re: [jdt-dev] Buffer overflow
Sent by:        [hidden email]




Same for me.

Thanks to auto-closing my inbox overflows every day.
I also receive ~100 "closing" mails from all SDK projects I'm participating, and I physically have no chance to look into any of them.
I've tried to complain (
https://www.eclipse.org/lists/platform-dev/msg01997.html) but then I was told it is good so and since then I directly move all such mails to trash.

I feel the practice to auto-closing "stale" bugs is wrong, even if PMC decided it is good.
It doesn't help anyone, it just adds more stress to few active people left on project.

So from my POV this practice must be stopped - for all projects.

Unfortunately, my mail provider doesn't allow mail *body* filters, so a big help for me personally would be if mail *header* would include [stale/closed] string - I could add a filter in my inbox and move them automatically to /dev/null.

Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov


> Gesendet: Donnerstag, 14. Mai 2020 um 14:18 Uhr
> Von: "Stephan Herrmann" <[hidden email]>
> An: "Eclipse JDT general developers list." <[hidden email]>
> Betreff: [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.
> _______________________________________________
> jdt-dev mailing list
> [hidden email]
> To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
>
_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev




_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Buffer overflow

Daniel Megert
In reply to this post by stephan.herrmann
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 <[hidden email]>
To:        "Eclipse JDT general developers list." <[hidden email]>
Date:        14.05.2020 14:19
Subject:        [EXTERNAL] [jdt-dev] Buffer overflow
Sent by:        [hidden email]




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
[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev





_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Buffer overflow

Andrey Loskutov
In reply to this post by Paul Pazderski
As I've said, *my mail provider* on *server side* doesn't allow me to filter on anything except message subject/sender etc.
I can't configure any filter by any *raw* mail data.

On the client side I could, but I don't use mail clients, I use browser / http access to my mailbox.

Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov


> Gesendet: Donnerstag, 14. Mai 2020 um 15:13 Uhr
> Von: "Paul Pazderski" <[hidden email]>
> An: "Eclipse JDT general developers list." <[hidden email]>
> Betreff: Re: [jdt-dev] Buffer overflow
>
> If you can filter by any header field (and by more than one per filter)
> the combination of
>   X-Bugzilla-Who: [hidden email]
>   X-Bugzilla-Status: CLOSED
>   X-Bugzilla-Resolution: WONTFIX
> and maybe
>   X-Bugzilla-Changed-Fields  /contains/  status_whiteboard
> should be enough to only match the auto close mails.

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Buffer overflow

stephan.herrmann
In reply to this post by Daniel Megert
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 <[hidden email]>
> To: "Eclipse JDT general developers list." <[hidden email]>
> Date: 14.05.2020 14:19
> Subject: [EXTERNAL] [jdt-dev] Buffer overflow
> Sent by: [hidden email]
> --------------------------------------------------------------------------------
>
>
>
> 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
> [hidden email]
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jdt-dev
>
>
>
>
>
> _______________________________________________
> jdt-dev mailing list
> [hidden email]
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
>

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Buffer overflow

stephan.herrmann
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 <[hidden email]>
>> To: "Eclipse JDT general developers list." <[hidden email]>
>> Date: 14.05.2020 14:19
>> Subject: [EXTERNAL] [jdt-dev] Buffer overflow
>> Sent by: [hidden email]
>> --------------------------------------------------------------------------------
>>
>>
>>
>> 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
>> [hidden email]
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jdt-dev
>>
>>
>>
>>
>>
>> _______________________________________________
>> jdt-dev mailing list
>> [hidden email]
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jdt-dev
>>
>
> _______________________________________________
> jdt-dev mailing list
> [hidden email]
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jdt-dev

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Buffer overflow

Daniel Megert
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 <[hidden email]>
To:        [hidden email]
Date:        14.05.2020 15:48
Subject:        [EXTERNAL] Re: [jdt-dev] Buffer overflow
Sent by:        [hidden email]




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 <[hidden email]>
>> To: "Eclipse JDT general developers list." <[hidden email]>
>> Date: 14.05.2020 14:19
>> Subject: [EXTERNAL] [jdt-dev] Buffer overflow
>> Sent by: [hidden email]
>> --------------------------------------------------------------------------------
>>
>>
>>
>> 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
>> [hidden email]
>> To unsubscribe from this list, visit
>>
https://www.eclipse.org/mailman/listinfo/jdt-dev
>>
>>
>>
>>
>>
>> _______________________________________________
>> jdt-dev mailing list
>> [hidden email]
>> To unsubscribe from this list, visit
>>
https://www.eclipse.org/mailman/listinfo/jdt-dev
>>
>
> _______________________________________________
> jdt-dev mailing list
> [hidden email]
> To unsubscribe from this list, visit
>
https://www.eclipse.org/mailman/listinfo/jdt-dev

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev





_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Buffer overflow

Jayaprakash Arthanareeswaran
In reply to this post by stephan.herrmann
From Stephan's mails, I initially thought it's not as much about filtering out emails as it is about taking care that still-relevant-bugs are given due attention.

But now I see it is both.

As a JDT lead, I give my +1 for not closing the stale bugs. As for sending notification, I am fine either way.

Regards,
Jay

[hidden email] wrote: -----
To: [hidden email]
From: Stephan Herrmann
Sent by: [hidden email]
Date: 05/14/2020 07:18PM
Subject: [EXTERNAL] Re: [jdt-dev] Buffer overflow

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 <[hidden email]>
>> To: "Eclipse JDT general developers list." <[hidden email]>
>> Date: 14.05.2020 14:19
>> Subject: [EXTERNAL] [jdt-dev] Buffer overflow
>> Sent by: [hidden email]
>> --------------------------------------------------------------------------------
>>
>>
>>
>> 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
>> [hidden email]
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jdt-dev
>>
>>
>>
>>
>>
>> _______________________________________________
>> jdt-dev mailing list
>> [hidden email]
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jdt-dev
>>
>
> _______________________________________________
> jdt-dev mailing list
> [hidden email]
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jdt-dev

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev



_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Buffer overflow

Andrey Loskutov
In reply to this post by Daniel Megert
I vote to get rid of auto-closing.
If auto-closing remains, then at least add [stale] to mail subject
 
Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov
 
 
Gesendet: Donnerstag, 14. Mai 2020 um 16:34 Uhr
Von: "Daniel Megert" <[hidden email]>
An: "Eclipse JDT general developers list." <[hidden email]>
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 <[hidden email]>
To:        [hidden email]
Date:        14.05.2020 15:48
Subject:        [EXTERNAL] Re: [jdt-dev] Buffer overflow
Sent by:        [hidden email]



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 <[hidden email]>
>> To: "Eclipse JDT general developers list." <[hidden email]>
>> Date: 14.05.2020 14:19
>> Subject: [EXTERNAL] [jdt-dev] Buffer overflow
>> Sent by: [hidden email]
>> --------------------------------------------------------------------------------
>>
>>
>>
>> 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
>> [hidden email]
>> To unsubscribe from this list, visit
>>
https://www.eclipse.org/mailman/listinfo/jdt-dev
>>
>>
>>
>>
>>
>> _______________________________________________
>> jdt-dev mailing list
>> [hidden email]
>> To unsubscribe from this list, visit
>>
https://www.eclipse.org/mailman/listinfo/jdt-dev
>>
>
> _______________________________________________
> jdt-dev mailing list
> [hidden email]
> To unsubscribe from this list, visit
>
https://www.eclipse.org/mailman/listinfo/jdt-dev

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev




_______________________________________________ jdt-dev mailing list [hidden email] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Buffer overflow

Daniel Megert
I'm not sure whether I was clear enough. Stopping auto-closing won't reduce the e-mail notifications. The stale bug notifications happened for years even when auto-closing was not enabled.

Dani



From:        "Andrey Loskutov" <[hidden email]>
To:        [hidden email]
Date:        14.05.2020 16:49
Subject:        [EXTERNAL] Re: [jdt-dev] Buffer overflow
Sent by:        [hidden email]




I vote to get rid of auto-closing.
If auto-closing remains, then at least add [stale] to mail subject

Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov
 
 
Gesendet: Donnerstag, 14. Mai 2020 um 16:34 Uhr
Von:
"Daniel Megert" <[hidden email]>
An:
"Eclipse JDT general developers list." <[hidden email]>
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 <[hidden email]>
To:        
[hidden email]
Date:        
14.05.2020 15:48
Subject:        
[EXTERNAL] Re: [jdt-dev] Buffer overflow
Sent by:        
[hidden email]



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 <[hidden email]>
>> To: "Eclipse JDT general developers list." <[hidden email]>
>> Date: 14.05.2020 14:19
>> Subject: [EXTERNAL] [jdt-dev] Buffer overflow
>> Sent by: [hidden email]
>> --------------------------------------------------------------------------------
>>
>>
>>
>> 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
>> [hidden email]
>> To unsubscribe from this list, visit
>>
https://www.eclipse.org/mailman/listinfo/jdt-dev
>>
>>
>>
>>
>>
>> _______________________________________________
>> jdt-dev mailing list
>> [hidden email]
>> To unsubscribe from this list, visit
>>
https://www.eclipse.org/mailman/listinfo/jdt-dev
>>
>
> _______________________________________________
> jdt-dev mailing list
> [hidden email]
> To unsubscribe from this list, visit
>
https://www.eclipse.org/mailman/listinfo/jdt-dev

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev




_______________________________________________ jdt-dev mailing list [hidden email] To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev




_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Buffer overflow

Till Brychcy
In reply to this post by Andrey Loskutov
+1 to get rid of auto-closing

On one hand, we encourage users to participate in eclipse and a first step is to file bugs.

But at least I as a bug-author absolutely HATE  it if bugs that I invested time to write are auto-closed.

This is everything but encouraging.

I’ve also seen others on twitter complain about it.

(if anybody cares, I think this practice should also be ended on Platform)

Notifications on stale bugs don’t matter, because they can be deleted without worrying if the bugs don’t get closed.


_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Buffer overflow

Mickael Istria-5


On Thu, May 14, 2020 at 5:15 PM Till Brychcy <[hidden email]> wrote:
On one hand, we encourage users to participate in eclipse and a first step is to file bugs.
But at least I as a bug-author absolutely HATE  it if bugs that I invested time to write are auto-closed.
This is everything but encouraging.
I’ve also seen others on twitter complain about it.
(if anybody cares, I think this practice should also be ended on Platform)
Notifications on stale bugs don’t matter, because they can be deleted without worrying if the bugs don’t get closed.

I agree with that.
As a committer, I don't think auto-closing helps at making me more productive, and I know it can be irritating and even disrespectful for the bug author. So IMO, it has no clear value (at least to me) but it has a negative impact on the community. For those reasons, I think that auto-close, or even auto-marking bugs as "stale" could totally be terminated.
I don't get the idea of marking a bug as stale in the title or comments. What would that change anyway? Would the bug receive more or less attention? If the former (get attention), isn't a plain comment enough?
I have the impression that the only benefit is to show positive trends of "we closed many bugs". I think such metrics are not to be trusted anyway if some bugs are closed while not being verified as fixed. Stopping the auto-close would for sure show some smaller numbers, but at least they'd be *real* numbers which can be used for proper estimations.


_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Buffer overflow

Daniel Megert
> I don't get the idea of marking a bug as stale in the title or comments. What would that change anyway? Would the bug receive more or less attention? If the former (get attention), isn't a plain comment enough?

You need to read the whole thread ;-). Some people cannot filter/trash based on body. Hence the suggestion to add [stale] to the subject.

Dani



From:        Mickael Istria <[hidden email]>
To:        "Eclipse JDT general developers list." <[hidden email]>
Date:        14.05.2020 17:27
Subject:        [EXTERNAL] Re: [jdt-dev] Buffer overflow
Sent by:        [hidden email]






On Thu, May 14, 2020 at 5:15 PM Till Brychcy <register.eclipse@...> wrote:

On one hand, we encourage users to participate in eclipse and a first step is to file bugs.
But at least I as a bug-author absolutely HATE  it if bugs that I invested time to write are auto-closed.
This is everything but encouraging.
I’ve also seen others on twitter complain about it.
(if anybody cares, I think this practice should also be ended on Platform)
Notifications on stale bugs don’t matter, because they can be deleted without worrying if the bugs don’t get closed.



I agree with that.
As a committer, I don't think auto-closing helps at making me more productive, and I know it can be irritating and even disrespectful for the bug author. So IMO, it has no clear value (at least to me) but it has a negative impact on the community. For those reasons, I think that auto-close, or even auto-marking bugs as "stale" could totally be terminated.
I don't get the idea of marking a bug as stale in the title or comments. What would that change anyway? Would the bug receive more or less attention? If the former (get attention), isn't a plain comment enough?
I have the impression that the only benefit is to show positive trends of "we closed many bugs". I think such metrics are not to be trusted anyway if some bugs are closed while not being verified as fixed. Stopping the auto-close would for sure show some smaller numbers, but at least they'd be *real* numbers which can be used for proper estimations.
_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev




_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Buffer overflow

Mickael Istria-5


On Thu, May 14, 2020 at 5:31 PM Daniel Megert <[hidden email]> wrote:
You need to read the whole thread ;-).

I did and still...
 
Some people cannot filter/trash based on body. Hence the suggestion to add [stale] to the subject.

I think the need for filtering comes from the fact that we artificially and automatically "animate" the bugs that have no activity. If we stop all forms of automated changes on such bugs, then there is no need to filter them any more...
So to me, filtering is a workaround for a problem, whose root cause is that we automatically process bugs. I suggest we get rid of the root cause, unless it has demonstrated some compelling value.

Also, imagine a bug that is [stale] in title, some committers have a filter to ignore them, a contributor just comment with some interesting input, or even a Gerrit patch, bug doesn't rename the bug (why would they?), then the filters still apply and the valuable contribution and further discussion get filtered out and ignored; which is even worse than auto-closing IMO.

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Buffer overflow

Manoj Palat-2
@Stephan, all: As a JDT lead, +1 for to stop auto CLOSING.

Regards,
Manoj

-----[hidden email] wrote: -----
To: [hidden email]
From: Stephan Herrmann
Sent by: [hidden email]
Date: 05/14/2020 07:18PM
Subject: [EXTERNAL] Re: [jdt-dev] Buffer overflow

Now that Eclipse PMC asks for a vote among JDT leads / committers, I propose the
following compromise:

- stop auto CLOSING


-----[hidden email] wrote: -----
To: "Eclipse JDT general developers list." <[hidden email]>
From: Mickael Istria
Sent by: [hidden email]
Date: 05/14/2020 09:09PM
Subject: [EXTERNAL] Re: [jdt-dev] Buffer overflow



On Thu, May 14, 2020 at 5:31 PM Daniel Megert <[hidden email]> wrote:
You need to read the whole thread ;-).

I did and still...
 Some people cannot filter/trash based on body. Hence the suggestion to add [stale] to the subject.

I think the need for filtering comes from the fact that we artificially and automatically "animate" the bugs that have no activity. If we stop all forms of automated changes on such bugs, then there is no need to filter them any more...
So to me, filtering is a workaround for a problem, whose root cause is that we automatically process bugs. I suggest we get rid of the root cause, unless it has demonstrated some compelling value.

Also, imagine a bug that is [stale] in title, some committers have a filter to ignore them, a contributor just comment with some interesting input, or even a Gerrit patch, bug doesn't rename the bug (why would they?), then the filters still apply and the valuable contribution and further discussion get filtered out and ignored; which is even worse than auto-closing IMO.

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Buffer overflow

Roland Grunberg
In reply to this post by Daniel Megert
On Thu, 2020-05-14 at 16:34 +0200, Daniel Megert wrote:
> JDT committers, please express your opinion on this if you have one,

+1 for no more auto-closing.

I'm not sure of the exact conditions under which a bug is auto-closed,
but I have seen bugs with ~10yrs of no activity get taken by new
contributors and fixed. I really don't think that would have happened
if they had been closed as WONTFIX.

I agree with Mickael as well that maybe touching old bugs is the real
issue.

Cheers,
--
Roland Grunberg

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
12