On Mon, Jan 05, 2009 at 06:06:03PM +0100, Mathias Burén wrote:

Agreed, but two months? Isn't that a bit too long? One month is good enough in my opinion.

A month would be alright. I'd prefer two weeks though. Hah! I'd like to avoid using a cron job to do this. Any ideas or patches for such an implementation are welcome at aur-dev@archlinux.org Cheers!

Ronald van Haren wrote:

On 1/5/09, Loui Chang wrote:

...

On Mon, Jan 05, 2009 at 06:06:03PM +0100, Mathias Burén wrote:

...

Agreed, but two months? Isn't that a bit too long? One month is good enough in my opinion.

A month would be alright. I'd prefer two weeks though. Hah! I'd like to avoid using a cron job to do this. Any ideas or patches for such an implementation are welcome at aur-dev@archlinux.org

Cheers!

You know a typical holiday takes longer than two weeks (well, mine at least). So I'm against anything shorter than 1 month, which IMO is maybe already a bit short.

There may also be instances that packages are wrongly flagged out of date, or packages can't be updated for some reasons. How do you want to implement these?

Ronald

I agree that this is generally a good idea, although two weeks does seem a bit short (especially around the holidays). As for instances where a package can't be updated, perhaps a new flag could be implemented for these situations? I've had a few of those situations myself and they can be frustrating, so I suggest the possible addition of a "pending update" flag or similar. Something that could give the maintainer the ability to mark a package in such a way as to notify the community that although the package is not functional, it is being looked into. Additionally, it could potentially lock out the ability to flag the package out-of-date to prevent packages in situations like this from being auto-orphaned if the discussed auto-orphan idea is implemented. Thoughts? -- Your Fortune... --------------- I'm encased in the lining of a pure pork sausage!!

Le Mon, 05 Jan 2009 18:11:42 -0500, Ghost1227 a écrit :

I agree that this is generally a good idea, although two weeks does seem a bit short (especially around the holidays). As for instances where a package can't be updated, perhaps a new flag could be implemented for these situations? I've had a few of those situations myself and they can be frustrating, so I suggest the possible addition of a "pending update" flag or similar. Something that could give the maintainer the ability to mark a package in such a way as to notify the community that although the package is not functional, it is being looked into. Additionally, it could potentially lock out the ability to flag the package out-of-date to prevent packages in situations like this from being auto-orphaned if the discussed auto-orphan idea is implemented. Thoughts?

Let's not add too much complexity to the AUR is what I think. I'm for auto-orphan after a month, vacations are usally not that long, and even if that's the case, one month without an update is too long. What I would like to see is a "broken" flag and/or the possibility for the maintainer of the package to be notified by email of any comment on one of his packages (a bit like with flyspray). I often don't see comments on my packages saying that they don't build anymore because they were broken by another package's update. -- catwell