Summary: | Maintainers should be notified of newly BROKEN ports (potentially in "Issues that need attention" emails) | ||
---|---|---|---|
Product: | Services | Reporter: | Yuri Victorovich <yuri> |
Component: | Bug Tracker | Assignee: | Bugmeister <bugmeister> |
Status: | Open --- | ||
Severity: | Affects Some People | CC: | adamw, grembo, jbeich, linimon, lwhsu, pi, portmaster, portmgr, rene |
Priority: | --- | Keywords: | feature, needs-qa |
Version: | unspecified | ||
Hardware: | Any | ||
OS: | Any |
Description
Yuri Victorovich
2020-01-11 15:30:06 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. Portmgr does not manage the "Issues that need attention" e-mails 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. (In reply to Antoine Brodin from comment #2) Who sends "issues that needs attention" emails, then, if it's not portmgr ? (In reply to Kurt Jaeger from comment #4) It's something in bugzilla 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 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. 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. (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. (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. (In reply to Michael Gmelin from comment #10) Filing a PR for every BROKEN/DEPRECATED is not feasible. (In reply to Adam Weinberger from comment #11) Too much noise in bugzilla? (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. (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 (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. (In reply to Li-Wen Hsu from comment #7) The maintainer received the following emails before graphics/vv was marked BROKEN: http://docs.freebsd.org/cgi/mid.cgi?201908070159.x771xdaO096467 http://docs.freebsd.org/cgi/mid.cgi?201908070212.x772C2Nc097537 http://docs.freebsd.org/cgi/mid.cgi?201908071230.x77CUPnD063443 http://docs.freebsd.org/cgi/mid.cgi?201908071457.x77Evw3o080816 (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. 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. (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? (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. (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. 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 (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. (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. (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 (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 And again, the ports commit r530719 marked a whole lot of ports DEPRECATED without any notification to maintainers. 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. 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. 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. |