On Dec 30, 2007 11:37 PM, Paul Mattal wrote:

1) the package y maintainer(s) notices package x in testing and rebuilds package y

2) the package x maintainer(s) is responsible to find all packages y and rebuilds all such packages y against the new package x

There's a middle-ground here which I like, myself. 1.5) the package x maintainer(s) is responsible to find all packages y and posts a todo list on the dashboard I like this method, but at the same time, it requires one to constantly scan the todo lists to see if a package of yours is there. Do we have any other options, or is it just there 2 (3) ? I'd prefer to go with "easiest" in these cases, because some of these rebuilds can be big.

On Jan 4, 2008 9:18 AM, Paul Mattal wrote:

Aaron Griffin wrote:

...

On Dec 30, 2007 11:37 PM, Paul Mattal wrote:

...

1) the package y maintainer(s) notices package x in testing and rebuilds package y

2) the package x maintainer(s) is responsible to find all packages y and rebuilds all such packages y against the new package x

There's a middle-ground here which I like, myself. 1.5) the package x maintainer(s) is responsible to find all packages y and posts a todo list on the dashboard

I like this method, but at the same time, it requires one to constantly scan the todo lists to see if a package of yours is there.

A slight variation on this is to the todo list + what Damir did.. post to a todo list and *also* put a post on the arch-dev-public list. This way people get push notification, and also a place to track what they've done and what they haven't.

I like this one. So ok, let me propose this: With rebuilds, it's the library maintainer's job to find all dep packages. There are then two choices: * build everything yourself, if you feel like it (yay!) * make a todolist and post on the arch-dev-public ML so we know that there is a new rebuild todolist. Sound like a good process?

On Fri, Jan 04, 2008 at 01:36:03PM -0600, Aaron Griffin wrote:

On Jan 4, 2008 9:18 AM, Paul Mattal wrote:

...

Aaron Griffin wrote:

...

On Dec 30, 2007 11:37 PM, Paul Mattal wrote:

...

1) the package y maintainer(s) notices package x in testing and rebuilds package y

2) the package x maintainer(s) is responsible to find all packages y and rebuilds all such packages y against the new package x

There's a middle-ground here which I like, myself. 1.5) the package x maintainer(s) is responsible to find all packages y and posts a todo list on the dashboard

I like this method, but at the same time, it requires one to constantly scan the todo lists to see if a package of yours is there.

A slight variation on this is to the todo list + what Damir did.. post to a todo list and *also* put a post on the arch-dev-public list. This way people get push notification, and also a place to track what they've done and what they haven't.

I like this one.

So ok, let me propose this: With rebuilds, it's the library maintainer's job to find all dep packages. There are then two choices: * build everything yourself, if you feel like it (yay!) * make a todolist and post on the arch-dev-public ML so we know that there is a new rebuild todolist.

Sound like a good process?

+1 Jason

On Jan 5, 2008 1:06 AM, Aaron Griffin wrote:

So ok, let me propose this: With rebuilds, it's the library maintainer's job to find all dep packages. There are then two choices: * build everything yourself, if you feel like it (yay!) * make a todolist and post on the arch-dev-public ML so we know that there is a new rebuild todolist.

Sound like a good process?

+1

Paul Mattal wrote:

Aaron Griffin wrote:

...

On Jan 4, 2008 9:18 AM, Paul Mattal wrote:

...

...

On Dec 30, 2007 11:37 PM, Paul Mattal wrote:

...

1) the package y maintainer(s) notices package x in testing and rebuilds package y

2) the package x maintainer(s) is responsible to find all packages y and rebuilds all such packages y against the new package x There's a middle-ground here which I like, myself. 1.5) the package x maintainer(s) is responsible to find all packages y and posts a todo list on the dashboard

I like this method, but at the same time, it requires one to constantly scan the todo lists to see if a package of yours is there. A slight variation on this is to the todo list + what Damir did..

Aaron Griffin wrote: post to a todo list and *also* put a post on the arch-dev-public list. This way people get push notification, and also a place to track what they've done and what they haven't.

I like this one.

So ok, let me propose this: With rebuilds, it's the library maintainer's job to find all dep packages. There are then two choices: * build everything yourself, if you feel like it (yay!) * make a todolist and post on the arch-dev-public ML so we know that there is a new rebuild todolist.

Sounds good. Put the package list, with the following observations:

* if you decide to build everything yourself, think about that first and want to take that responsibility; releasing is more than just rebuilding, and by rebuilding you potentially break something and thereby take on responsibility to fix it in relatively short order (even if it's just in testing) * generally make sure the emailed todo list actually contains the list of packages, or at minimum a direct link to the todo list; it gives people no excuse not to notice

I'm hesitant to suggest this, as I'm not able to actually make it happen, but could the addition of a package to a to-do list trigger the same automated-mail thing that is currently used for out-of-date flags? That would make option two a single task: make a to-do list. T.

Aaron Griffin wrote:

On Jan 4, 2008 4:22 PM, Tom K wrote:

...

I'm hesitant to suggest this, as I'm not able to actually make it happen, but could the addition of a package to a to-do list trigger the same automated-mail thing that is currently used for out-of-date flags? That would make option two a single task: make a to-do list.

I was thinking the same - could you add this to the "Internal Dev" section so that we actually remember to do it?

Done - FS#9100