FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 11-03-2011, 02:16 PM
Dan McGee
 
Default 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

Thu Nov 3 17:30:02 2011
Return-path: <devel-bounces@lists.fedoraproject.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Thu, 03 Nov 2011 17:18:06 +0200
Received: from bastion01.fedoraproject.org ([209.132.181.2]:35792 helo=bastion.fedoraproject.org)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <devel-bounces@lists.fedoraproject.org>)
id 1RLz3O-0008Mi-Fi
for tom@linux-archive.org; Thu, 03 Nov 2011 17:18:06 +0200
Received: from lists.fedoraproject.org (collab01.vpn.fedoraproject.org [192.168.1.21])
by bastion01.phx2.fedoraproject.org (Postfix) with ESMTP id E27C720EB7;
Thu, 3 Nov 2011 15:18:10 +0000 (UTC)
Received: from collab1.fedoraproject.org (localhost.localdomain [127.0.0.1])
by lists.fedoraproject.org (Postfix) with ESMTP id EE349326760;
Thu, 3 Nov 2011 15:18:09 +0000 (UTC)
X-Original-To: devel@lists.fedoraproject.org
Delivered-To: devel@lists.fedoraproject.org
Received: from smtp-mm02.fedoraproject.org (smtp-mm02.fedoraproject.org
[66.35.62.164])
by lists.fedoraproject.org (Postfix) with ESMTP id A40FC3266EF
for <devel@lists.fedoraproject.org>;
Thu, 3 Nov 2011 15:18:08 +0000 (UTC)
Received: from mail-bw0-f45.google.com (mail-bw0-f45.google.com
[209.85.214.45])
by smtp-mm02.fedoraproject.org (Postfix) with ESMTP id 148D5E71DB
for <devel@lists.fedoraproject.org>;
Thu, 3 Nov 2011 15:18:07 +0000 (UTC)
Received: by bkbzu5 with SMTP id zu5so1503564bkb.32
for <devel@lists.fedoraproject.org>;
Thu, 03 Nov 2011 08:18:07 -0700 (PDT)
Received: by 10.204.136.152 with SMTP id r24mr8726208bkt.5.1320333486653;
Thu, 03 Nov 2011 08:18:06 -0700 (PDT)
Received: from valhalla.rhi.hi.is (valhalla.rhi.hi.is. [130.208.69.191])
by mx.google.com with ESMTPS id z13sm2539417bkw.8.2011.11.03.08.18.05
(version=SSLv3 cipher=OTHER); Thu, 03 Nov 2011 08:18:05 -0700 (PDT)
Message-ID: <4EB2B09B.5080706@gmail.com>
Date: Thu, 03 Nov 2011 15:17:47 +0000
From: =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
<johannbg@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:7.0) Gecko/20110927 Thunderbird/7.0
MIME-Version: 1.0
To: devel@lists.fedoraproject.org
Subject: Re: convert init.d to systemd,
how to determine which python is installed
References: <4EB2A0BB.1080607@redhat.com> <1320331098.10590.33.camel@atropine>
In-Reply-To: <1320331098.10590.33.camel@atropine>
X-BeenThere: devel@lists.fedoraproject.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Development discussions related to Fedora
<devel@lists.fedoraproject.org>
List-Id: Development discussions related to Fedora
<devel.lists.fedoraproject.org>
List-Unsubscribe: <https://admin.fedoraproject.org/mailman/listinfo/devel>,
<mailto:devel-request@lists.fedoraproject.org?subject=unsubscrib e>
List-Archive: <http://lists.fedoraproject.org/pipermail/devel>
List-Post: <mailto:devel@lists.fedoraproject.org>
List-Help: <mailto:devel-request@lists.fedoraproject.org?subject=help>
List-Subscribe: <https://admin.fedoraproject.org/mailman/listinfo/devel>,
<mailto:devel-request@lists.fedoraproject.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: devel-bounces@lists.fedoraproject.org
Errors-To: devel-bounces@lists.fedoraproject.org

T24gMTEvMDMvMjAxMSAwMjozOCBQTSwgQWRhbSBKYWNrc29uIH dyb3RlOgo+IE9uIFRodSwgMjAx
MS0xMS0wMyBhdCAxMDoxMCAtMDQwMCwgS2FsZWIgUy4gS0VJVE hMRVkgd3JvdGU6Cj4+IEhla2FG
UyBydW5zIGEgZGFlbW9uIGZyb20gaW5pdC4gSXQncyBhIEJvdH RsZSAocHl0aG9uLWJhc2VkKSBo
dHRwIHNlcnZlci4KPj4KPj4gSW4gb3JkZXIgdG8gd29yayBvbi wgZS5nLiBSSEVMNiBpbiBhZGRp
dGlvbiB0byBGZWRvcmEsIHRoZSBvbGQgaW5pdAo+PiBzY3JpcH QgaGFzOgo+PiAuLi4KPj4gdmVy
Y21kPSJmcm9tIGRpc3R1dGlscy5zeXNjb25maWcgaW1wb3J0IG dldF9weXRob25fbGliOyBwcmlu
dAo+PiBnZXRfcHl0aG9uX2xpYigpIgo+PiBweV9kaXI9JChweX Rob24gLWMgIiR7dmVyY21kfSIp
Cj4+IGV4ZT0iJHtweV9kaXJ9L2hla2Fmc2QucHkiCj4+IC4uLg o+Pgo+PiBJJ2Qga2luZGEgbGlr
ZSB0byBwcmVzZXJ2ZSB0aGF0IGluIHNvbWUgZmFzaGlvbiBpbi B0aGUgbmV3IHN5c3RlbWQKPj4g
c2VydmljZSBmaWxlLiBOb3QgdG8gcnVuIG9uIFJIRUw2IG9idm lvdXNseSwgYnV0IHRvIGJlIGZ1
dHVyZS1wcm9vZgo+PiBhZ2FpbnN0IHRoZSBkYXkgd2hlbiBweX Rob24yLjggb3IgcHl0aG9uMy54
IHNoaXBzIGluIEYxNyBvciBsYXRlciBvcgo+PiBSSEVMNywgZS 5nLgo+IEdlbmVyYXRlIHRoZSBh
Y3R1YWwgc3lzdGVtZCBzZXJ2aWNlIGZpbGUgYXQgcnBtYnVpbG QgdGltZS4gIFNvbWV0aGluZwo+
IGxpa2UgdGhpcyBtYXliZSwgaWYgeW91J3JlIHVzaW5nIHRoZS BzdGFuZGFyZCBtYWdpYyBmb3IK
PiAle3B5dGhvbl9zaXRlbGlifToKPgo+IFNvdXJjZTE6IGhla2 Fmcy5zZXJ2aWNlLmluCj4gLi4u
Cj4gc2VkIHMvQFBZVEhPTl9TSVRFTElCQC8le3B5dGhvbl9zaX RlbGlifS8gJXtTT1VSQ0UxfT4g
ICRSUE1fQlVJTERfUk9PVC9saWIvc3lzdGVtZC9zeXN0ZW0vaG VrYWZzLnNlcnZpY2UKCkp1c3Qg
b3V0IG9mIGN1cmlvc2l0eSBhcmUgdGhlcmUgYW55IGd1aWRlbG luZXMgZm9yYmlkZGluZyBjcmVh
dGluZyBhIApzeW1ib2xpYyBsaW5rIHRvIHRoYXQgZmlsZSBmcm 9tIC91c3Ivc2JpbgoKU28gaW5z
dGVhZCBvZiBoYXZpbmcgYSB1bml0IGZpbGUgdGhhdCBsb29rcy BsaWtlIHRoaXMuLi4KCltVbml0
XQpEZXNjcmlwdGlvbj1IZWthRlMgYW4gQ2x1c3RlcmVkIEZpbG UgU3lzdGVtIFNlcnZlcgpSZXF1
aXJlcz1nbHVzdGVyZC5zZXJ2aWNlCkFmdGVyPW5ldHdvcmsudG FyZ2V0IGdsdXN0ZXJkLnNlcnZp
Y2UKCltTZXJ2aWNlXQpUeXBlPW9uZXNob3QKRXhlY1N0YXJ0PS 91c3IvbGliL3B5dGhvbjIuNy9z
aXRlLXBhY2thZ2VzL2hla2Fmc2QucHkgLWwgCi92YXIvbG9nL2 hla2Fmcy9oZWthZnNkIC1wIC9y
dW4vaGVrYWZzZC5waWQKUmVtYWluQWZ0ZXJFeGl0PXllcwoKW0 luc3RhbGxdCldhbnRlZEJ5PW11
bHRpLXVzZXIudGFyZ2V0CgpZb3Ugd291bGQgaGF2ZSBhIHVuaX QgZmlsZSBsaWtlIHRoaXMuLi4K
CltVbml0XQpEZXNjcmlwdGlvbj1IZWthRlMgYW4gQ2x1c3Rlcm VkIEZpbGUgU3lzdGVtIFNlcnZl
cgpSZXF1aXJlcz1nbHVzdGVyZC5zZXJ2aWNlCkFmdGVyPW5ldH dvcmsudGFyZ2V0IGdsdXN0ZXJk
LnNlcnZpY2UKCltTZXJ2aWNlXQpUeXBlPW9uZXNob3QKRXhlY1 N0YXJ0PS91c3Ivc2Jpbi9oZWth
ZnNkIC1sIC92YXIvbG9nL2hla2Fmcy9oZWthZnNkIC1wIC9ydW 4vaGVrYWZzZC5waWQKUmVtYWlu
QWZ0ZXJFeGl0PXllcwoKW0luc3RhbGxdCldhbnRlZEJ5PW11bH RpLXVzZXIudGFyZ2V0CgpBbmQg
anVzdCBtb3ZlIHRoZSBsaW5rIHVwb24gdXBkYXRlL3VwZ3JhZG UgcG9pbnRpbmcgdG8gdGhlIG5l
dyB2ZXJzaW9uPwoKSkJHCi0tIApkZXZlbCBtYWlsaW5nIGxpc3 QKZGV2ZWxAbGlzdHMuZmVkb3Jh
cHJvamVjdC5vcmcKaHR0cHM6Ly9hZG1pbi5mZWRvcmFwcm9qZW N0Lm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2RldmVs
 
Old 11-03-2011, 02:31 PM
Tom Gundersen
 
Default Package signoffs page

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
 
Old 11-03-2011, 02:37 PM
Dan McGee
 
Default Package signoffs page

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
 
Old 11-03-2011, 04:05 PM
Eric Bélanger
 
Default Package signoffs page

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.
 
Old 11-03-2011, 04:17 PM
Thomas Bächler
 
Default Package signoffs page

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)
 
Old 11-03-2011, 06:27 PM
Tom Gundersen
 
Default Package signoffs page

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
 
Old 11-03-2011, 08:37 PM
Gaetan Bisson
 
Default Package signoffs page

[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
 
Old 11-04-2011, 08:56 AM
Lukas Fleischer
 
Default Package signoffs page

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?
 
Old 11-04-2011, 03:14 PM
Dan McGee
 
Default Package signoffs page

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
 
Old 11-04-2011, 04:28 PM
Eric Bélanger
 
Default Package signoffs page

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
>
 

Thread Tools




All times are GMT. The time now is 04:28 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org