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 03-13-2010, 01:41 PM
Paul Mattal
 
Default improving signoffs

There's a confluence of circumstances that occurs regularly now that is
wasting lots of time for those trying to squash bugs:


1) It's really hard to get signoffs for core packages. It usually takes
at least a week, and an extra bump, and coaxing. The process isn't
fire-and-forget, so I have to spend time each day thinking about
packages I currently have awaiting signoffs and what has happened to
them and whether or not I need to take some action.


2) Signoff threads are hijacked for a general discussion about the
package. This is annoying because it happens AFTER the developer has
done all the work teeing up the new package, testing it himself on both
environments, writing up the signoff, doing the coaxing, watching the
signoff thread. Once the thread is hijacked, it becomes even more
difficult for those who would sign off to figure out the state of the
signoff.


All this has the effect of filibustering progress in core and
discouraging people from doing work on core packages.


There are a number of potential solutions to this problem-- perhaps some
of you will think of others. Here are two that come to mind:


1) Get a web signoff mechanism to really work for us. We'd have to
evaluate why the previous web mechanism wasn't embraced and solve the
problems with it. This would require some more work in archweb, which I
could probably do if we thought it was the right approach.


2) A pre-signoff thread for each signoff. You run this thread before you
do any packaging work, so that if someone wants to discuss other things
about the package and suggest other modifications, they do it without
causing you a whole lot of extra work. We then agree not to hijack
signoff threads for unrelated aspects of the package-- rather, we start
other threads or open new bug reports.


What do others think? Any other ideas for how to handle this?

- P
 
Old 03-13-2010, 09:21 PM
Eric Bélanger
 
Default improving signoffs

On Sat, Mar 13, 2010 at 9:41 AM, Paul Mattal <paul@mattal.com> wrote:
> There's a confluence of circumstances that occurs regularly now that is
> wasting lots of time for those trying to squash bugs:
>
> 1) It's really hard to get signoffs for core packages. It usually takes at
> least a week, and an extra bump, and coaxing. The process isn't
> fire-and-forget, so I have to spend time each day thinking about packages I
> currently have awaiting signoffs and what has happened to them and whether
> or not I need to take some action.
>
> 2) Signoff threads are hijacked for a general discussion about the package.
> This is annoying because it happens AFTER the developer has done all the
> work teeing up the new package, testing it himself on both environments,
> writing up the signoff, doing the coaxing, watching the signoff thread. Once
> the thread is hijacked, it becomes even more difficult for those who would
> sign off to figure out the state of the signoff.
>
> All this has the effect of filibustering progress in core and discouraging
> people from doing work on core packages.
>
> There are a number of potential solutions to this problem-- perhaps some of
> you will think of others. Here are two that come to mind:
>
> 1) Get a web signoff mechanism to really work for us. We'd have to evaluate
> why the previous web mechanism wasn't embraced and solve the problems with
> it. This would require some more work in archweb, which I could probably do
> if we thought it was the right approach.

Problems with the current web signoff (some might be in bug tracker):

- notification. There should be a text box where you write the package
modifications then click on a button. That would send an automatic
signoff message (standard blurb with text box contents) to the dev
public (or aur in case of community packages) ML to inform devs about
the pending signoff and package changes.

- currently there is no way to flag a package as broken on the web signoff.

- you can't unsign-off a package. In the case you sign-off the wrong
package by accident or notice a problem after signing-off, you can't
revert it.

- the packages are ordered alphabetically so core packages are mixed
up with extra and community packages. We should be able to sort by
repo.

- sometime you want to add extra information when signing off, like
what on what setup you tested, what part of the package you tested or
on how in-depth you tested. A short text box on the signoff page might
be useful.

- users signoff. Some low-usage packages benefit from users signoff.
Maybe we could add a feature where a dev could enter a user name
and/or email and signoff for a user.


>
> 2) A pre-signoff thread for each signoff. You run this thread before you do
> any packaging work, so that if someone wants to discuss other things about
> the package and suggest other modifications, they do it without causing you
> a whole lot of extra work. We then agree not to hijack signoff threads for
> unrelated aspects of the package-- rather, we start other threads or open
> new bug reports.

That would be a good idea. This way the package will be done right the
first time.

>
> What do others think? Any other ideas for how to handle this?
>
> - P
>
 
Old 03-13-2010, 10:05 PM
Allan McRae
 
Default improving signoffs

On 14/03/10 08:21, Eric Bélanger wrote:

On Sat, Mar 13, 2010 at 9:41 AM, Paul Mattal<paul@mattal.com> wrote:

There's a confluence of circumstances that occurs regularly now that is
wasting lots of time for those trying to squash bugs:

1) It's really hard to get signoffs for core packages. It usually takes at
least a week, and an extra bump, and coaxing. The process isn't
fire-and-forget, so I have to spend time each day thinking about packages I
currently have awaiting signoffs and what has happened to them and whether
or not I need to take some action.


Didn't we go through this a month or two back? As an aside, paclist
from pacman-contrib is very handy for remembering signoffs. "paclist
testing" shows you the packages you have installed from [testing].



2) Signoff threads are hijacked for a general discussion about the package.
This is annoying because it happens AFTER the developer has done all the
work teeing up the new package, testing it himself on both environments,
writing up the signoff, doing the coaxing, watching the signoff thread. Once
the thread is hijacked, it becomes even more difficult for those who would
sign off to figure out the state of the signoff.

All this has the effect of filibustering progress in core and discouraging
people from doing work on core packages.

There are a number of potential solutions to this problem-- perhaps some of
you will think of others. Here are two that come to mind:

1) Get a web signoff mechanism to really work for us. We'd have to evaluate
why the previous web mechanism wasn't embraced and solve the problems with
it. This would require some more work in archweb, which I could probably do
if we thought it was the right approach.


Problems with the current web signoff (some might be in bug tracker):

- notification. There should be a text box where you write the package
modifications then click on a button. That would send an automatic
signoff message (standard blurb with text box contents) to the dev
public (or aur in case of community packages) ML to inform devs about
the pending signoff and package changes.

- currently there is no way to flag a package as broken on the web signoff.

- you can't unsign-off a package. In the case you sign-off the wrong
package by accident or notice a problem after signing-off, you can't
revert it.

- the packages are ordered alphabetically so core packages are mixed
up with extra and community packages. We should be able to sort by
repo.

- sometime you want to add extra information when signing off, like
what on what setup you tested, what part of the package you tested or
on how in-depth you tested. A short text box on the signoff page might
be useful.

- users signoff. Some low-usage packages benefit from users signoff.
Maybe we could add a feature where a dev could enter a user name
and/or email and signoff for a user.


The biggest problem I see is that I rarely visit the webpage, whereas I
visit my email inbox several times an hour. So switching to web-base
signoffs requires people to go out of their way and is going to reduce
visibility and require even more chasing people.


How we know a signoff is needed is another interesting issue... The
suggestion is to have the web interface automatically send an email to
the list. But instead of clicking reply, we a required to boot up a web
browser, navigate to the correct page and enter our response there.
That is just tedious.




2) A pre-signoff thread for each signoff. You run this thread before you do
any packaging work, so that if someone wants to discuss other things about
the package and suggest other modifications, they do it without causing you
a whole lot of extra work. We then agree not to hijack signoff threads for
unrelated aspects of the package-- rather, we start other threads or open
new bug reports.


That would be a good idea. This way the package will be done right the
first time.


If you can not get packaging done right first time, do not do it. I
maintain ~40 packages in [core] and there is no way I am going to post a
message asking permission to update them. But if you want to make a big
change that is worthy of discussion then do so.


I agree discussing changes is useless in signoff threads unless they are
regressions. All other requests should go to the bug tracker. And we
should just point people there and move on.


Allan
 
Old 03-13-2010, 10:34 PM
Paul Mattal
 
Default improving signoffs

2) A pre-signoff thread for each signoff. You run this thread before
you do
any packaging work, so that if someone wants to discuss other things
about
the package and suggest other modifications, they do it without
causing you
a whole lot of extra work. We then agree not to hijack signoff
threads for
unrelated aspects of the package-- rather, we start other threads or
open
new bug reports.


That would be a good idea. This way the package will be done right the
first time.


If you can not get packaging done right first time, do not do it. I
maintain ~40 packages in [core] and there is no way I am going to post a
message asking permission to update them. But if you want to make a big
change that is worthy of discussion then do so.

I agree discussing changes is useless in signoff threads unless they are
regressions. All other requests should go to the bug tracker. And we
should just point people there and move on.


I'm not talking about mistakes. Those would be regressions, or mistakes
in the way the new functionality has been implemented.


I'm talking about the fact that I cleaned up X and now someone noticed
Y, or I did Z and someone now thinks we should do Z' and Z'.


Signoffs are supposed to keep us from messing up, not allow some to
avoid doing work by making others of us do it by holding signoffs ransom
for extra things they'd like to see implemented.


- P
 

Thread Tools




All times are GMT. The time now is 01:12 AM.

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