More nuclear options

Started by Josh Berkusalmost 20 years ago19 messageshackers
Jump to latest
#1Josh Berkus
josh@agliodbs.com

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" is an apache log converter for which the source code
appears to be completely missing (?). So barring objections, that one
will get the ol' missle from space too.

--Josh

#2Bruce Momjian
bruce@momjian.us
In reply to: Josh Berkus (#1)
Re: More nuclear options

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" is an apache log converter for which the source code
appears to be completely missing (?). So barring objections, that one
will get the ol' missle from space too.

Ka-boom!

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#3Josh Berkus
josh@agliodbs.com
In reply to: Josh Berkus (#1)
Re: More nuclear options

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)
userlock (Merlin)

--Josh Berkus

#4Robert Treat
xzilla@users.sourceforge.net
In reply to: Josh Berkus (#3)
Re: More nuclear options

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
pgfoundry with a hefty readme saying that the code is unmaintained and what
it's build status is on various versions. This may not seem too useful, but
if someone were to need this code, or we ever hope to get someone to update
it and/or maintain it, thier not going to find it in the contrib modules in
some small corner of the the ftp archive, but they might have a chance of
finding it on pgfoundry.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

#5Steve Singer
steve@ssinger.info
In reply to: Josh Berkus (#3)
Re: More nuclear options

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.

Show quoted text

dbase (owner?)
fulltextindex (owner?)
mac (LER)
userlock (Merlin)

--Josh Berkus

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

#6Josh Berkus
josh@agliodbs.com
In reply to: Robert Treat (#4)
Re: More nuclear options

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 which confuse users and crowd the namespace.
Quality > quantity.

In a year nobody has spoken up for those specific projects. Who's
going to maintain them? Who's going to use them?

--Josh Berkus

#7Robert Treat
xzilla@users.sourceforge.net
In reply to: Josh Berkus (#6)
Re: More nuclear options

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 litter pgFoundry with dead, broken projects
which nobody uses and which confuse users and crowd the namespace.
Quality > quantity.

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.

In a year nobody has spoken up for those specific projects. Who's
going to maintain them? Who's going to use them?

People do get pointed at adddepends even today... certainly no one will do
anything with these projects if you nuke them, but I like giving people
options... your call though.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

#8Josh Berkus
josh@agliodbs.com
In reply to: Robert Treat (#7)
Re: More nuclear options

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 pgfoundry admins agreed on is that if a
project had no code and no activity in 6 months we would contact the
owner, and if no response kill it. That we've been lagging behind on
this is a manpower issue (and to some degree a technical issue with GForge).

People do get pointed at adddepends even today... certainly no one will do
anything with these projects if you nuke them, but I like giving people
options... your call though.

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).

However, in the last year nobody has spoken up for the other three, not
even you.

--Josh

#9Merlin Moncure
mmoncure@gmail.com
In reply to: Josh Berkus (#3)
Re: More nuclear options

On 7/10/06, Josh Berkus <josh@agliodbs.com> 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 userlock contrib module is just very thin wrappers
over backend functions with little/no actual value. I think the user
lock functality really belongs in the core project somehow.

The other proposed features to userlock, namely enhancement to certain
aspects of how they are handled in the backend were largely taken care
of by tom for postgresql 8.1.

By the way, some time back I started another project on gborg,
postisam, but never received permission from my former employer to
release the code. so if that is still there it can be nuked as well.

merlin

#10Robert Treat
xzilla@users.sourceforge.net
In reply to: Josh Berkus (#8)
Re: More nuclear options

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 spot as
pgfoundry admin.

No need to fly off the handle there Josh.

Otherwise, the rule that the pgfoundry admins agreed on is that if a
project had no code and no activity in 6 months we would contact the
owner, and if no response kill it. That we've been lagging behind on
this is a manpower issue (and to some degree a technical issue with
GForge).

No code, or no active code development? Seems there is an important
difference that plays in here... looking a m-SQL it has code and could be a
starting point for someone who was looking for that. 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.

People do get pointed at adddepends even today... certainly no one will
do anything with these projects if you nuke them, but I like giving
people options... your call though.

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).

However, in the last year nobody has spoken up for the other three, not
even you.

Perhaps no one knew they needed to speak up... perhaps people couldn't even
find them in contrib... how many people still ask if we have full text
indexing? contrib isn't exactly the most visible place...

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.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

#11Josh Berkus
josh@agliodbs.com
In reply to: Robert Treat (#10)
Re: More nuclear options

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 to
real projects and not a repository of failed ideas.

Seems there is an important

difference that plays in here... looking a m-SQL it has code and could be a
starting point for someone who was looking for that.

So are you telling me you want to be responsible for it?

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 and code files which are missing. I don't
see any value in Techdocs for instructions that can't be followed.

Perhaps no one knew they needed to speak up... perhaps people couldn't even
find them in contrib... how many people still ask if we have full text
indexing? contrib isn't exactly the most visible place...

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.

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 Berkus

#12Robert Treat
xzilla@users.sourceforge.net
In reply to: Josh Berkus (#11)
Re: More nuclear options

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 and code files which are missing. I don't
see any value in Techdocs for instructions that can't be followed.

The information for the sql / code is embedded within the readme. It probably
should be broken out into multiple files. That might make it project worthy
rather than article worthy.

Perhaps no one knew they needed to speak up... perhaps people couldn't
even find them in contrib... how many people still ask if we have full
text indexing? contrib isn't exactly the most visible place...

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.

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.

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.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

#13Joshua D. Drake
jd@commandprompt.com
In reply to: Robert Treat (#7)
Re: More nuclear options

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 pgfoundry/gborg right now, this argument rings a
little hollow.

Strengthens JoshB's argument, not lessens it. That is also an argument for
Gforge admins, not hackers :)

In a year nobody has spoken up for those specific projects. Who's
going to maintain them? Who's going to use them?

People do get pointed at adddepends even today... certainly no one will do
anything with these projects if you nuke them, but I like giving people
options... your call though.

They will always be able to pull down the source from a previous release.

Sincerely,

Joshua D. Drake

--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

#14Josh Berkus
josh@agliodbs.com
In reply to: Robert Treat (#12)
Re: More nuclear options

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 /old section
and the CVS archives easily enough.

--Josh

#15Robert Treat
xzilla@users.sourceforge.net
In reply to: Josh Berkus (#14)
Re: More nuclear options

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 cheese.
If it's going to be dead code, it can do so in the FTP /old section
and the CVS archives easily enough.

I'm not going to actively maintain it, my intrest is just in exposing the
information so that others might find it. Putting it on foundry gives it a
chance at finding an active maintainer... leaving it in the archives of CVS
will guarantee you don't get one. Since most people seem comfortable with
that, so be it.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

#16Hannu Krosing
hannu@tm.ee
In reply to: Josh Berkus (#8)
Re: More nuclear options

Ü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 problem, you can have my spot as
pgfoundry admin

Why not just make *one* project, called DeadProjects and keep one
tarball + one README.TXT per directory under it, so that in the unlikely
event that someone (pg_necromancer ?) does want to resurrect a dead
project he/she/it has a place to get the code from.

--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com

#17Mark Mielke
mark@mark.mielke.cc
In reply to: Josh Berkus (#11)
Re: More nuclear options

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.

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.

To present a somewhat external opinion - I've looked at pgfoundry in
the past and been both confused and disappointed. Code that doesn't
compile, with no maintainer gives me a dirty taste in my mouth, and
my inner voice says "what the heck is this crap?"

There are several open source projects that give me this taste. Please
help PostgreSQL not be on this list by pruning dead projects, or
poor quality projects from the public image. It's EMBARASSING! :-)

Thanks.

Cheers,
mark

--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/

#18Joshua D. Drake
jd@commandprompt.com
In reply to: Josh Berkus (#11)
Re: More nuclear options

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 (maybe even the front of PgFoundry and or PostgreSQL.Org?) that
asks if anyone would like to take over maintainership of the handful?

Have a closing date for it, e.g; leave it open for a week and then if no one
steps up --- its over and we nuke them with prejudice.

Sincerely,

Joshua D. Drake

--Josh Berkus

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

#19Christopher Kings-Lynne
chriskl@familyhealth.com.au
In reply to: Josh Berkus (#8)
Re: More nuclear options

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"??