Brad Fanella wrote:

On Sun, Oct 03, 2010 at 07:54:42PM +0200, Jakob Gruber wrote:

...

Hi TUs,

I've just created a new proposal concerning the orphaning of all packages marked 'out of date' which have not been updated (or submitted) since before January 1st, 2009. For details, see the actual proposal text.

The voting period ends on October 10th, please cast your votes!

schuay

Yeah, as long as they haven't been updated for a while (as you said, January 1st, 2009), then I'm all for it!

Thanks, Brad

I've cast a "yes" vote. I also move to name this "Operation Oliver Twist" and to name the orphaning script "twister". One problem that might arise though is if a stable package (i.e. one that almost never gets updated upstream) has been recently flagged out-of-date then it might get orphaned (a malicious user who is aware of the impending operation might even write a script to flag such packages out-of-date). Perhaps you could cross-reference the last activity of the maintainer when deciding whether to delete a package, e.g. last package action <= 2009-01-01 and last maintainer action <= xxxx-xx-xx. That shouldn't add much complexity to the code but it might improve the handling of a few fringe cases. I'm really just floating the idea though. Regards, Xyne

On Sun, Oct 03, 2010 at 10:03:25PM +0300, Konstantinos Karantias wrote:

I'm not a TU, but I don't agree. Package sources may not be updated by then, so the packages doesn't actually need any modifications.

In my opinion, you should examine every package in detail before deleting it.

(In other words, I agree with Xyne :P)

On Sun, Oct 3, 2010 at 9:57 PM, Xyne wrote:

...

Brad Fanella wrote:

...

...

Hi TUs,

I've just created a new proposal concerning the orphaning of all

On Sun, Oct 03, 2010 at 07:54:42PM +0200, Jakob Gruber wrote: packages

...

marked 'out of date' which have not been updated (or submitted) since before January 1st, 2009. For details, see the actual proposal text.

The voting period ends on October 10th, please cast your votes!

schuay

Yeah, as long as they haven't been updated for a while (as you said, January 1st, 2009), then I'm all for it!

Thanks, Brad

I've cast a "yes" vote. I also move to name this "Operation Oliver Twist" and to name the orphaning script "twister".

One problem that might arise though is if a stable package (i.e. one that almost never gets updated upstream) has been recently flagged out-of-date then it might get orphaned (a malicious user who is aware of the impending operation might even write a script to flag such packages out-of-date). Perhaps you could cross-reference the last activity of the maintainer when deciding whether to delete a package, e.g. last package action <= 2009-01-01 and last maintainer action <= xxxx-xx-xx.

That shouldn't add much complexity to the code but it might improve the handling of a few fringe cases. I'm really just floating the idea though.

Regards, Xyne

That is a valid point. The real question: Is it worth the risk? In my opinion, it is. -- Brad

But also, orphaning all the packages that fit into this category is unsure. Some people may have orphaned the for fun or something. It has happened to me many times. On Sun, Oct 3, 2010 at 9:33 PM, Brad Fanella wrote:

...

I'm not a TU, but I don't agree. Package sources may not be updated by

...

so the packages doesn't actually need any modifications.

In my opinion, you should examine every package in detail before deleting it.

(In other words, I agree with Xyne :P)

On Sun, Oct 3, 2010 at 9:57 PM, Xyne wrote:

...

Brad Fanella wrote:

...

...

Hi TUs,

I've just created a new proposal concerning the orphaning of all

On Sun, Oct 03, 2010 at 07:54:42PM +0200, Jakob Gruber wrote: packages

...

marked 'out of date' which have not been updated (or submitted) since before January 1st, 2009. For details, see the actual proposal text.

The voting period ends on October 10th, please cast your votes!

schuay

Yeah, as long as they haven't been updated for a while (as you said, January 1st, 2009), then I'm all for it!

Thanks, Brad

I've cast a "yes" vote. I also move to name this "Operation Oliver Twist" and to name the orphaning script "twister".

One problem that might arise though is if a stable package (i.e. one

...

...

almost never gets updated upstream) has been recently flagged out-of-date then it might get orphaned (a malicious user who is aware of the impending operation might even write a script to flag such packages out-of-date). Perhaps you could cross-reference the last activity of the maintainer when deciding whether to delete a package, e.g. last package action <= 2009-01-01 and last maintainer action <= xxxx-xx-xx.

That shouldn't add much complexity to the code but it might improve the handling of a few fringe cases. I'm really just floating the idea

On Sun, Oct 03, 2010 at 10:03:25PM +0300, Konstantinos Karantias wrote: then, that though.

...

...

Regards, Xyne

Also, I know this was only mentioned on the TU voting page, but there are currently 525 packages that are out of date that fit into this category.

Checking/orphaning all of them by hand wouldn't be practical.

-- Brad

-- Blog: http://www.gtklocker.com/

On 4 October 2010 03:11, Konstantinos Karantias wrote:

But also, orphaning all the packages that fit into this category is unsure.

Some people may have orphaned the for fun or something. It has happened to me many times.

Please post your replies below quotes. Anyway, we cannot mass-orphan them without checking. It is simply not right, no matter the statistics. For example, cutegod [1] is owned by Dragonlord, a TU. He might have his reasons. Like him, many others who are not TUs might have their reasons. Anyway, I consider this more of a TODO. [1] http://aur.archlinux.org/packages.php?ID=14119

On 4 October 2010 02:51, Brad Fanella wrote:

Well, in most cases, they are flagged out of date for a good reason.

For example, cutegod no longer has a project page up nor is the actual source available.

How 'bout someone writes up something nice such as the "Python 2.7/3.1 package list" on the Dev interface?

Yes, for a majority I suppose that holds true. And here's another minority: psychosynth [1] I own it and it's outdated because upstream has not provided build-related response, so kindly remove it from the list. [1] http://aur.archlinux.org/packages.php?ID=16898

On Sun, Oct 3, 2010 at 10:18 PM, Ray Rashif wrote:

On 4 October 2010 03:11, Konstantinos Karantias wrote:

...

But also, orphaning all the packages that fit into this category is unsure.

Some people may have orphaned the for fun or something. It has happened to me many times.

Please post your replies below quotes.

Anyway, we cannot mass-orphan them without checking. It is simply not right, no matter the statistics. For example, cutegod [1] is owned by Dragonlord, a TU. He might have his reasons. Like him, many others who are not TUs might have their reasons.

Anyway, I consider this more of a TODO.

[1] http://aur.archlinux.org/packages.php?ID=14119

Well, I can't get into TU's farms, it's a difficult process, but I wish them good luck with the work they're going to do, I believe in them. :) Be sure to not screw up anything guys! :) -- Blog: http://www.gtklocker.com/

On 4 October 2010 04:32, Jakob Gruber wrote:

 On 10/03/2010 08:57 PM, Xyne wrote:

...

I've cast a "yes" vote. I also move to name this "Operation Oliver Twist" and to name the orphaning script "twister".

One problem that might arise though is if a stable package (i.e. one that almost never gets updated upstream) has been recently flagged out-of-date then it might get orphaned (a malicious user who is aware of the impending operation might even write a script to flag such packages out-of-date). Perhaps you could cross-reference the last activity of the maintainer when deciding whether to delete a package, e.g. last package action<= 2009-01-01 and last maintainer action<= xxxx-xx-xx.

That shouldn't add much complexity to the code but it might improve the handling of a few fringe cases. I'm really just floating the idea though.

Regards, Xyne

Sounds good. After adding the 'last maintainer action <= 2009-01-01' criteria, the list still contains 335 packages. Keep in mind this list is generated from a DB dump (which is roughly  2 weeks old) so it might not be 100% up to date.

http://pastebin.com/e5qJxBUs

OK, this is _much_ better and can be mass-orphaned. Good job, voted now.

On 10/03/10 16:05, Ray Rashif wrote:

On 4 October 2010 01:54, Jakob Gruber wrote:

...

Hi TUs,

I've just created a new proposal concerning the orphaning of all packages marked 'out of date' which have not been updated (or submitted) since before January 1st, 2009. For details, see the actual proposal text.

The voting period ends on October 10th, please cast your votes!

Jakob, would it be possible for you to parse the e-mail address of the current maintainer, and for each package send an e-mail? The template could look like this:

""" Subject: [AUR][$pkgname] Orphan candidate

Hi

Your package '$pkgname' [1] is a candidate to be orphaned, as per the out-of-date and inactivity list generated recently [2]. If you do not update '$pkgname' by the 10th of October 2010, it will be automatically orphaned. ...

maybe just something like, "If you wish to continue maintaining it and are able to do so, please re-adopt and update it or state why this cannot be done?" ...Orphaning generally isn't a very harmful act. And/or we could go by the one-by-one orphaning principle of giving maintainers a couple weeks to respond to email. It's likely many of these maintainers won't respond because they've been inactive on AUR for a year and a half; and if they do respond, it's evidence that they're active enough to warrant a not-so-automatic process perhaps? (So the critical date of orphaning then should/would probably be later than 10th October.) -Isaac

On 4 October 2010 04:51, Isaac Dupree wrote:

On 10/03/10 16:05, Ray Rashif wrote:

...

On 4 October 2010 01:54, Jakob Gruber  wrote:

...

 Hi TUs,

I've just created a new proposal concerning the orphaning of all packages marked 'out of date' which have not been updated (or submitted) since before January 1st, 2009. For details, see the actual proposal text.

The voting period ends on October 10th, please cast your votes!

Jakob, would it be possible for you to parse the e-mail address of the current maintainer, and for each package send an e-mail? The template could look like this:

""" Subject: [AUR][$pkgname] Orphan candidate

Hi

Your package '$pkgname' [1] is a candidate to be orphaned, as per the out-of-date and inactivity list generated recently [2]. If you do not update '$pkgname' by the 10th of October 2010, it will be automatically orphaned. ...

maybe just something like, "If you wish to continue maintaining it and are able to do so, please re-adopt and update it or state why this cannot be done?"

...Orphaning generally isn't a very harmful act.

And/or we could go by the one-by-one orphaning principle of giving maintainers a couple weeks to respond to email.  It's likely many of these maintainers won't respond because they've been inactive on AUR for a year and a half; and if they do respond, it's evidence that they're active enough to warrant a not-so-automatic process perhaps?

(So the critical date of orphaning then should/would probably be later than 10th October.)

The latest list Jakob generated (also thanks to Xyne's prompt response) deals with this safely. We don't need to care or waste time with packages whose maintainers have disappeared for more than a year, almost 2 years.

On Sun, Oct 3, 2010 at 8:42 PM, Loui Chang wrote:

On Sun 03 Oct 2010 19:54 +0200, Jakob Gruber wrote:

...

I've just created a new proposal concerning the orphaning of all packages marked 'out of date' which have not been updated (or submitted) since before January 1st, 2009. For details, see the actual proposal text.

The voting period ends on October 10th, please cast your votes!

I think that you forgot the discussion period for this proposal. So I believe that you will need to restart a vote after a proper discussion period. Please send the text of the proposal to this list to initiate that discussion.

Many thanks. Sorry for the bureaucracy - but that is how things have been mandated.

I am not sure if it has been mentioned, but the problem would also be that it may be needed by another package as well.

Excerpts from Jos\xe9 Valecillos's message of 2010-10-05 20:37:04 -0400:

On 10/03/2010 01:24 PM, Jakob Gruber wrote:

...

Hi TUs,

I've just created a new proposal concerning the orphaning of all packages marked 'out of date' which have not been updated (or submitted) since before January 1st, 2009. For details, see the actual proposal text.

The voting period ends on October 10th, please cast your votes!

schuay

I propose clean up the orphaned packages as well. There are many packages (about 900) that are orphan and also flaged as out of date. Aur is becoming a cementary of old packages, many people abandon packages that aren't need them anymore, or just have been dropped by their original developers.

One way can be delete all the packages that have been outdated for about a year and have 2 months orphaned. Its a idea, there can be other criteria. But, please consider thoroughly if the packages haven't been updated in one year and have months orphan is very likely that isn't used by anybody.

The old packages serve as a reference for anyone wanting to adopt. If you delete them, people will have to start over from scratch. -- David Campbell

Excerpts from Jeremiah Dodds's message of 2010-10-06 08:53:33 -0400:

On Tue, Oct 5, 2010 at 8:58 PM, David Campbell wrote:

...

The old packages serve as a reference for anyone wanting to adopt. If you delete them, people will have to start over from scratch.

Perhaps a simple searchable-by-name archive of old packages would suffice? Or even just a publicly readable ftp server? It would clear the cruft out, and still allow people to access an old package if they want to renew it or need it for whatever reason.

What matters is not how old the package is, but whether it works or not. There has already been a feature request for the ability to flag packages as broken: FS#18829. -- David Campbell