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

> 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 why. Tycho has merged its tycho/tycho extras a while back and it really simplifies things, if one likes he still can build the things independently anyways...

> Even if we will disable bug trackers for all repositories except one
> repo per the organization, we will loose automatic bug / PR tracking

You can link/track issues across any repository [2]

- Issue in the same repository	#ISSUE-NUMBER (e.g. #10)
- Issue in a different repository OWNER/REPOSITORY#ISSUE-NUMBER (e.g. octo-org/octo-repo#100)
- multiple issues  (e.g. #10, #123, octo-org/octo-repo#100)

> and still have four (!) bug trackers (pdt, jdt, equinox, platform).

Just as an example cucumber [3] has 115 repositories (not all has trackers) and a very active community and they simply pinned the most commonly used ones and still people find where to report bugs ... You can even create projects that span multiple projects [4] if you like to have a more consistent overview about multiple "trackers" and get a more high level for users (or people like to triage/manage things).

[1] https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/customizing-your-organizations-profile [2] https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword
[3] https://github.com/cucumber/
[4] https://github.com/orgs/cucumber/projects
    https://github.com/orgs/cucumber/projects/8

Am 30.03.22 um 18:06 schrieb 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 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
<https://github.com/eclipse-platform/eclipse.platform>* for Platform
 2. *eclipse.jdt*
    <https://github.com/eclipse-jdt/eclipse.jdt>                          for
    Jdt
 3. *equinox.framework*
    <https://github.com/eclipse-equinox/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 <mailto: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
    <mailto: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
            <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.

            [1] -
            https://docs.github.com/en/issues/tracking-your-work-with-issues/transferring-an-issue-to-another-repository
            <https://docs.github.com/en/issues/tracking-your-work-with-issues/transferring-an-issue-to-another-repository>

            *Gesendet:* Samstag, 26. März 2022 um 11:07 Uhr
            *Von:* "Dirk Steinkamp" <Dirk.Steinkamp@xxxxxx>
            <mailto:Dirk.Steinkamp@xxxxxx>
            *An:* "Eclipse platform general developers list."
            <platform-dev@xxxxxxxxxxx> <mailto: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  <mailto:platform-dev@xxxxxxxxxxx>

                To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/platform-dev  <https://www.eclipse.org/mailman/listinfo/platform-dev>

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

            _______________________________________________

            platform-dev mailing list

            platform-dev@xxxxxxxxxxx  <mailto:platform-dev@xxxxxxxxxxx>

            To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/platform-dev  <https://www.eclipse.org/mailman/listinfo/platform-dev>

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

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


Back to the top