[arch-dev-public] package signoffs

Jan de Groot

9 Feb 2010 9 Feb '10

8:38 a.m.

These days it looks like almost nobody in our developer team uses i686 anymore. I still have a laptop running it, but I barely use it. I think it's time to revise our signoff policy. I was thinking about making it a bit more flexible: - signoff by 3 devs, no matter what architecture, and no bugs within 3 days -> move - signoff for both architectures, 2 each -> move - no signoff, no bugs for a week -> move For the last thing to get implemented, this can be a bit tricky. Sometimes developers throw something in testing, just to test something, and it sits there for weeks without anyone knowing why it's in testing. I would like to have every package that goes to testing getting committed with a reason in the commit message. This way we can find out why something is in testing and if we can easily move it out without breaking things.

Show replies by date

Thomas Bächler

9 Feb 9 Feb

8:46 a.m.

Am 09.02.2010 09:38, schrieb Jan de Groot:

...

These days it looks like almost nobody in our developer team uses i686 anymore. I still have a laptop running it, but I barely use it.

I think it's time to revise our signoff policy. I was thinking about making it a bit more flexible:

- signoff by 3 devs, no matter what architecture, and no bugs within 3 days -> move - signoff for both architectures, 2 each -> move

Actually, until now we had 2 for each architecture, minus the original commiter. So if I use x86_64, I need 1 x86_64 and 2 i686 signoffs. These days, I even move things with a single i686 signoff. I've had ppp, openvpn and wpa_supplicant in testing for over a week. I got signoffs for the latter after poking you and Roman personally (really personally, I had to threaten both of you with my arsenal of guns and nuclear weapons so you signed off) - and that although probably everyone of us uses wpa_supplicant, directly or indirectly. Still, all signoffs are for x86_64.

...

- no signoff, no bugs for a week -> move

For the last thing to get implemented, this can be a bit tricky. Sometimes developers throw something in testing, just to test something, and it sits there for weeks without anyone knowing why it's in testing. I would like to have every package that goes to testing getting committed with a reason in the commit message. This way we can find out why something is in testing and if we can easily move it out without breaking things.

We could implement a special case for this in archrelease and add this to the commit message.

Allan McRae

8:49 a.m.

On 09/02/10 18:38, Jan de Groot wrote:

...

These days it looks like almost nobody in our developer team uses i686 anymore. I still have a laptop running it, but I barely use it.

I think both architectures are an issues, although I agree i686 is worse. There is rarely a signoff without requiring a bump these days. As an aside, in the last month there has been five devs signoff for i686 (me, Eric, Andrea, Vesa, Dan), but I was surprised to see three of these still used i686...

...

I think it's time to revise our signoff policy. I was thinking about making it a bit more flexible:

- signoff by 3 devs, no matter what architecture, and no bugs within 3 days -> move - signoff for both architectures, 2 each -> move - no signoff, no bugs for a week -> move

Sounds fine to me. I know several of us give a "signoff" after a week if there appears to be no issues whether or not we use the package...

...

For the last thing to get implemented, this can be a bit tricky. Sometimes developers throw something in testing, just to test something, and it sits there for weeks without anyone knowing why it's in testing. I would like to have every package that goes to testing getting committed with a reason in the commit message. This way we can find out why something is in testing and if we can easily move it out without breaking things.

Good commit messages should make the reason for testing clear anyway. Allan

Paul Mattal

12:12 p.m.

On 02/09/2010 03:49 AM, Allan McRae wrote:

...

On 09/02/10 18:38, Jan de Groot wrote:

...
These days it looks like almost nobody in our developer team uses i686 anymore. I still have a laptop running it, but I barely use it.

I think both architectures are an issues, although I agree i686 is worse. There is rarely a signoff without requiring a bump these days.

As an aside, in the last month there has been five devs signoff for i686 (me, Eric, Andrea, Vesa, Dan), but I was surprised to see three of these still used i686...

...
I think it's time to revise our signoff policy. I was thinking about making it a bit more flexible:

- signoff by 3 devs, no matter what architecture, and no bugs within 3 days -> move - signoff for both architectures, 2 each -> move - no signoff, no bugs for a week -> move

Sounds fine to me. I know several of us give a "signoff" after a week if there appears to be no issues whether or not we use the package...

...
For the last thing to get implemented, this can be a bit tricky. Sometimes developers throw something in testing, just to test something, and it sits there for weeks without anyone knowing why it's in testing. I would like to have every package that goes to testing getting committed with a reason in the commit message. This way we can find out why something is in testing and if we can easily move it out without breaking things.

Good commit messages should make the reason for testing clear anyway.

One thought to add: I think the signoffs are more useful as a "sanity check" than a test of the newly-implemented functionality. I think the primary benefit of signoffs is catching obvious regressions, more than making sure we, in fact, did close bug #83446 completely and correctly. It's still good to have descriptive commit messages, but I think lately we've been trying too hard to test the specific thing(s) in the commit message, rather than using it as a clue as to what to sanity check. That's extra benefit when people do it, but extra obstacle to getting signoffs done if people feel obliged to replicate the precise set of test conditions necessary to fully test a fix. - P

Thomas Bächler

12:41 p.m.

Am 09.02.2010 13:12, schrieb Paul Mattal:

...

I think the signoffs are more useful as a "sanity check" than a test of the newly-implemented functionality. I think the primary benefit of signoffs is catching obvious regressions, more than making sure we, in fact, did close bug #83446 completely and correctly.

Most importantly, the signoffs are there to verify that neither the package files nor the contained binaries are corrupted. An i686 signoff is still necessary to see that the package installs fine and the binaries actually execute - an x86_64 signoff will tell you that the commands in the PKGBUILD are sane, but not that nothing got corrupted.

Dan McGee

1:34 p.m.

On Tue, Feb 9, 2010 at 6:41 AM, Thomas Bächler wrote:

...

Am 09.02.2010 13:12, schrieb Paul Mattal:

...
I think the signoffs are more useful as a "sanity check" than a test of the newly-implemented functionality. I think the primary benefit of signoffs is catching obvious regressions, more than making sure we, in fact, did close bug #83446 completely and correctly.

Most importantly, the signoffs are there to verify that neither the package files nor the contained binaries are corrupted. An i686 signoff is still necessary to see that the package installs fine and the binaries actually execute - an x86_64 signoff will tell you that the commands in the PKGBUILD are sane, but not that nothing got corrupted.

Remember that one of the original reasons we went to a "draconian" signoff policy was due to an unbootable kernel getting into [core]. We haven't had that happen again so something worked here. When you look at it that way, a signoff from another person is essential to prove that it didn't break badly. No noise for a week however does make it pretty likely that nothing broke. -Dan

Thomas Bächler

1:57 p.m.

Am 09.02.2010 14:34, schrieb Dan McGee:

...

...
Most importantly, the signoffs are there to verify that neither the package files nor the contained binaries are corrupted. An i686 signoff is still necessary to see that the package installs fine and the binaries actually execute - an x86_64 signoff will tell you that the commands in the PKGBUILD are sane, but not that nothing got corrupted.

Remember that one of the original reasons we went to a "draconian" signoff policy was due to an unbootable kernel getting into [core].

I remember the discussion. The problem was that the i686 package got corrupted during upload.

...

We haven't had that happen again so something worked here. When you look at it that way, a signoff from another person is essential to prove that it didn't break badly. No noise for a week however does make it pretty likely that nothing broke.

... or that nobody tried it (as probably nobody tried testing/openvpn, one of the core packages that barely any developer uses).

Paul Mattal

2:34 p.m.

On 02/09/2010 08:57 AM, Thomas Bächler wrote:

...

Am 09.02.2010 14:34, schrieb Dan McGee:

...
...
Most importantly, the signoffs are there to verify that neither the package files nor the contained binaries are corrupted. An i686 signoff is still necessary to see that the package installs fine and the binaries actually execute - an x86_64 signoff will tell you that the commands in the PKGBUILD are sane, but not that nothing got corrupted.

Remember that one of the original reasons we went to a "draconian" signoff policy was due to an unbootable kernel getting into [core].

I remember the discussion. The problem was that the i686 package got corrupted during upload.

...
We haven't had that happen again so something worked here. When you look at it that way, a signoff from another person is essential to prove that it didn't break badly. No noise for a week however does make it pretty likely that nothing broke.

... or that nobody tried it (as probably nobody tried testing/openvpn, one of the core packages that barely any developer uses).

I like a way I've seen Aaron do this-- when signoffs are not forthcoming on something, it's okay to have someone signoff as "responsible" in such a scenario, without actually testing. It's an "I take responsibility", which certainly it isn't the same as a test, but is at least a somewhat higher bar in practice, since nobody wants their name explicitly associated with broken stuff. - P

Allan McRae

2:39 p.m.

On 10/02/10 00:34, Paul Mattal wrote:

...

On 02/09/2010 08:57 AM, Thomas Bächler wrote:

...
Am 09.02.2010 14:34, schrieb Dan McGee:

...
...
Most importantly, the signoffs are there to verify that neither the package files nor the contained binaries are corrupted. An i686 signoff is still necessary to see that the package installs fine and the binaries actually execute - an x86_64 signoff will tell you that the commands in the PKGBUILD are sane, but not that nothing got corrupted.

Remember that one of the original reasons we went to a "draconian" signoff policy was due to an unbootable kernel getting into [core].

I remember the discussion. The problem was that the i686 package got corrupted during upload.

...
We haven't had that happen again so something worked here. When you look at it that way, a signoff from another person is essential to prove that it didn't break badly. No noise for a week however does make it pretty likely that nothing broke.

... or that nobody tried it (as probably nobody tried testing/openvpn, one of the core packages that barely any developer uses).

I like a way I've seen Aaron do this-- when signoffs are not forthcoming on something, it's okay to have someone signoff as "responsible" in such a scenario, without actually testing. It's an "I take responsibility", which certainly it isn't the same as a test, but is at least a somewhat higher bar in practice, since nobody wants their name explicitly associated with broken stuff.

Well... allanbrokeit

Eric Bélanger

6:59 p.m.

On Tue, Feb 9, 2010 at 3:49 AM, Allan McRae wrote:

...

On 09/02/10 18:38, Jan de Groot wrote:

...
These days it looks like almost nobody in our developer team uses i686 anymore. I still have a laptop running it, but I barely use it.

I think both architectures are an issues, although I agree i686 is worse. There is rarely a signoff without requiring a bump these days.

As an aside, in the last month there has been five devs signoff for i686 (me, Eric, Andrea, Vesa, Dan), but I was surprised to see three of these still used i686...

It might just be an impression but it seems to me that the signoffs are mostly done by a small group of devs. I realize that some of you are busy/inactive but it would be easier and faster if everyone tried to do signoffs once in a while. If we rely on the same 3-4 devs for signoffs, then if they are busy, inactive, forget or don't use the package, then the signoff process become stalled. Therefore, we have all these bumps in the signoff threads. As far as i686 goes, if you have a i686 chroot on your x86_64 system you can do some i686 signoff. Of course, you can't test boot related packages like the kernel or udev but command line utilities like nano or wget as well as libraries can be tested and signed off. One reason that it takes time to get signoffs for certain packages is that we don't know if enough devs use it to get the required signoff. For instance, I don't use openvpn. How many devs use openvpn? I don't know and probably no-one does. A while ago, I started this: http://wiki.archlinux.org/index.php/DeveloperWiki:CoreSignoffs#List_of_poten... to fix that issue but basically no-one bothered to fill it up. If we would know how many dev use these low usage packages, then we could automatically send the signoff thread to both the dev ML and to the arch-general ML and specifically ask for users signoff instead of waiting for dev signoffs that will never come.

...

...
I think it's time to revise our signoff policy. I was thinking about making it a bit more flexible:

- signoff by 3 devs, no matter what architecture, and no bugs within 3 days -> move - signoff for both architectures, 2 each -> move - no signoff, no bugs for a week -> move

Sounds fine to me.

same here.

...

I know several of us give a "signoff" after a week if there appears to be no issues whether or not we use the package...

I did that several time. I just do a package sanity test.

...

...
For the last thing to get implemented, this can be a bit tricky. Sometimes developers throw something in testing, just to test something, and it sits there for weeks without anyone knowing why it's in testing. I would like to have every package that goes to testing getting committed with a reason in the commit message. This way we can find out why something is in testing and if we can easily move it out without breaking things.

Good commit messages should make the reason for testing clear anyway.

Allan

Thomas Bächler

10 Feb 10 Feb

9:22 a.m.

Am 09.02.2010 19:59, schrieb Eric Bélanger:

...

It might just be an impression but it seems to me that the signoffs are mostly done by a small group of devs. I realize that some of you are busy/inactive but it would be easier and faster if everyone tried to do signoffs once in a while. If we rely on the same 3-4 devs for signoffs, then if they are busy, inactive, forget or don't use the package, then the signoff process become stalled. Therefore, we have all these bumps in the signoff threads.

I apologize for that. I sometimes don't have the time to update my system for a while week and when I do, I forgot which signoffs are pending. I can't update the system if I don't know if I have some free time after the update, because things break in testing every now and then.

...

As far as i686 goes, if you have a i686 chroot on your x86_64 system you can do some i686 signoff. Of course, you can't test boot related packages like the kernel or udev but command line utilities like nano or wget as well as libraries can be tested and signed off.

That is true. And it is those system-critical i686 packages like udev who are barely signed off on i686.

Aaron Griffin

7:37 p.m.

On Wed, Feb 10, 2010 at 3:22 AM, Thomas Bächler wrote:

...

Am 09.02.2010 19:59, schrieb Eric Bélanger:

...
It might just be an impression but it seems to me that the signoffs are mostly done by a small group of devs. I realize that some of you are busy/inactive but it would be easier and faster if everyone tried to do signoffs once in a while. If we rely on the same 3-4 devs for signoffs, then if they are busy, inactive, forget or don't use the package, then the signoff process become stalled. Therefore, we have all these bumps in the signoff threads.

I apologize for that. I sometimes don't have the time to update my system for a while week and when I do, I forgot which signoffs are pending. I can't update the system if I don't know if I have some free time after the update, because things break in testing every now and then.

This is the reason that I originally wanted the web-based signoffs. They were implemented, but never took off. The theory was that, when I updated after a week or so, I can check for "pending signoffs" on a list and check some boxes.

...

...
As far as i686 goes, if you have a i686 chroot on your x86_64 system you can do some i686 signoff. Of course, you can't test boot related packages like the kernel or udev but command line utilities like nano or wget as well as libraries can be tested and signed off.

That is true. And it is those system-critical i686 packages like udev who are barely signed off on i686.

I still use i686 on my thinkpad, FWIW

Allan McRae

11:15 p.m.

On 11/02/10 05:37, Aaron Griffin wrote:

...

On Wed, Feb 10, 2010 at 3:22 AM, Thomas Bächler wrote:

...
Am 09.02.2010 19:59, schrieb Eric Bélanger:

...
It might just be an impression but it seems to me that the signoffs are mostly done by a small group of devs. I realize that some of you are busy/inactive but it would be easier and faster if everyone tried to do signoffs once in a while. If we rely on the same 3-4 devs for signoffs, then if they are busy, inactive, forget or don't use the package, then the signoff process become stalled. Therefore, we have all these bumps in the signoff threads.

I apologize for that. I sometimes don't have the time to update my system for a while week and when I do, I forgot which signoffs are pending. I can't update the system if I don't know if I have some free time after the update, because things break in testing every now and then.

This is the reason that I originally wanted the web-based signoffs. They were implemented, but never took off. The theory was that, when I updated after a week or so, I can check for "pending signoffs" on a list and check some boxes.

As an alternative. "pacman -S pacman-contrib; paclist testing". Allan

Pierre Schmitz

11:22 p.m.

Am Mittwoch, 10. Februar 2010 20:37:09 schrieb Aaron Griffin:

...

This is the reason that I originally wanted the web-based signoffs. They were implemented, but never took off.

The problem is that the webinterface is not very user friendly atm.. We would also need some way to add information about the package that should be signed- off and to add comments. As long as we use the mailing list for that its just easier to send the sign-off here. Something like review board (e.g. http://reviewboard.kde.org/) is similar to what would be needed but way to much overhead. -- Pierre Schmitz, https://users.archlinux.de/~pierre

5206

Age (days ago)

5207

Last active (days ago)

List overview

Download

13 comments

8 participants

participants (8)

Aaron Griffin
Allan McRae
Dan McGee
Eric Bélanger
Jan de Groot
Paul Mattal
Pierre Schmitz
Thomas Bächler