Discussion:
Bug#1079850: Should openrocket be removed from unstable?
Add Reply
Helmut Grohne
2024-08-28 06:30:02 UTC
Reply
Permalink
Source: openrocket
Severity: serious
Justification: grab attention of maintainer
User: ***@debian.org
Usertags: sidremove

Dear maintainer,

I suggest removing openrocket from Debian for the following reasons:
* It accumulated one RC-bug:
+ #984609: openrocket: uninstallable: depends on no longer available openjdk-8-jre
Last modified: 3 years

* It is not part of bookworm or trixie and is not a key package.

This bug serves as a pre-removal warning. After one month, the bug will be
reassigned to ftp.debian.org to actually request removal of the package.

In case the package should be kept in unstable, please evaluate each of the
RC-bugs listed above.
* If the bug is meant to prevent the package from entering testing or a stable
release, but this package should stay part of unstable, please add a
usertag:

user ***@debian.org
usertags NNN + sidremove-ignore

* If the bug no longer applies, please close it. If it is closed, check
whether the fixed version is correct and adjust if necessary.

* Is the bug really release-critical? If not, please downgrade.

* If the bug still applies, please send a status update at least once a year.

Once all of the mentioned RC bugs have been acted upon in one way or another,
please close this bug.

In case the package should be removed from unstable, you may reassign this
bug report:

Control: severity -1 normal
Control: retitle -1 RM: openrocket -- RoM; rc-buggy
Control: reassign -1 ftp.debian.org

Alternatively, you may wait a month and have it reassigned.

In case you disagree with the above, please downgrade this bug below RC
severity. Doing so will also prevent automatic reassignment.

Kind regards

A tool for automatically removing packages from unstable

This bug report has been automatically filed with little human intervention.
If the filing is unclear or in error, don't hesitate to contact
Helmut Grohne <***@subdivi.de> for assistance.
Bdale Garbee
2024-09-04 18:20:01 UTC
Reply
Permalink
Post by Helmut Grohne
Source: openrocket
Severity: serious
Justification: grab attention of maintainer
Usertags: sidremove
Dear maintainer,
I suggest removing openrocket from Debian
I agree.

Upstream now offers for download a 'fat' jar file that can be run on
Debian systems with modern Java, though not in full DFSG compliance.

In parallel, I've done work with upstream to resolve some of the
dependency issues that prevented packaing openrocket from current
upstream source for inclusion in Debian main. There's still more work
to do to package class libraries in Debian before openrocket can move
to main.

So, for now, I'm fine if we remove openrocket entirely from Debian. I
don't think anyone really still wants to run that old version. Then
I'll file an ITP in WNPP so anyone thinking about it will know I'm still
trying to get openrocket back in to main... someday. When it's ready
for main, a full review of the sources through NEW processing will make
good sense.

Regards,

Bdale
Helmut Grohne
2024-09-05 06:30:02 UTC
Reply
Permalink
Control: severity -1 normal
Control: retitle -1 RM: openrocket -- RoM; rc-buggy
Control: reassign -1 ftp.debian.org
Control: affects -1 + src:openrocket

Hi Bdale,
Post by Bdale Garbee
Post by Helmut Grohne
I suggest removing openrocket from Debian
I agree.
Upstream now offers for download a 'fat' jar file that can be run on
Debian systems with modern Java, though not in full DFSG compliance.
In parallel, I've done work with upstream to resolve some of the
dependency issues that prevented packaing openrocket from current
upstream source for inclusion in Debian main. There's still more work
to do to package class libraries in Debian before openrocket can move
to main.
So, for now, I'm fine if we remove openrocket entirely from Debian. I
don't think anyone really still wants to run that old version. Then
I'll file an ITP in WNPP so anyone thinking about it will know I'm still
trying to get openrocket back in to main... someday. When it's ready
for main, a full review of the sources through NEW processing will make
good sense.
Thank you for the reply. I've turned this bug into a removal bug
accordingly.

I also note that openrocket currently has only two bugs in the BTS. It's
the RC bug that triggered the removal suggestion and the removal
suggestion bug. As a result, there is no need to reopen any bugs in case
of reintroducing openrocket at a later time.

Keep in mind that the motivation behind these removals is reducing the
workload on QA teams. Thus I concur with temporarily removing openrocket
until it passes NEW again is a sensible trade-off.

Helmut

Loading...