User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
I think the broader generalized message here is "please let's
make decisions as group".
Merging repos now feels like a whim. I'd personally like to see
a documented strategy of which repos we will have when we reach
the end point. Why only these? Why not more, like what we have
now? Why not have just one?
I'm not arguing for nor against merging. I would just really
appreciate understanding the strategy and seeing a plan so that we
committers could comment on a cohesive them. This affects us all
and we should all be included...
On 31.03.2022 09:37, S A wrote:
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.
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.