Please first finish the GitHub moves and let that settle for a month (or better, a fe months). There are enough new problems and disruptive changes already.
The thing is in order to fix very old problems and some new we have to change things or we are going to add even more bandaid and make it even harder to fix later (as it has happened so many times).
I think this is a good opportunity to simplify our repo structure. AFAIK the existing structure was built based on the IBM team structure. I should start merging repos so make this less confusing for users and to simplify our workflow.
Probably we should start with the small, not so active ones. We also discussed that yesterday in our PMC meeting and my impression was that the present PMC members were in favor of merging.
I would have hoped that a decision or strategy for how to "make
it easy for users to report problems" would be a no brainer,
rather than devolving immediately into "no one wants to triage
them anyway so let the user learn which of the following 31
repositories might be the best place to report a problem for the
Eclipse SDK product":
That list of course gets bigger when we consider the number of
projects and corresponding repos involved in any one of the EPP
packages and of course to many people if not most people, all
these things are the Eclipse IDE...
So if we're concerned about people opening an issue in the wrong
repo we could pin an issue with a message "when in doubt open an
issue [here](link-to-where) instead".
We should be able to do something helpful on this "home page",
right?
I think that no matter what we decide is best, we will want
something like the above to guide the user so that they find the
information they need to learn what to do with respect to bug
reporting...
Regards,
Ed
On 30.03.2022 18:33, Andrey Loskutov
wrote:
OMG, just geniuos implementation, github tops everything!
I guess the one half of users will give up searching the
bug tracker for Eclipse IDE, and another half will create bugs
in *wrong* bug tracker (according to Murphy's law).
On the other side, less user bug reports will mean less
work for us.
I don't see a reasonable solution for bug tracking with
github.
That is simply not manageable, neither for us nor for
users.
Isn't Jira offering a free license for open source?
Gesendet: Mittwoch,
30. März 2022 um 18:17 Uhr Von: "Nitin Dahyabhai"
<thatnitind@xxxxxxxxx> An: "Eclipse platform general developers list."
<platform-dev@xxxxxxxxxxx> Betreff: Re: [platform-dev] Intended Bug-Tracker
for Platform-projects hosted on GitHub
There's an additional hurdle in that you can't move
an Issue between repos unless you're someone that has
write access on *both*. Even for projects as closely
connected as Andrey listed (assuming pdt is a typo),
that's a short list.
On Wed, Mar 30, 2022 at 12:06
PM Andrey Loskutov <loskutov@xxxxxx>
wrote:
Sravan, this picture is not that simple.
Once JDT fully migrates to github, it will
have 3 (!) bug tracker, not one, because
github has bug tracker *per repository*. Same
for all other projects.
Platform already has 15 (!!!) bug trackers,
platform UI not yet migrated.
Even if we will disable bug trackers for
all repositories except one repo per the
organization, we will loose automatic bug / PR
tracking links and still have four (!) bug
trackers (pdt, jdt, equinox, platform).
Gesendet: Mittwoch,
30. März 2022 um 17:49 Uhr Von: "Sravan K Lakkimsetti" <sravankumarl@xxxxxxxxxx> An: "Eclipse platform general
developers list." <platform-dev@xxxxxxxxxxx> Betreff: Re: [platform-dev]
Intended Bug-Tracker for
Platform-projects hosted on GitHub
I would
not prefer another top level
repository for just issues. We
do have
I believe
this should be sufficient. Lets
see how this goes.
Thanks
Sravan
From:
platform-dev <platform-dev-bounces@xxxxxxxxxxx>
On Behalf Of Aleksandar
Kurtakov Sent: 30 March 2022
21:07 To: Eclipse platform
general developers list. <platform-dev@xxxxxxxxxxx> Subject: [EXTERNAL] Re:
[platform-dev] Intended
Bug-Tracker for
Platform-projects hosted on
GitHub
I always have
one question: Is anyone
subscribing to triage things and
keeping it in a manageable
state?
If no one
plans to do that it's better if
users learn about project
structure, question how we
organize things and etc. so we
start improving/reorganizing.
+1 for a
top level "empty" repo, that
users are pointed to for
reporting bugs. Listing 20+
repos and letting the user
find the right one, just to
create a bug report, won't
be great.
Thanks, Hannes for
clarifying the
possiblity to
transfer an issue.
That's good to know.
Anyhow: I want to
stress the user's
perspective -- it's
way to easy to get
confused.
I just wanted to
file a bug report
and thought I might
give github issues a
try. But where to
go? I tried the
github search with
various combinations
of "eclipse ui",
"eclipse platform",
etc. -- which all
turned up search
results of other
people's projects,
but never a relevant
eclipse project at
the top. So I ended
up posting it to
bugzilla ...
Sorry, but from a
"simple user's
perspective" this is
a great way to cut
away the feedback
loop to the users,
make users give up,
and turn away from
eclipse ...
There needs to be
some guidance for
the casual reporter
of issues at an
entry point that's
easy to find.
PLUS: I like
bugzilla's list of
probably related
bugs -- so I don't
file a duplicate too
easily.
(and maybe part of
the confusion is
that Eclipse is
often used as
synonym for "Eclipse
IDE", not even
realizing that
"Eclipse IDE" should
be the full name of
the product, but
understanding IDE
simply as a
descriptive term and
taking "Eclipse" as
the product name ...
I know it's like
saying "I use
Microsoft for
writing documents",
but all developers I
usually meet and
talk to speak [and
probably think]
simply of "Eclipse"
when they actually
mean "Eclipse
IDE"...)
Dirk
Am
26.03.2022 um
12:22 schrieb
Hannes Wellmann:
It is
possible to
move issues
between
repositories
on GitHub, see
[1], and it is
also possible
to link issues
in other
repositories
by mentioning
them.
Although it
is simpler for
those that
handle bugs to
assign them to
the correct
repository
directly, I
agree that it
can be
difficult to
find out which
one the
correct repo
is, especially
if one is not
deeply
involved into
Eclipse
development.
To help
those people
maybe it would
be useful to
create a repo
at https://github.com/eclipse/ide
(or similar)
that is
de-facto empty
and where
users can
report bugs
for which they
don't know the
responsible
project/repository
for. The bugs
could then be
transferred to
the correct
repo by
committers
that can
identify the
responsible
repository.
But I assume
there is
definitely the
risk that
managing such
a common
bug-tracker
becomes quite
a great task
that consumes
too many
resources. So
bug reports
should be
encouraged to
only use it as
last resort
and there
should be good
documentation/guidelines for reporters to find the appropriated repo by
them self.
Gesendet: Samstag,
26. März 2022
um 11:07 Uhr Von: "Dirk
Steinkamp" <Dirk.Steinkamp@xxxxxx> An: "Eclipse
platform
general
developers
list." <platform-dev@xxxxxxxxxxx> Betreff: Re:
[platform-dev]
Intended
Bug-Tracker
for
Platform-projects
hosted on
GitHub
Speaking from someone who only
recently made
a first
contribution
to Eclipse,
but has been
using Eclipse
for years and
occasionally
reported
issues, I have
to say that
already the
many existing
project are
simply
confusing to
pick from when
a user simply
wants to
report
something. The
bugzilla seems
to have the
option to
later
(re)assign it
to the correct
subproject.
This doesn't get better with
all the
different
eclipse-subprojects
hosting their
own
github-projects
with separate
issue
trackers, as
you can't move
issues from
one
github-project
to the other,
right? It's
also lacking
an integrated
overview of
issues that
might be
related, but
affect
different
subprojects.
So I'd favour something that
can provide
overarching,
integrating
capabilities -
be it
bugzilla, or
something
else.
Dirk
Am
26.03.2022 um
09:42 schrieb
Hannes
Wellmann:
At the
moment it is
not clear to
me (maybe I
have missed
something) if
I should still
use Bugzilla
or instead the
Github Issues
of for
Eclipse-projects
that were
moved to
Github?
IIRC to was
not the plan
to shutdown
the associated
Bugzilla now,
but does this
also mean that
bugs should
still be
reported there
or should GH
issues be used
for that as
soon as a
project was
moved?
At the
moment I have
the impression
both is used,
which is IMHO
not ideal but
probably hard
to avoid in a
transition
phase.