Re: [platform-dev] Intended Bug-Tracker for Platform-projects hosted on GitHub

2022-03-30 Thread Nitin Dahyabhai
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 wrote: >

Re: [platform-dev] Intended Bug-Tracker for Platform-projects hosted on GitHub

2022-03-30 Thread Aleksandar Kurtakov
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

Re: [platform-dev] Intended Bug-Tracker for Platform-projects hosted on GitHub

2022-03-30 Thread Sravan K Lakkimsetti
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.

Re: [platform-dev] Intended Bug-Tracker for Platform-projects hosted on GitHub

2022-03-30 Thread Andrey Loskutov
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

Re: [platform-dev] Intended Bug-Tracker for Platform-projects hosted on GitHub

2022-03-30 Thread Aleksandar Kurtakov
On Wed, Mar 30, 2022 at 7:33 PM Mickael Istria wrote: > > > On Wed, Mar 30, 2022 at 6:00 PM Andrey Loskutov wrote: > >> Beside this, users don't want to "learn about project structure, question >> how we organize things and etc." just to submit a bug. >> However, right now we move from one

Re: [platform-dev] Intended Bug-Tracker for Platform-projects hosted on GitHub

2022-03-30 Thread S A
+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 wrote: > Thanks, Hannes for clarifying the

Re: [platform-dev] Intended Bug-Tracker for Platform-projects hosted on GitHub

2022-03-30 Thread Mickael Istria
On Wed, Mar 30, 2022 at 6:00 PM Andrey Loskutov wrote: > Beside this, users don't want to "learn about project structure, question > how we organize things and etc." just to submit a bug. > However, right now we move from one bugzilla instance to a not organized > / not managed list of

[platform-dev] Migration plan of eclipse.platform.ui to GitHub: April 11th

2022-03-30 Thread Mickael Istria
Hi all, The eclipse.platform.ui is the only Eclipse Platform project repository left to migrate to GitHub; not so surprisingly it's also the current most active one and the most crowded one regarding Gerrit queue. To ensure relatively low disturbance for ongoing work and to not add risk to next

Re: [platform-dev] Intended Bug-Tracker for Platform-projects hosted on GitHub

2022-03-30 Thread Andrey Loskutov
Alex,   all committers already subscribed to repo changes are automatically subscribed to any repo we create.   Beside this, users don't want to "learn about project structure, question how we organize things and etc." just to submit a bug.   However, right now we move from one bugzilla

Re: [platform-dev] Intended Bug-Tracker for Platform-projects hosted on GitHub

2022-03-30 Thread Andrey Loskutov
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

Re: [platform-dev] Intended Bug-Tracker for Platform-projects hosted on GitHub

2022-03-30 Thread Christoph Läubrich
> Once JDT fully migrates to github, it will have 3 (!) bug tracker I always recommended to merge repositories that actually belong together... So we either have here again an organization readme that clearly explains why things are separated or simply merge them if we can't consistently tell