[arch-dev-public] reverse staging idea - Arch-dev-public - lists.archlinux.org

newer
[arch-dev-public] DB rebuilds

[arch-dev-public] reverse staging idea

older
[arch-dev-public] Away for a...

Paul Mattal

18 Jun 2007 18 Jun '07

4:44 p.m.

Since I know there have been complaints about packages remaining in the ftp directories when new ones are uploaded, how about we modify the /arch/db-* update scripts run by the devs to move old versions of updated packages into ~/staging/<repo>/old? This makes the default behavior that they stick around but aren't cluttering the ftp directory. Just an idea I had that I didn't want us to lose. - P

Show replies by date

Dale Blount

18 Jun 18 Jun

4:51 p.m.

On Mon, 2007-06-18 at 10:44 -0400, Paul Mattal wrote:

Since I know there have been complaints about packages remaining in the ftp directories when new ones are uploaded, how about we modify the /arch/db-* update scripts run by the devs to move old versions of updated packages into ~/staging/<repo>/old?

How about an "old" directory stored somewhere on the filesystem accessible by everyone? (incase the update broke something and the maintainer isn't around to restore).

This makes the default behavior that they stick around but aren't cluttering the ftp directory.

Just an idea I had that I didn't want us to lose.

Sounds good to me. Dale

Dan McGee

5:10 p.m.

On 6/18/07, Dale Blount wrote:

On Mon, 2007-06-18 at 10:44 -0400, Paul Mattal wrote:

...
Since I know there have been complaints about packages remaining in the ftp directories when new ones are uploaded, how about we modify the /arch/db-* update scripts run by the devs to move old versions of updated packages into ~/staging/<repo>/old?

How about an "old" directory stored somewhere on the filesystem accessible by everyone? (incase the update broke something and the maintainer isn't around to restore).

+1 for it to be a public old directory, as long as people still clean it out once in a while.

...
This makes the default behavior that they stick around but aren't cluttering the ftp directory.

Just an idea I had that I didn't want us to lose.

Sounds good to me.

Dale Blount

5:11 p.m.

On Mon, 2007-06-18 at 11:10 -0400, Dan McGee wrote:

On 6/18/07, Dale Blount wrote:

...
On Mon, 2007-06-18 at 10:44 -0400, Paul Mattal wrote:

...
Since I know there have been complaints about packages remaining in the ftp directories when new ones are uploaded, how about we modify the /arch/db-* update scripts run by the devs to move old versions of updated packages into ~/staging/<repo>/old?

How about an "old" directory stored somewhere on the filesystem accessible by everyone? (incase the update broke something and the maintainer isn't around to restore).

+1 for it to be a public old directory, as long as people still clean it out once in a while.

I was thinking a daily cron that removed files last modified more than a month ago. Dale

Jason Chu

7:44 p.m.

On Mon, Jun 18, 2007 at 11:11:26AM -0400, Dale Blount wrote:

On Mon, 2007-06-18 at 11:10 -0400, Dan McGee wrote:

...
On 6/18/07, Dale Blount wrote:

...
On Mon, 2007-06-18 at 10:44 -0400, Paul Mattal wrote:

...
Since I know there have been complaints about packages remaining in the ftp directories when new ones are uploaded, how about we modify the /arch/db-* update scripts run by the devs to move old versions of updated packages into ~/staging/<repo>/old?

How about an "old" directory stored somewhere on the filesystem accessible by everyone? (incase the update broke something and the maintainer isn't around to restore).

+1 for it to be a public old directory, as long as people still clean it out once in a while.

I was thinking a daily cron that removed files last modified more than a month ago.

Is it really safe to say that all packages are updated within a month? I know I haven't updated lots of my packages in more than a month (because they haven't had any updates!). Jason

Dan McGee

7:51 p.m.

On 6/18/07, Jason Chu wrote:

On Mon, Jun 18, 2007 at 11:11:26AM -0400, Dale Blount wrote:

...
On Mon, 2007-06-18 at 11:10 -0400, Dan McGee wrote:

...
On 6/18/07, Dale Blount wrote:

...
On Mon, 2007-06-18 at 10:44 -0400, Paul Mattal wrote:

...
Since I know there have been complaints about packages remaining in the ftp directories when new ones are uploaded, how about we modify the /arch/db-* update scripts run by the devs to move old versions of updated packages into ~/staging/<repo>/old?

How about an "old" directory stored somewhere on the filesystem accessible by everyone? (incase the update broke something and the maintainer isn't around to restore).

+1 for it to be a public old directory, as long as people still clean it out once in a while.

I was thinking a daily cron that removed files last modified more than a month ago.

Is it really safe to say that all packages are updated within a month? I know I haven't updated lots of my packages in more than a month (because they haven't had any updates!).

This is something that cleans them out of the old/ directory only, where they are automatically moved to after you run one of the /arch/db-* scripts, I assume. So this will have no direct effect on the ftp directories. -Dan

Jason Chu

8:01 p.m.

On Mon, Jun 18, 2007 at 01:51:14PM -0400, Dan McGee wrote:

On 6/18/07, Jason Chu wrote:

...
On Mon, Jun 18, 2007 at 11:11:26AM -0400, Dale Blount wrote:

...
On Mon, 2007-06-18 at 11:10 -0400, Dan McGee wrote:

...
On 6/18/07, Dale Blount wrote:

...
On Mon, 2007-06-18 at 10:44 -0400, Paul Mattal wrote:

...
Since I know there have been complaints about packages remaining in the ftp directories when new ones are uploaded, how about we modify the /arch/db-* update scripts run by the devs to move old versions of updated packages into ~/staging/<repo>/old?

How about an "old" directory stored somewhere on the filesystem accessible by everyone? (incase the update broke something and the maintainer isn't around to restore).

+1 for it to be a public old directory, as long as people still clean it out once in a while.

I was thinking a daily cron that removed files last modified more than a month ago.

Is it really safe to say that all packages are updated within a month? I know I haven't updated lots of my packages in more than a month (because they haven't had any updates!).

This is something that cleans them out of the old/ directory only, where they are automatically moved to after you run one of the /arch/db-* scripts, I assume. So this will have no direct effect on the ftp directories.

Ah, ok. That makes sense then. Jason

Dale Blount

7:52 p.m.

Is it really safe to say that all packages are updated within a month? I know I haven't updated lots of my packages in more than a month (because they haven't had any updates!).

I'd say the live package is pretty safe if it hasn't been rolled-back within a month... Isn't that the only reason we keep old packages around at times? Dale

Thomas Bächler

5:23 p.m.

Dale Blount schrieb:

...
Since I know there have been complaints about packages remaining in the ftp directories when new ones are uploaded, how about we modify the /arch/db-* update scripts run by the devs to move old versions of updated packages into ~/staging/<repo>/old?

How about an "old" directory stored somewhere on the filesystem accessible by everyone? (incase the update broke something and the maintainer isn't around to restore).

+1, but outside the ftp directory. Also +1 on the cronjob idea.

Tom K

8:29 p.m.

Thomas Bächler wrote:

Dale Blount schrieb:

...
...
Since I know there have been complaints about packages remaining in the ftp directories when new ones are uploaded, how about we modify the /arch/db-* update scripts run by the devs to move old versions of updated packages into ~/staging/<repo>/old?

How about an "old" directory stored somewhere on the filesystem accessible by everyone? (incase the update broke something and the maintainer isn't around to restore).

+1, but outside the ftp directory. Also +1 on the cronjob idea.

Yeah, that works for me too.

6162

Age (days ago)

6162

Last active (days ago)

Download

9 comments

6 participants

tags

participants (6)

Dale Blount
Dan McGee
Jason Chu
Paul Mattal
Thomas Bächler
Tom K