[arch-dev-public] Package signoffs page
Devs, This seems like a good time to get the ball fully rolling on the package signoffs page: https://www.archlinux.org/packages/signoffs/ I and a few others would like to make this the goto for signoffs- fewer emails, easier to see at a glance what signoffs are pending, etc. Given we have a large set of packages in [testing] right now for some [core] signature rebuilds, this seems like an ideal time to get some feedback so we can fully migrate to using this page. So this is a call for (constructive) feedback on what more I need to implement to make it useful to all of you. A list below is things already on the todo list that definitely need to be done; if there are other things that *need* to be done, please let me know. If there are other things that would be nice, let me know too, but that might be worth a feature request that can be worked on after we switch. Must haves: * A way to cancel a signoff * Signoff "blacklist" or modification- basically say "this package doesn't need signoffs, just remove it from display" * A daily summary email saying "hey gang, here are today's pending signoffs" Thanks! -Dan
Hi Dan, Thanks for working on this, I have wondered why we don't use this. On Thu, Nov 3, 2011 at 4:16 PM, Dan McGee <dpmcgee@gmail.com> wrote:
This seems like a good time to get the ball fully rolling on the package signoffs page: https://www.archlinux.org/packages/signoffs/
I and a few others would like to make this the goto for signoffs- fewer emails, easier to see at a glance what signoffs are pending, etc. Given we have a large set of packages in [testing] right now for some [core] signature rebuilds, this seems like an ideal time to get some feedback so we can fully migrate to using this page.
So this is a call for (constructive) feedback on what more I need to implement to make it useful to all of you. A list below is things already on the todo list that definitely need to be done; if there are other things that *need* to be done, please let me know. If there are other things that would be nice, let me know too, but that might be worth a feature request that can be worked on after we switch.
From my point of view it is already very useful. And as soon as it is possible to cancel signoffs I think we should start using it.
* A daily summary email saying "hey gang, here are today's pending signoffs"
Not so sure about this feature. It might cause too much noise to be useful. I suggest we still send out the initial signoff emails when we push the package to testing (with maybe some comments about changes), as It might still be useful to have a ML thread for discussing the update. I think it would be best to let the maintainer send a remainder email if it is needed, rather than sending them automatically. Cheers, Tom
On Thu, Nov 3, 2011 at 10:31 AM, Tom Gundersen <teg@jklm.no> wrote:
* A daily summary email saying "hey gang, here are today's pending signoffs"
Not so sure about this feature. It might cause too much noise to be useful.
I suggest we still send out the initial signoff emails when we push the package to testing (with maybe some comments about changes), as It might still be useful to have a ML thread for discussing the update. I think it would be best to let the maintainer send a remainder email if it is needed, rather than sending them automatically.
My goal in adding this is to remove the need completely for those update emails. I know I just delete them immediately anyway unless I am doing an -Syu in the next 5 minutes and can check packages right then and there. For the 20% of signoff emails that have actual content, I agree- keep sending those. But a once-a-day report is about as low-noise as it gets compared to what we have now, I was thinking, and rarely does a package need a <24h turnaround to get out of [testing] unless it is security related (which would be another relatively straightforward feature to implement- "send email now for this package" or whatever). -Dan
On Thu, Nov 3, 2011 at 11:16 AM, Dan McGee <dpmcgee@gmail.com> wrote:
Devs,
This seems like a good time to get the ball fully rolling on the package signoffs page: https://www.archlinux.org/packages/signoffs/
I and a few others would like to make this the goto for signoffs- fewer emails, easier to see at a glance what signoffs are pending, etc. Given we have a large set of packages in [testing] right now for some [core] signature rebuilds, this seems like an ideal time to get some feedback so we can fully migrate to using this page.
So this is a call for (constructive) feedback on what more I need to implement to make it useful to all of you. A list below is things already on the todo list that definitely need to be done; if there are other things that *need* to be done, please let me know. If there are other things that would be nice, let me know too, but that might be worth a feature request that can be worked on after we switch.
Must haves: * A way to cancel a signoff * Signoff "blacklist" or modification- basically say "this package doesn't need signoffs, just remove it from display" * A daily summary email saying "hey gang, here are today's pending signoffs"
Thanks!
-Dan
We need a way to red flag a package , i..e. "This package is NOT OK" on the interface. Of course, this should be followed up with an email on the ML explaining the issue.
No idea if some of this has been implemented already, I'll just write it down.
Must haves: * A way to cancel a signoff * Signoff "blacklist" or modification- basically say "this package doesn't need signoffs, just remove it from display"
* A way to "disable" a signoff for a package ("this is not ready to go to core yet") and "enable" it when you actually want signoffs. For example, the "linux" package can often stay in testing for a week or two and doesn't need signoffs right away.
* A daily summary email saying "hey gang, here are today's pending signoffs"
* "This package has been waiting for signoffs for N days" reminders also must-haves:: * Display the actual number of signoffs for each built architecture * A way to block a package (what Eric said) maybe: * A possibility for integration into dbscripts (db-move could block based on signoff and blocker status)
On Thu, Nov 3, 2011 at 6:17 PM, Thomas Bächler <thomas@archlinux.org> wrote:
No idea if some of this has been implemented already, I'll just write it down.
Must haves: * A way to cancel a signoff * Signoff "blacklist" or modification- basically say "this package doesn't need signoffs, just remove it from display"
* A way to "disable" a signoff for a package ("this is not ready to go to core yet") and "enable" it when you actually want signoffs. For example, the "linux" package can often stay in testing for a week or two and doesn't need signoffs right away.
* A daily summary email saying "hey gang, here are today's pending signoffs"
* "This package has been waiting for signoffs for N days" reminders
also must-haves::
* Display the actual number of signoffs for each built architecture * A way to block a package (what Eric said)
maybe:
* A possibility for integration into dbscripts (db-move could block based on signoff and blocker status)
This might be counterproductive, as sometimes unpopular packages are moved without enough signoffs, or with some informal user signoffs (the pcmcia stuff springs to mind). It should be possible to override this, maybe with "db-move --force". -t
[2011-11-03 10:16:19 -0500] Dan McGee:
This seems like a good time to get the ball fully rolling on the package signoffs page: https://www.archlinux.org/packages/signoffs/
Great. I'm looking forward to using this. Only one suggestion: could we add a column with the packager name?
* A daily summary email saying "hey gang, here are today's pending signoffs"
I agree this is a must have: I like my emails to remind me of what I have to do. When packages are flagged out-of-date or added to TODO lists, we already receive notifications, and that is working very well. Maybe it's just me but I will surely forget to check the signoff page regularly unless emails remind me of the stuff pending there. Cheers. -- Gaetan
Forwarding this so dan can reply -------- Original Message -------- Subject: Re: [arch-general] [arch-dev-public] Package signoffs page Date: Fri, 4 Nov 2011 10:56:33 +0100 From: Lukas Fleischer <archlinux@cryptocrack.de> Reply-To: General Discussion about Arch Linux <arch-general@archlinux.org> To: arch-general@archlinux.org On Thu, Nov 03, 2011 at 10:16:19AM -0500, Dan McGee wrote:
Devs,
This seems like a good time to get the ball fully rolling on the package signoffs page: https://www.archlinux.org/packages/signoffs/
I and a few others would like to make this the goto for signoffs- fewer emails, easier to see at a glance what signoffs are pending, etc. Given we have a large set of packages in [testing] right now for some [core] signature rebuilds, this seems like an ideal time to get some feedback so we can fully migrate to using this page.
So this is a call for (constructive) feedback on what more I need to implement to make it useful to all of you. A list below is things already on the todo list that definitely need to be done; if there are other things that *need* to be done, please let me know. If there are other things that would be nice, let me know too, but that might be worth a feature request that can be worked on after we switch.
Must haves: * A way to cancel a signoff * Signoff "blacklist" or modification- basically say "this package doesn't need signoffs, just remove it from display" * A daily summary email saying "hey gang, here are today's pending signoffs"
+1. And +1 to a "red flag"/block feature to ensure packages that nuked someone's system won't be moved until this is resolved. By the way, are TUs encouraged to give their sign-offs as well or is this a dev-only thing? Oh, how will we handle user sign-offs in the future (I remember that these were asked for a few times)? Replies to the daily summary mails?
On Thu, Nov 3, 2011 at 10:16 AM, Dan McGee <dpmcgee@gmail.com> wrote:
Devs,
This seems like a good time to get the ball fully rolling on the package signoffs page: https://www.archlinux.org/packages/signoffs/
Devs (and TUs, someone link this to them please), We should be up and running now with a page that is 100% usable for our current purposes. PLEASE give it a shot, without diving in this will not gain steam and be used like it wasn't for 3 years. Needs addressed: * a package signoff can be marked as either 'known bad' or 'not enabled'. These are distinct boolean options, setting either of them will not allow signoffs. * signoffs can be revoked. * daily summary email on a per-testing-repo basis (preview coming soon) * packager/maintainer notes for a given package in a testing repo that are displayed with the signoff (see pacman on the page right now) * full filtering options on page (if you're not using JavaScript, you're silly, it is 2011, not 1994), and page never needs refreshing when doing multiple signoffs Two more questions/comments: 1. Dev/TU distinction- should anyone in either group be allowed to sign off on any package? - pros: simpler, we trust each other anyway, you can see exactly who signs off on what anyway so you aren't just relying on a magic 'Yes' to show up. - cons: not sure? "security"? or the fact that in the past we generally haven't crossed this boundary. 2. User signoffs- not even worried about this yet. Let the old solution work for now, which is sending an email to arch-general. -Dan
On Fri, Nov 4, 2011 at 12:14 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Thu, Nov 3, 2011 at 10:16 AM, Dan McGee <dpmcgee@gmail.com> wrote:
Devs,
This seems like a good time to get the ball fully rolling on the package signoffs page: https://www.archlinux.org/packages/signoffs/
Devs (and TUs, someone link this to them please),
We should be up and running now with a page that is 100% usable for our current purposes. PLEASE give it a shot, without diving in this will not gain steam and be used like it wasn't for 3 years.
Needs addressed: * a package signoff can be marked as either 'known bad' or 'not enabled'. These are distinct boolean options, setting either of them will not allow signoffs.
Unless I'm doing things wrong, this is only available for the packages I built. This defeats the purpose of the 'known bad' flag. Anyone should be able to flag any package as bad.
* signoffs can be revoked. * daily summary email on a per-testing-repo basis (preview coming soon)
The report should only be sent when there are package in the testing repo. I just received a useless notification for the empty multilib-testing repo (maybe you already implemented that and were only testing the system). I'm not sure about the usefulness of the reports for the community-testing and multilib-testing repo as signoffs are not required for these repo so people might not be bothered to sign them off. The section about packages older than 14 days is useful so perhaps reports for these repos should be weekly instead of daily. If people start signing them off (at least most of them), then I won't mind the daily report.
* packager/maintainer notes for a given package in a testing repo that are displayed with the signoff (see pacman on the page right now) * full filtering options on page (if you're not using JavaScript, you're silly, it is 2011, not 1994), and page never needs refreshing when doing multiple signoffs
Two more questions/comments: 1. Dev/TU distinction- should anyone in either group be allowed to sign off on any package? - pros: simpler, we trust each other anyway, you can see exactly who signs off on what anyway so you aren't just relying on a magic 'Yes' to show up.
another pros: some packages are nor used by many devs (e.g. lvm2, firmare) so if TUs use them, it would be good if they could signoff.
- cons: not sure? "security"? or the fact that in the past we generally haven't crossed this boundary. 2. User signoffs- not even worried about this yet. Let the old solution work for now, which is sending an email to arch-general.
-Dan
On Fri, Nov 4, 2011 at 12:28 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Fri, Nov 4, 2011 at 12:14 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Thu, Nov 3, 2011 at 10:16 AM, Dan McGee <dpmcgee@gmail.com> wrote:
Devs,
This seems like a good time to get the ball fully rolling on the package signoffs page: https://www.archlinux.org/packages/signoffs/
Devs (and TUs, someone link this to them please),
We should be up and running now with a page that is 100% usable for our current purposes. PLEASE give it a shot, without diving in this will not gain steam and be used like it wasn't for 3 years.
Needs addressed: * a package signoff can be marked as either 'known bad' or 'not enabled'. These are distinct boolean options, setting either of them will not allow signoffs.
Unless I'm doing things wrong, this is only available for the packages I built. This defeats the purpose of the 'known bad' flag. Anyone should be able to flag any package as bad. This seems fishy. Anyone can mark a package as bad? I'm not sure I agree here. Perhaps the equivalent of a "negative signoff" would make more sense, but a truely bad package should be removed from the repos ASAP, not marked here.
* signoffs can be revoked. * daily summary email on a per-testing-repo basis (preview coming soon)
The report should only be sent when there are package in the testing repo. I just received a useless notification for the empty multilib-testing repo (maybe you already implemented that and were only testing the system). Already fixed.
I'm not sure about the usefulness of the reports for the community-testing and multilib-testing repo as signoffs are not required for these repo so people might not be bothered to sign them off. Required? No. Helpful? Incredibly, it means someone else has run your package and you feel a lot better about it.
The section about packages older than 14 days is useful so perhaps reports for these repos should be weekly instead of daily. If people start signing them off (at least most of them), then I won't mind the daily report. We're going from like *50* emails in one day to 3 a day, which contain much more information. I'm not too concerned here.
* packager/maintainer notes for a given package in a testing repo that are displayed with the signoff (see pacman on the page right now) * full filtering options on page (if you're not using JavaScript, you're silly, it is 2011, not 1994), and page never needs refreshing when doing multiple signoffs
Two more questions/comments: 1. Dev/TU distinction- should anyone in either group be allowed to sign off on any package? - pros: simpler, we trust each other anyway, you can see exactly who signs off on what anyway so you aren't just relying on a magic 'Yes' to show up.
another pros: some packages are nor used by many devs (e.g. lvm2, firmare) so if TUs use them, it would be good if they could signoff.
- cons: not sure? "security"? or the fact that in the past we generally haven't crossed this boundary. 2. User signoffs- not even worried about this yet. Let the old solution work for now, which is sending an email to arch-general.
-Dan
On Fri, Nov 4, 2011 at 1:37 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Fri, Nov 4, 2011 at 12:28 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Fri, Nov 4, 2011 at 12:14 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Thu, Nov 3, 2011 at 10:16 AM, Dan McGee <dpmcgee@gmail.com> wrote:
Devs,
This seems like a good time to get the ball fully rolling on the package signoffs page: https://www.archlinux.org/packages/signoffs/
Devs (and TUs, someone link this to them please),
We should be up and running now with a page that is 100% usable for our current purposes. PLEASE give it a shot, without diving in this will not gain steam and be used like it wasn't for 3 years.
Needs addressed: * a package signoff can be marked as either 'known bad' or 'not enabled'. These are distinct boolean options, setting either of them will not allow signoffs.
Unless I'm doing things wrong, this is only available for the packages I built. This defeats the purpose of the 'known bad' flag. Anyone should be able to flag any package as bad. This seems fishy. Anyone can mark a package as bad? I'm not sure I agree here. Perhaps the equivalent of a "negative signoff" would make more sense, but a truely bad package should be removed from the repos ASAP, not marked here.
Just to be clear, by anyone I meant any dev or TU. Obviously, a package with major issues should be removed from testing but if it has minor issues (file conflicts, missing files like man pages, missing depends, etc) that should be fixed before pushing it to the main repo, there should be a way to mark it on the signoff page. Like a negative signoff as you called it. So that it does't get moved to the repos by mistake in case the maintainer checks the signoff pages before checking his emails. That's what my feature request was about.
* signoffs can be revoked. * daily summary email on a per-testing-repo basis (preview coming soon)
The report should only be sent when there are package in the testing repo. I just received a useless notification for the empty multilib-testing repo (maybe you already implemented that and were only testing the system). Already fixed.
I'm not sure about the usefulness of the reports for the community-testing and multilib-testing repo as signoffs are not required for these repo so people might not be bothered to sign them off. Required? No. Helpful? Incredibly, it means someone else has run your package and you feel a lot better about it.
The section about packages older than 14 days is useful so perhaps reports for these repos should be weekly instead of daily. If people start signing them off (at least most of them), then I won't mind the daily report. We're going from like *50* emails in one day to 3 a day, which contain much more information. I'm not too concerned here.
I suppose the community packages were not signed off because no-one bothered starting the signoff thread and the signoff page wasn't used. I guess it might change as we'll start using the signoff page regularly so keep the reports daily.
* packager/maintainer notes for a given package in a testing repo that are displayed with the signoff (see pacman on the page right now) * full filtering options on page (if you're not using JavaScript, you're silly, it is 2011, not 1994), and page never needs refreshing when doing multiple signoffs
Two more questions/comments: 1. Dev/TU distinction- should anyone in either group be allowed to sign off on any package? - pros: simpler, we trust each other anyway, you can see exactly who signs off on what anyway so you aren't just relying on a magic 'Yes' to show up.
another pros: some packages are nor used by many devs (e.g. lvm2, firmare) so if TUs use them, it would be good if they could signoff.
- cons: not sure? "security"? or the fact that in the past we generally haven't crossed this boundary. 2. User signoffs- not even worried about this yet. Let the old solution work for now, which is sending an email to arch-general.
-Dan
On Fri, Nov 4, 2011 at 1:24 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Fri, Nov 4, 2011 at 1:37 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Fri, Nov 4, 2011 at 12:28 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
Needs addressed: * a package signoff can be marked as either 'known bad' or 'not enabled'. These are distinct boolean options, setting either of them will not allow signoffs.
Unless I'm doing things wrong, this is only available for the packages I built. This defeats the purpose of the 'known bad' flag. Anyone should be able to flag any package as bad. This seems fishy. Anyone can mark a package as bad? I'm not sure I agree here. Perhaps the equivalent of a "negative signoff" would make more sense, but a truely bad package should be removed from the repos ASAP, not marked here.
Just to be clear, by anyone I meant any dev or TU. Obviously, a package with major issues should be removed from testing but if it has minor issues (file conflicts, missing files like man pages, missing depends, etc) that should be fixed before pushing it to the main repo, there should be a way to mark it on the signoff page. Like a negative signoff as you called it. So that it does't get moved to the repos by mistake in case the maintainer checks the signoff pages before checking his emails. That's what my feature request was about. OK, this makes sense. The data model is somewhat set up to allow this; I probably won't get to this immediately but it shouldn't be too hard to add the ability to signoff in a negative way. (there is also a yet-unused comments field attached to each signoff that is not yet exposed in the UI).
-Dan
One thing I have noticed is that I have no idea why these packages are in [testing] from just looking at the signoff page. Could we get the commit message shown? Allan
participants (7)
-
Allan McRae
-
Dan McGee
-
Eric Bélanger
-
Florian Pritz
-
Gaetan Bisson
-
Thomas Bächler
-
Tom Gundersen