Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-dev] Intended Bug-Tracker for Platform-projects hosted on GitHub


On Thu, Mar 31, 2022 at 9:25 AM Ed Merks <ed.merks@xxxxxxxxx> wrote:

Note that we do have the following repo already, so I'm doubtful we need yet another one in order to have a "central" one.

https://github.com/eclipse-platform/.github/issues

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...


Now, that's the first very constructive message in this thread! Thanks for that, Ed!
 

I Googled and saw this:

https://docs.github.com/en/issues/tracking-your-work-with-issues/pinning-an-issue-to-your-repository

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 make use of pinned issues for Github migration already and it comes quite handy https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues .

We should be able to do something helpful on this "home page", right?

https://github.com/eclipse-platform

These folks have some "banner text on their "home page":

https://github.com/adoptium/

They also have "pinned" repos.   But I've not figured out where that comes from...


Looks good. I'll look into pinning repos too.
 

In any case, we could do something more helpful too I think... 

For example, this also has a banner:

https://github.com/cucumber

It links to this:

https://cucumber.io/tools/cucumber-open/

Where you can follow to this:

https://cucumber.io/tools/cucumber-open/support/

Which leads here:

https://cucumber.io/tools/cucumber-open/support/#issues

And here they have helpful advice to the user. 

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... 

There is definitely room for improvement . IMHO Lars and your combined efforts will move things in the right direction.
 

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?
Would be that an alternative?
 
Kind regards,
Andrey Loskutov

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

https://www.eclipse.org/user/aloskutov
 
 
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).
 
Kind regards,
Andrey Loskutov

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

https://www.eclipse.org/user/aloskutov
 
 
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

  1. eclipse.platform              for Platform
  2. eclipse.jdt                          for Jdt
  3. equinox.framework       for equinox
  4. eclipse.pde.ui                   for pde

 

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.

 

On Wed, Mar 30, 2022 at 5:25 PM S A <simeon.danailov.andreev@xxxxxxxxx> wrote:

+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.

 

Best regards,

Simeon

 

On Tue, 29 Mar 2022 at 20:22, Dirk Steinkamp <Dirk.Steinkamp@xxxxxx> wrote:

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.

 

Thanks,

Hannes

 

 

    

_______________________________________________
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

 

_______________________________________________
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

_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev



--

Aleksandar Kurtakov

Red Hat Eclipse Team

_______________________________________________ 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
 
 
--
Regards,
Nitin Dahyabhai
Eclipse WTP PMC
_______________________________________________ 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
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev


--
Aleksandar Kurtakov
Red Hat Eclipse Team

Back to the top