[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-dev] Vote to stop bug auto-closing in all Eclipse platform projects
|
Auto-closing also make the project seem dead as it clearly indicates that there is no resources or people just don't care to handle valid reports.
I'd better have a growing number of issues showing that we need more resources than a constant number of issues that gives the false impression there is no problem.
In the end, its just a matter of what we want to deliver 'more' or 'better' software. As mentioned before, it might be good to have one of the releases per year that is dedicated to bug fixing (and maybe bug triage) where we simply do not accept new features. For example the 20xx-12 release as its is a bit shorter and we can have a fresh start for the new year.
I completely agree with you. We only make use of SWT in our projects and
pay a developer to fix bugs in SWT. Without looking at my reported
issues, I would say nearly all of them were bugs.
This does not mean that SWT is very buggy, but even a good project can
(and should) get better.
--
Best regards,
Thomas Singer
=============
syntevo GmbH
www.syntevo.com
On 2022-02-18 07:13, Christoph Läubrich wrote:
> Auto-closing is more likely to stimulate people in
> trying to contribute [...] Sometimes they reopen
> with frustration and this can trigger a new conversation with some
> committers to help them in contributing more.
I'm not sure if you suggest here to
a) frustrate users more 'stimulate' them
-or-
b) user should rant more to get more attention and 'stimulate' contributors
;-)
> It just make the
> project seem dead.
Auto-closing also make the project seem dead as it clearly indicates
that there is no resources or people just don't care to handle valid
reports.
I'd better have a growing number of issues showing that we need more
resources than a constant number of issues that gives the false
impression there is no problem.
In the end, its just a matter of what we want to deliver 'more' or
'better' software. As mentioned before, it might be good to have one of
the releases per year that is dedicated to bug fixing (and maybe bug
triage) where we simply do not accept new features. For example the
20xx-12 release as its is a bit shorter and we can have a fresh start
for the new year.
Am 17.02.22 um 21:12 schrieb Mickael Istria:
> We all know that the root cause of this discussion is the 10+ years of
under-resourcing for Eclipse platform.
Eclipse Platform is not under-resourced. It's OK-resourced, and just
like any project would benefit from more resources, but let's move the
resources discussion away and focus on the community aspects of
auto-closing bugs.
> Do we expect big players to come back and sponsor teams of
developers again as it was in 00ths? I doubt so. Perhaps, small
companies and individuals from the community are the only hope.
I don't get how it's related to the discussion about auto-closing bugs
or not. And I also don't get how Alex's answer triggered that question.
And if yes, how auto-close could help to recruit new resources for
triaging (not even dreaming about bug fixing) from the community?
Auto-closing is more likely to stimulate people in trying to
contribute than just keeping the bug silent. At least, people can
decide to reopen with more details, or to add other information (not
useful anymore, was fixed), and that's a form of contribution already.
Sometimes they reopen with frustration and this can trigger a new
conversation with some committers to help them in contributing more.
On the other hand, keeping the bugs open but silent brings no
interaction and thus no new opportunity to recruit. It just make the
project seem dead.
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
