[arch-dev-public] Package signoffs page

[Eric Bélanger]

On Fri, Nov 4, 2011 at 1:37 PM, Dan McGee <dpmcgee at gmail.com> wrote:
> On Fri, Nov 4, 2011 at 12:28 PM, Eric Bélanger <snowmaniscool at gmail.com> wrote:
>> On Fri, Nov 4, 2011 at 12:14 PM, Dan McGee <dpmcgee at gmail.com> wrote:
>>> On Thu, Nov 3, 2011 at 10:16 AM, Dan McGee <dpmcgee at 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
>>>
>>
>