On Dec 2, 2007 3:53 PM, Eric Belanger <email@example.com> wrote:
> On Sun, 2 Dec 2007, Travis Willard wrote:
> > On Dec 2, 2007 4:30 PM, Eric Belanger <firstname.lastname@example.org> wrote:
> >> On Sun, 2 Dec 2007, Travis Willard wrote:
> >>> That's not the way signoffs work. You CAN'T just 'assume' they are fine.
> >>> You have to wait. Sorry, but it breaks the whole system otherwise.
> >> Actually, these packages were already signed off by two devs: Dan for i686
> >> and me for x86_64. From an IRC discussion with Aaron, the devs who put the
> >> packages in testing counts as one of the two signoff. That might seem
> >> strange but it's the way it works unless the signoffs gets a better
> >> definition.
> > That doesn't seem sound to me. Recall the problem when the kernel
> > package that was uploaded had something screwy in it due to a bad
> > transfer. Under this situation, tpowa would have 'signed off' his own
> > upload, whoever built it for x86_64 would have signed it off for their
> > own upload, and then the buggy package i686 would have been pushed to
> > core.
> > If that's how we want our signoffs, then that's fine - I'm just
> > pointing out a possible flaw.
> I agree that the packager shouldn't count as a signoff. That how I
> undertood it before the little discussion in IRC.
> IMO, the way signoff should be done to prevent any potential screw up is
> that 2 devs other than the packagers should signoff and that each
> architecture should at least be signed off
So as to not clutter up Dan's thread, can we move this talk here?
To clarify. My intention was "at least 2 devs are responsible for the
package" - the statement DOES include the original packager, however,
let me point out that each cvs commit has 2 packages.
I guess I assumed the statement was clear when it really wasn't. So
let me clarify:
Bill uploads package a-i686.
Bill, in the act of uploading it, says "well this works for me". It's
an implicit signoff and the way we have always worked - the act of
uploading a package is an implicit agreement that it is in working
order. No one tests a package, says "wow this is broken" and uploads
Now, when John signs off for i686, that's two people who have said
"hey this is working". However, a-x86_64 has not been signed off for.
In fact, bill never uploaded that package so couldn't possibly sign
off for it. Alternatively, Bill used my machine to build the package
but does not have a box to test it on. As such, 2 people are needed to
test/signoff for x86_64.
So, in actuality, I intended a total of 4 signoffs, but including the
I don't really get where the idea that the original person who
uploaded the package isn't responsible for it comes from? The whole
point of the sign off thing is to say "we are the ones responsible for
How about this: In the email sent out for having a package signed off,
you explicitly list yourself as signed off on a given architecture
that you actually tested the package on. Is there a problem with this?
arch-dev-public mailing list
12-03-2007, 01:29 AM
i assumed the signoffs as you described them now again. no problem
there. instead of just having one dev behind a pkg.tar.gz file
granting its "working" state, signoffs double this, so that 2 devs
are behind every pkg.tar.gz
Monday 03 December 2007, Aaron Griffin wrote:
| How about this: In the email sent out for having a package signed
| off, you explicitly list yourself as signed off on a given
| architecture that you actually tested the package on. Is there a
| problem with this?
for the process itself, yes, it would be better to have also the
builder of a pkg on an arch to sign off explicitelly.
regarding signing off a pkg, i have a general comment. now it is
happening on the mailinglist. once the new web-frontend of official
repos is updated to include multiple devs per pkg and also per arch,
the singing (signing) can take place also on the website in a
list-like thing (ajax or similar to the todo-lists), ideally once 2
or more devs did sing, the possibility would be to move the pkg out
of testing automatically (e.g. by pressing a button). once this is
working and the process has low ammount of overhead doing it, we can
do the singing even in extra and unstable.