Re: [HACKERS] More nuclear options

2006-07-11 Thread Joshua D. Drake
> Again, it's the same question. If *you* want to be the maintainer, I'll > put it on pgfoundry. Otherwise, you're asking me to be responsible for > the code because you don't want to throw it away. Josh, How about a general call for maintainers? Post it to general, hackers and advocacy (mayb

Re: [HACKERS] More nuclear options

2006-07-11 Thread Christopher Kings-Lynne
I've already added adddepends to pgFoundry (as "Old PG Upgrade"), since people spoke up for it. I will assign one of them as admin of the project (not sure who yet). How is addepends in any way "old pg upgrade"?? ---(end of broadcast)--- TIP 5:

Re: [HACKERS] More nuclear options

2006-07-11 Thread Robert Treat
On Tuesday 11 July 2006 15:53, Josh Berkus wrote: >I'll grant that tips > > doesn't look like much more than an article stub... it should probably be > > moved to the new techdocs rather than pgfoundry. > > That was what I started to do. Unfortunately, the README is > instrucitons for some SQL

Re: [HACKERS] More nuclear options

2006-07-11 Thread Joshua D. Drake
> Given the current number of projects that have no code / files / anything > associated with them on pgfoundry/gborg right now, this argument rings a > little hollow. I would say that: > Given the current number of projects that have no code / files / anything > associated with them on pgfoundr

Re: [HACKERS] More nuclear options

2006-07-11 Thread Hannu Krosing
Ühel kenal päeval, T, 2006-07-11 kell 14:05, kirjutas Josh Berkus: > Robert, > > > Given the current number of projects that have no code / files / anything > > associated with them on pgfoundry/gborg right now, this argument rings a > > little hollow. > > If you're so keen to add to the probl

Re: [HACKERS] More nuclear options

2006-07-11 Thread Robert Treat
On Tuesday 11 July 2006 16:33, Josh Berkus wrote: > Robert, > > > I really don't see how this will actually cause you any extra effort, but > > if you want to plug my name on there after you move it, that's fine with > > me. > > I meant "maintain" it, not just leave it there to age like a bad chees

Re: [HACKERS] More nuclear options

2006-07-11 Thread Josh Berkus
Robert, I really don't see how this will actually cause you any extra effort, but if you want to plug my name on there after you move it, that's fine with me. I meant "maintain" it, not just leave it there to age like a bad cheese. If it's going to be dead code, it can do so in the FTP /o

Re: [HACKERS] More nuclear options

2006-07-11 Thread mark
On Tue, Jul 11, 2006 at 03:53:26PM -0400, Josh Berkus wrote: > >All I am saying is that it couldn't hurt to put the information out > >there... we're not hurting for disk space and none of this stuff appears > >inherently wrong, just outdated, but it might still prove useful for some > >people

Re: [HACKERS] More nuclear options

2006-07-11 Thread Josh Berkus
Robert, No need to fly off the handle there Josh. I was hoping that you'd take me up on it in a rash moment. No code, or no active code development? No code was the rule we discussed. Other stuff would be a matter for discussion. The idea was that pgfoundry was supposed to be confined

Re: [HACKERS] More nuclear options

2006-07-11 Thread Robert Treat
On Tuesday 11 July 2006 14:05, Josh Berkus wrote: > Robert, > > > Given the current number of projects that have no code / files / anything > > associated with them on pgfoundry/gborg right now, this argument rings a > > little hollow. > > If you're so keen to add to the problem, you can have my sp

Re: [HACKERS] More nuclear options

2006-07-11 Thread Merlin Moncure
On 7/10/06, Josh Berkus wrote: All, userlock (Merlin) Ok, I will update the project description and maintain it. userlock is a great feature, and I tried contacting the original author to get him to relicense the project but could never get a hold of him. To be honest, the current us

Re: [HACKERS] More nuclear options

2006-07-11 Thread Robert Treat
On Tuesday 11 July 2006 12:55, Josh Berkus wrote: > Robert, > > > To be honest I don't know why people are against throwing the code on > > pgfoundry with a hefty readme saying that the code is unmaintained and > > what it's build status is on various versions > > ... because we don't want to litte

Re: [HACKERS] More nuclear options

2006-07-11 Thread Josh Berkus
Robert, Given the current number of projects that have no code / files / anything associated with them on pgfoundry/gborg right now, this argument rings a little hollow. If you're so keen to add to the problem, you can have my spot as pgfoundry admin. Otherwise, the rule that the pgfoundr

Re: [HACKERS] More nuclear options

2006-07-11 Thread Josh Berkus
Robert, To be honest I don't know why people are against throwing the code on pgfoundry with a hefty readme saying that the code is unmaintained and what it's build status is on various versions ... because we don't want to litter pgFoundry with dead, broken projects which nobody uses and wh

Re: [HACKERS] More nuclear options

2006-07-11 Thread Steve Singer
On Mon, 10 Jul 2006, Josh Berkus wrote: To be migrated to pgFoundry: dbmirror (need owner) I'll volunteer for this if no one else steps forward. I'm not planning on making any significant chances to dbmirror at this point stage but I can look after for the pgfoundry project.

Re: [HACKERS] More nuclear options

2006-07-11 Thread Robert Treat
On Monday 10 July 2006 17:06, Josh Berkus wrote: > All, > > At the request of Dave Page, here's the semi-final list after looking at > the code: > > To be killed: > adddepends > tips > mSQL-interface > To be honest I don't know why people are against throwing the code on pgfound

Re: [HACKERS] More nuclear options

2006-07-10 Thread Josh Berkus
All, At the request of Dave Page, here's the semi-final list after looking at the code: To be killed: adddepends tips mSQL-interface To be migrated to pgFoundry: dbmirror (need owner) dbase (owner?) fulltextindex (owner?) mac (LER)

Re: [HACKERS] More nuclear options

2006-07-10 Thread Bruce Momjian
Josh Berkus wrote: > Folks, > > I was looking at migrating mSQL-interface to pgFoundry, but I'm not sure > there's any reason to do so. It was never finished, doesn't build, and > it's not like I run across mSQL databases in the field. Does anyone? > > Shall we just kill it? > > Also, "tips"