Bug 243271 - [feature suggestion] Messages about broken ports maintained by the user should be added to "Issues that need attention" e-mails
Summary: [feature suggestion] Messages about broken ports maintained by the user shoul...
Status: In Progress
Alias: None
Product: Services
Classification: Unclassified
Component: Bug Tracker (show other bugs)
Version: unspecified
Hardware: Any Any
: --- Affects Only Me
Assignee: Bugmeister
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-11 15:30 UTC by Yuri Victorovich
Modified: 2020-04-04 23:06 UTC (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yuri Victorovich freebsd_committer 2020-01-11 15:30:06 UTC
Sorry that I create this issue for the bug tracker, but this is sort-of an integrative issue.

Problem description:
When some port maintained by the user gets broken and gets quickly labeled as 'BROKEN', maintainer of this port gets no notification about this. For example, 6 months ago the port graphics/vv, maintained by me, was broken by a dependency library name change and got labeled BROKEN, and I had no idea before I accidentally noticed its name added to /usr/ports/MOVED when it was deleted after being broken for 6 months.

Proposed solution:
When the system queries for open PRs by the user, and decides to send the e-mail "Problems that need special attention", broken ports maintained by the user should be added to the list of items it queries for and notifies users about.

This way such notifications would just integrate into the existing process, and this would solve the problem of maintainers being informed about broken ports.
Comment 1 Li-Wen Hsu freebsd_committer 2020-02-18 17:26:39 UTC
I have to echo this, and I am very glad to see others have the same thought.

I've contacted portmgr to pause removing ports a little bit and firstly revive the "your port has been marked broken" and "your port is scheduled to be removed" notification mails.  It is reported in progress but I do hope there is some temporarily solution like opening a PR in the issue tracker along with marking BROKEN/DEPRECATED.
Comment 2 Antoine Brodin freebsd_committer 2020-02-18 17:30:47 UTC
Portmgr does not manage the "Issues that need attention" e-mails
Comment 3 Li-Wen Hsu freebsd_committer 2020-02-18 17:57:54 UTC
Sorry that I didn't make this clear.  I think the main issue is the maintainers are not being notified when their port being marked BROKEN/DEPRECATED.  One possible path is:

1) A ticket is filed when a port is being marked BROKEN/DEPRECATED
2) The maintainer is automatically added to the ticket
3) A periodic routine checks the open PRs and send notification to the assignee

For 1), it needs help from portmgr because currently the only way a port can be marked BROKEN/DEPRECATED without maintainer approval is from portmgr.

For 2), it is already implemented by bugmeister.

For 3), the "Problems that need special attention" can include the port maintainer.  This would be a bit tricky to implement but the maintainer should already has been notified in 2).

There are two exceptions of 1), one is the port maintained by ports@, so we still need the "your port has been marked broken" and "your port is scheduled to be removed" notifications send to the maintainers periodically.  The other is someone breaks the rule of respecting maintainer, this chance is low and the notification mail will also catch this.

Another reason to revive the two notification mails is then we don't really need to implement 3), and we  don't need 1) as it is just a temporarily solution.  Reviving the notification mails looks a better solution.  We still need to be extra careful when removing ports before we have this mechanism being fixed.

That's why I forward to portmgr and hope them can think highly of this. Thanks.
Comment 4 Kurt Jaeger freebsd_committer 2020-02-18 18:04:42 UTC
(In reply to Antoine Brodin from comment #2)
Who sends "issues that needs attention" emails, then, if it's not portmgr ?
Comment 5 Antoine Brodin freebsd_committer 2020-02-18 18:10:01 UTC
(In reply to Kurt Jaeger from comment #4)
It's something in bugzilla
Comment 6 Chris Hutchinson 2020-02-18 18:18:58 UTC
I'd simply like to add a +1 to this concept. I can't
speak for all Maintainers. But I'm *buried* in email.
As I'm also subscribed to other FreeBSD lists than
ports@. As a result I can/might miss something of
this nature. But filtering against a title such as
proposed would go a long way toward *reading* something
as important as this.

Thanks for the proposal!

--Chris
Comment 7 Li-Wen Hsu freebsd_committer 2020-02-18 18:34:17 UTC
Sigh. I just wanted to point out that if there is no ticket filed, there will not be "Issues that need attention" and then it will not work.

graphics/vv had been marked BROKEN and removed without any fix because these two commits didn't trigger any notification to the maintainer:

http://svnweb.freebsd.org/changeset/ports/519652
http://svnweb.freebsd.org/changeset/ports/522617

The only possibility is the maintainer is a committer or the maintainer subscribes the svn-ports-* mailing list and read all the mails carefully, but it is very easy to lost due to large amount of the commit mails.
Comment 8 Adam Weinberger freebsd_committer 2020-02-18 18:38:02 UTC
I'd be in favor of an automated script that looks for new BROKEN/DEPRECATED and sends an email to the maintainer. Filing a bug report for every port marked BROKEN or DEPRECATED is not feasible.
Comment 9 Li-Wen Hsu freebsd_committer 2020-02-18 18:47:18 UTC
(In reply to Adam Weinberger from comment #8)
Yes, I've been saying that we used to have that mechanism and we need to revive it in comment 1 and 3.  I just said that could be a temporarily workaround before we have that nice script running.  I also said that (privately) filing ticket is not necessary and we can simply pause removing the ports for a little while, just before we can notify the maintainers.

We will lost ports and maintainers if we silently remove their ports.
Comment 10 Michael Gmelin freebsd_committer 2020-02-18 19:26:48 UTC
(In reply to Li-Wen Hsu from comment #9)

(In reply to Li-Wen Hsu from comment #9)

For the ports I maintain I would like to have a PR opened in bugzilla
like you suggested; assigning it to the maintainer and escalating
it should then work automatically through existing mechanisms.

BROKEN PRs could be searched for easily. They could also be referred to in
the commit message when a broken port is fixed or when it is removed.

I'm not sure if this will work for everyone and if it isn't too heavy/
would lead to bugzilla spam & create more noise and work for everyone.

Maybe some notification à la portscout might be less intrusive.
Comment 11 Adam Weinberger freebsd_committer 2020-02-18 19:29:45 UTC
(In reply to Michael Gmelin from comment #10)

Filing a PR for every BROKEN/DEPRECATED is not feasible.
Comment 12 Michael Gmelin freebsd_committer 2020-02-18 19:47:02 UTC
(In reply to Adam Weinberger from comment #11)

Too much noise in bugzilla?
Comment 13 Michael Gmelin freebsd_committer 2020-02-18 20:34:28 UTC
(In reply to Michael Gmelin from comment #12)

@Adam: I mean:
(1) Too much work to create them?
(2) Too much noise/overhead?

(1) could be fixed by creating PRs automatically (I don't know
enough about the infrastructure to understand if this
is way too much work), but it's probably more about (2)

What about extending portscout to check if a port was marked
BROKEN and inform the maintainer about it once? In cases where
there is an updated version available upstream there might even
be some synergy.

portscout already checks the entire ports tree and has
a web based interface one can use to check the status of all
ports by maintainer. Once implemented, deploying such a
feature should be trivial, as there won't be new infrastructure
to be commissioned.
Comment 14 Jan Beich freebsd_committer 2020-02-19 11:08:41 UTC
(In reply to Li-Wen Hsu from comment #1)
> I've contacted portmgr to pause removing ports a little bit
> and firstly revive the "your port has been marked broken"
> and "your port is scheduled to be removed" notification mails.

linimon@, do you know why those portsmon periodic notifications were disabled?

Examples:
https://lists.freebsd.org/pipermail/freebsd-ports/2015-May/099080.html
https://lists.freebsd.org/pipermail/freebsd-multimedia/2015-May/016085.html
Comment 15 Rene Ladan freebsd_committer 2020-02-19 21:22:18 UTC
(In reply to Yuri Victorovich from comment #0)

So, this also implies that you did not care to look after graphics/vv for all of those six points, making your point pretty moot.

In reality, a lot of ports that we tend to clean up are already neglected for a long time anyway. I mean, all of the ports that only work with Python 2.7 clearly have an upstream that did not care about their software either, as Python 2.7 was deprecated for years before it finally reached its end of life this year. And there are many more examples, both from upstream and FreeBSD maintainers.

A few have PRs filed against them and I tend to fix those ports, given those PRs contain a usable fix, suggestion or patch. Also, people are always welcome to fix and resurrect removed ports.

From all the suggestions I think the portscout and email options would be the best ones.
Comment 17 Rene Ladan freebsd_committer 2020-02-19 21:53:56 UTC
(In reply to Rene Ladan from comment #15)

"six points" -> "six months" ...

Two more points:
- removing expired ports is not a portmgr job, I just happen to wear both hats.
- most expired ports will be removed before 2020Q2 is branched, independent of the progress on this PR.
Comment 18 Mathieu Arnold freebsd_committer 2020-02-19 22:03:03 UTC
Also, if you want to get a notification when your port gets a commit, like, say, someone fixes something, or marks it broken, or whatever, you only need to register on freshports.org and subscribe to your ports.
Comment 19 Li-Wen Hsu freebsd_committer 2020-02-19 22:08:47 UTC
(In reply to Antoine Brodin from comment #16)
Thanks for pointing this out. I guess there might be some miscommunication in that case.

To be clear. I am not saying portmgr or anybody is doing anything wrong, and in fact these cleanup are important and should be appreciated.  I just want to provide suggest and help to see if we can improve the situation.  I believe the goal of all of us are fixing ports.  The issue here is some of us thought there is no one interested in some ports anymore but in fact they want to fix and just didn't know.  And if we can publish the status (of BROKEN/DEPRECATED), more people will join the efforts.  Just like there is usually public announcement when we removing things under src/.

I was wanting let's try some more ways before deleting things.  I know resurrecting ports is possible, but please note that this is harder than fixing it while it's still in the tree.

More communication is better in the most cases.

Few questions and suggestions:
- How far is it from resurrecting the BROKEN/DEPRECATED warning? How is the current status and how can we help?
- How about having a monthly or weekly public status report to ports@ like "these ports are broken and these ports are to be removed in the next batch" All the previous mechanism are sent to maintainers or dedicated list.  Having these will get more attention and fixes.  Doing this weekly/monthly should be low impact to the mailing list traffic.
- It's more personal question, I can't find any pkg-fallout mail about chinese/cnprint before it was marked BROKEN in http://svnweb.freebsd.org/changeset/ports/516880 , did I miss anything?
Comment 20 Li-Wen Hsu freebsd_committer 2020-02-19 22:12:50 UTC
(In reply to Mathieu Arnold from comment #18)
Yes this is handy and I will do that. To be honesty I didn't know this. I'm not sure if this is documented in the porter's handbook and I probably need to reread it again.

Also, I want to suggest this kind of important message is better to be opt-out but not opt-in.
Comment 21 Yuri Victorovich freebsd_committer 2020-02-19 22:28:52 UTC
(In reply to Rene Ladan from comment #15)

I can't continuously "look after" all ports. Various ports are in various conditions due to a variety of reasons. Some become broken when an underlying Java version changes and build begins to fail, like in the RStudio case. Some are 2.7-only like you mentioned. Some are sensitive to a default compiler version.

This is why the notification mechanism is important. I don't want to get notifications about all commits either, just when ports become broken or derecated.
Comment 22 Chris Hutchinson 2020-02-19 22:50:29 UTC
Would a monthly submission to the ports@ list titled
BROKEN ports to be REMOVED in 30 days
be too much of a burden? I chose the title the way
it is, because the CAPS tend to get ones attention,
and in all, seems like it might alarm some people
enough to read, and hopefully *adopt* a needy port.

Just a thought. :)

--Chris
Comment 23 Mathieu Arnold freebsd_committer 2020-02-20 09:27:10 UTC
(In reply to Yuri Victorovich from comment #21)

You do not have to continously look after all ports, but as a committer, it is expected of you to check your ports once in a while.  When a port has not been building for six months, it is marked BROKEN, and then it gets removed a few months later.
If in all those months you did not have 2 minutes to look at that port to see, for example, if there was a new version available, then you are maintaining too many ports.
Comment 24 Mark Linimon freebsd_committer freebsd_triage 2020-02-20 13:11:14 UTC
(In reply to Jan Beich from comment #14)

They were not "disabled" as much as they were turned off once the python
upgrade on the portsmon jail failed, all that time ago.

Yes, I want to get back to fixing it, but no, not this week.
Comment 25 Chris Hutchinson 2020-02-20 16:03:21 UTC
(In reply to Mathieu Arnold from comment #23)
I spend *hours* near daily reading through the
(FreeBSD) mailing lists I'm subscribed to. In
spite of the efforts by the ports@ team to
correct them. The Titles are often not very
indicative of the problem at hand. As a result,
I cannot always *effectively* filter against
them to guarantee I receive/see every message
I *should*. My suggestion, with regards to
the title would alleviate that problem. As
well as bring attention to ports of value that
others may want to adopt.
That was the primary intent of my suggestion. :)

--Chris
Comment 26 Rene Ladan freebsd_committer 2020-02-20 18:57:02 UTC
(In reply to Chris Hutchinson from comment #22)
Well, hmm, the idea is OK in principle, but wouldn't we end up with a near-daily because of the sliding window? Today it would be for ports removed before March 20, tomorrow for ports removed before March 21, etc.

Aside from that, there is already such an overview on FreshPorts here:
https://www.freshports.org/ports-expiration-date.php?sort=expiration_date
Comment 27 Yuri Victorovich freebsd_committer 2020-04-04 21:39:05 UTC
And again, the ports commit r530719 marked a whole lot of ports DEPRECATED without any notification to maintainers.
Comment 28 Adam Weinberger freebsd_committer 2020-04-04 22:51:10 UTC
It marked ports that were broken for at least 6 months. Maintainers gets build failure emails. I'm in agreement that we need an automated system to alert maintainers about ports marked DEPRECATED, but these ports were broken without fixes for over half a year; there was no obligation to perform any other step. 

I said previously that I'm in support of an automated solution. Instead of updating this PR every time a DEPRECATED sweep occurs, your efforts would be of far better use helping out with the work already started to build the automated system.
Comment 29 Yuri Victorovich freebsd_committer 2020-04-04 23:02:37 UTC
There's also no message to maintainer when the port is marked BROKEN.

When some port becomes unfetchable and portmgr catches this early and marks it BROKEN there is a very high chance that the maintainer gets no messages at all.

For example, I got exactly zero fallout messages about misc/crosti and now see that it has been marked BROKEN on 2019-11-06.
Comment 30 Adam Weinberger freebsd_committer 2020-04-04 23:06:51 UTC
As I said, we need an automated system. Clearly what we have either doesn't work or doesn't exist.

And like I said, you can help with that or not, but if you choose not to, venting frustration in this PR doesn't help the process.