[Bug 577151] Shutdown this bugzilla instance.

added Bugzilla Bugzilla-Component legacy labels

The only reason why we still use Bugzilla is integration with release record interface [1].

Is it planned to support GitHub and GitLab issues there?

[1] https://projects.eclipse.org/projects/technology.passage/releases/2.1.1/bugs

(In reply to Alexander Fedorov from comment #1)

The only reason why we still use Bugzilla is integration with release record
interface [1].

The historical release records for projects that have already moved off of Bugzilla are already "broken" in this regard because the generation of that page is live. So, unfortunately I think they are already of diminished value.

Is it planned to support GitHub and GitLab issues there?

Perhaps simply add the ability to link to a GH / GL milestone URL like https://github.com/eclipse/lsp4j/milestone/19?closed=1 - that is what LSP4J does for its GH "release record" https://github.com/eclipse/lsp4j/releases/tag/v0.12.0

Wayne and I discussed this very issue recently - but I can't remember the forum it was discussed in, so no link. I have cc'ed @Wayne in case he has a link.

Is it planned to support GitHub and GitLab issues there?

No. In fact, my current thinking is to deprecate and remove the feature entirely. See Bug 576364.

The short version is that even the implementation based on Bugzilla has some fundamental flaws that would just be passed forward if we extended the support to GitLab/GitHub. IMHO, it's more useful your community to just include a change log directly in your repository.

(In reply to Wayne Beaton from comment #3)

Is it planned to support GitHub and GitLab issues there?

No. In fact, my current thinking is to deprecate and remove the feature entirely. See Bug 576364.

Well, in this case we don't have more reasons to continue using Bugzilla.
Thank you for sharing your thinking.

In principle moving on is good, but sadly too many EF moves are not for the better. cf. the still not replaced NNTP

Bugzilla is a very important service providing the accessible design/bug-fix decisions for most Eclipse projects. Unfortunately some such discussion has moved to Gerrit, making the discussions transient and invisible to the normal search and seemingly also invisible now that Gerrit is dying. (I am happy to lose Gerrit; it never did anything for me, but Bugzilla is almost the most important EF service to me, perhaps second only to GIT.)

To me it is essential that

a single form provides searches across all important Eclipse projects finding all historical and future bugs/issues seemlessly with minimal loss of information wrt author/date/history
migration of a bug between projects remains possible
the existing bug numbers are respected by the new tooling so that comments such as See Bug 123456 do not become hideously opaque
that all old references point forwards and vice-versa

The latter is a notable failure of the M2E migration, where all old bugs were terminated by the comment:

Moved to https://github.com/eclipse-m2e/m2e-core/issues/

necessitating that someone looking at e.g. Bug 410228 follows the link to the unhelpfully paged index, where after searching all 4 pages no hit occurs for either "410228" or "test scope dependencies in classpath at runtime of main java". For Bugzilla, Firefox search is able to look at many hundreds of bug titles in one go.

Surely every Bugzilla thread should be migrated and should be indexed directly from the original Bugzilla thread? Just because a Bug is INVALID doesn't make it uninteresting; keeping the INVALID helps other users avoid duplicates and may help them understand some important design limitation.

By Roger Light

My concern regarding shutting down this bugzilla is around making sure that the Community section is replaced with something else, likewise security bugs.

To me it is essential that
\

a single form provides searches across all important Eclipse projects
finding all historical and future bugs/issues seemlessly with minimal loss
of information wrt author/date/history

There is a lot of relative "noise" on Bugzilla. How pertinent is bug 2 nowadays?

the existing bug numbers are respected by the new tooling so that comments
such as See Bug 123456 do not become hideously opaque

That won't happen -- issues in modern trackers follow the project. So you'll have many Issue #1 -- all related to different projects.

that all old references point forwards and vice-versa

We will maintain a static list of bugzilla bugs with working links. Not sure about attachments, though.

(In reply to Roger Light from comment #6)

My concern regarding shutting down this bugzilla is around making sure that
the Community section is replaced with something else, likewise security
bugs.

The new Community section is already alive, and we're calling it HelpDesk: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues

In the near future we will migrate open issues from EF > Community to HelpDesk.

(In reply to Denis Roy from comment #7)

that all old references point forwards and vice-versa

Not sure about attachments, though.

Since migration of attachments may be too difficult, it would seem essential that each migrated Bugzilla start, or perhaps end, with a distinct identifying link to where the migration came from and a clear message that attachments may be found by visiting the original Bugzilla which much must of course remain available in read-only form in perpetuity.

We will maintain a static list of bugzilla bugs with working links.

Will this list be used to repair the m2e issues so that each already migrated Bugzilla has a distinct link to the superseding issue.?

And will all future Bugzilla migrations have a distinct link?

(In reply to Ed Willink from comment #5)

The latter is a notable failure of the M2E migration, where all old bugs
were terminated by the comment:

Moved to https://github.com/eclipse-m2e/m2e-core/issues/\
necessitating that someone looking at e.g. Bug 410228 follows the link to
the unhelpfully paged index, where after searching all 4 pages no hit occurs
for either "410228" or "test scope dependencies in classpath at runtime of
main java". For Bugzilla, Firefox search is able to look at many hundreds of
bug titles in one go.

Surely every Bugzilla thread should be migrated and should be indexed
directly from the original Bugzilla thread? Just because a Bug is INVALID
doesn't make it uninteresting; keeping the INVALID helps other users avoid
duplicates and may help them understand some important design limitation.

the original Bugzilla which much must
of course remain available in read-only form in perpetuity.

No. There is no way to ever evolve if things must remain in perpetuity.

We can establish reasonable amounts of historical data to be read-only for a reasonable amount of time, after that, it has to be culled, or it creates noise for everyone.

(In reply to Denis Roy from comment #9)

the original Bugzilla which much must
of course remain available in read-only form in perpetuity.

No. There is no way to ever evolve if things must remain in perpetuity.

We can establish reasonable amounts of historical data to be read-only for a
reasonable amount of time, after that, it has to be culled, or it creates
noise for everyone.

This is a very important point, I must confess I haven't realized that yet.

So foundation does not plan to migrate existing bugzilla tickets to some read only instance that will be there forever?

Means, if Platform project wants to keep existing bugzilla tickets forever, we need to make sure we will find some 3rd party service and migrate tickets to that service, without any help from foundation?

Note: bugzilla tickets, at least for Platform project are not just "noise" that "has to be culled", they represent majority of existing Eclipse code base documentation. Lot of code can only be understood by consulting referenced bugzilla tickets. We can't afford this knowledge base to be lost.

If you're actively using bug data that is 20 years old, then one could argue it's not historical. Perhaps that bug data should be migrated over to the new location (GitHub, GitLab).

While we can certainly run a static output of Bugzilla and preserve links in static HTML format, we cannot run the Bugzilla app in read-only mode in perpetuity, as was suggested.

(In reply to Andrey Loskutov from comment #10)

So foundation does not plan to migrate existing bugzilla tickets to some
read only instance that will be there

Yes

forever?

Forever is a long time that no one can commit to. For the foreseeable future? Yes. We still have CVS in read-only mode, which will be shut down for 10 years next year.

(In reply to Andrey Loskutov from comment #10)

Means, if Platform project wants to keep existing bugzilla tickets forever,
we need to make sure we will find some 3rd party service and migrate tickets
to that service, without any help from foundation?

That is not what that means -- but any project is free to back up any of our data for whatever purpose.

This makes me speechless. Providing a read only copy of bugzilla data that is guaranteed to be deleted at some point in time is a "no go" IMO.

One could simply say - who cares about Eclipse on desktop, in 10 years or earlier it will be dead anyway, so let jump straight to the future and use web technologies for everything.

OK, I understand that Eclipse on desktop (and the infrastructure around it) is not priority number one for Eclipse Foundation and is seen more as a burden. I understand that the backup of the data that is important for projects is mostly projects problem, not the foundation.

So in platform we need not only think which 3rd party service we should use as replacement for active development, we also forced now to look for 3rd party service to keep our documentation (bugzilla & wiki).

Code repositories will move to 3rd party. Wikis will move to 3rd party. Bug tracker will move to 3rd party. Mailing lists will move to 3rd party. Forums will move to 3rd party. All legacy services will shut down sooner or later (sooner is for sure better). Every project can use now different 3rd party services, no common infrastructure / information / documentation systems etc.

Only build infrastructure and some rudimentary web pages seem to remain at foundation (or is jenkins also planned to be replaced by some 3rd party service?).

What's the point in the foundation then?
Some marketing?
Happy 20th anniversary Eclipse!

Your post is needlessly unreasonable and bordeline rude. I will not engage further with you unless it's constructive.

By Nathan Ridge

LLVM is another major open-source project which is currently in the process of transitioning away from Bugzilla. It may be instructive to look at how they're approaching it, as a point of comparison:

https://lists.llvm.org/pipermail/llvm-dev/2020-July/143274.html

As I understand, they're migrating all their bugs from Bugzilla to Github (so that the Bugzilla instance can then be shut down without any data loss), and also setting up redirect links (in their case, of the form "llvm.org/PR12345") that allow you to go from an original Bugzilla bug number, to the migrated issue on Github.

(In reply to Nathan Ridge from comment #14)

https://lists.llvm.org/pipermail/llvm-dev/2020-July/143274.html

Excellent. This is precisely the diligent approach that the EF should be investigating.

(In reply to Denis Roy from comment #13)

Your post is needlessly unreasonable and bordeline rude. I will not engage
further with you unless it's constructive.

Inexcusable. Don't shoot the messenger just because a too accurate message is inconvenient and mandates hard work.

Bugzilla is a critical part of the code for longstanding Eclipse projects.

Bugzilla content may not need to last in the broadest sense of perpetuity, but a usable read-only form must last for at least as long as a non-trivial number of users download Eclipse builds from EF-authorized sites.

(In reply to Denis Roy from comment #11)

While we can certainly run a static output of Bugzilla and preserve links in
static HTML format

That seems like a critical requirement for oldest projects. Bugzilla is a huge knowledge base with many many many incoming references. We need to keep all that or we'll just lose a huge part of the history, and knowing history is supposed to be the best way to avoid repeating mistakes.

I think static HTML pages would be as good as a read-only bugzilla; only lost things would be Search capabilities, but after all, there are many good search engines on the Web.
@Andrey: what do you think would be missing in static HTML compared to read-only bugzilla?

@webmaster: Is there a place/sandbox where we can play with an example of static HTML export of Bugzilla? Could this strategy be already applied to archived components that already moved to GitHub?

(In reply to Mickael Istria from comment #16)

I think static HTML pages would be as good as a read-only bugzilla; only
lost things would be Search capabilities, but after all, there are many good
search engines on the Web.
@Andrey: what do you think would be missing in static HTML compared to
read-only bugzilla?

Most important: bug numbers that could be in some way found 1:1 in the new url's. Means, if I see code that says "due bug XYZ we have to do that", I should be able to go to some url with that has XYZ part or redirects me to that XYZ ticket in the new tracker.

In case we will change numbers scheme, links in the bug text referring to the old "XYZ" ticket should point to the new "ABC" ticket that contains the "XYZ" content.

After that: links to other bugs from current bug (both from text and from "see also / depends / blocks), links to gerrits and links to git commits.

Tags/severity and other metadata are probably not that interesting, except bug/comment creation time/date & user info.

Not sure about original emails from people worked on the bug - this is probably personal data that is not allowed to "copy/paste" to the new instance, but this is a bigger story. If we migrate and someone would like to ask the original patch author about reasons for the change or extra questions regarding how to reproduce etc - the original bugzilla user might not be known under the bugzilla email in github/gitlab/whenewer new tracker. So here we will have a massive disruption anyway.

On the other side, at least bugzilla user names should be kept in the new location, because it is crucial to understand who was saying what in the discussion and whom one should to ask if needed about the ticket.

(In reply to Andrey Loskutov from comment #17)

Most important: bug numbers that could be in some way found 1:1 in the new
url's. Means, if I see code that says "due bug XYZ we have to do that", I
should be able to go to some url with that has XYZ part or redirects me to
that XYZ ticket in the new tracker.
In case we will change numbers scheme, links in the bug text referring to
the old "XYZ" ticket should point to the new "ABC" ticket that contains the
"XYZ" content.
After that: links to other bugs from current bug (both from text and from
"see also / depends / blocks), links to gerrits and links to git commits.
Tags/severity and other metadata are probably not that interesting, except
bug/comment creation time/date & user info.

I assume all that can be covered in the scope of what Denis described as "While we can certainly run a static output of Bugzilla and preserve links in static HTML format". Or do I over-interpret this?

Not sure about original emails from people worked on the bug - this is
probably personal data that is not allowed to "copy/paste" to the new
instance, but this is a bigger story. If we migrate and someone would like
to ask the original patch author about reasons for the change or extra
questions regarding how to reproduce etc - the original bugzilla user might
not be known under the bugzilla email in github/gitlab/whenewer new tracker.
So here we will have a massive disruption anyway.
On the other side, at least bugzilla user names should be kept in the new
location, because it is crucial to understand who was saying what in the
discussion and whom one should to ask if needed about the ticket.

The best strategy seems to be keeping as much of the data as possible. Whether emails can be kept or not is something we can trust EF will evaluate as part of this "static output" export.

For the projects that have migrated to GH already (E.g. Tycho) the Bugzilla entries have been archived so it is possible to track down the historical bug information.

However some of the info is lost because the Product goes from Tycho -> z_Archived and the Component is set to Tycho (losing the existing component) and all the version information is also lost. See last entry in history on https://bugs.eclipse.org/bugs/show_activity.cgi?id=548726 for an example.

Are there alternatives so that this information can be preserved?


Bugzilla Link	577151
Status	NEW
Importance	P3 normal
Reported	Nov 09, 2021 11:13 EDT
Modified	Dec 22, 2021 11:10 EDT
Depends on	577551
Blocks	577150
See also	577551

[Bug 577151] Shutdown this bugzilla instance.

Description

Designs

Child items ...

Activity

[Bug 577151] Shutdown this bugzilla instance.

Description

Blocks

Activity