Thread: More nuclear options

More nuclear options

From
Josh Berkus
Date:
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




Re: More nuclear options

From
Bruce Momjian
Date:
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. +


Re: More nuclear options

From
Josh Berkus
Date:
All,

At the request of Dave Page, here's the semi-final list after looking at 
the code:

To be killed:adddependstipsmSQL-interface

To be migrated to pgFoundry:dbmirror (need owner)dbase (owner?)fulltextindex (owner?)mac (LER)userlock (Merlin)

--Josh Berkus


Re: More nuclear options

From
Robert Treat
Date:
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


Re: More nuclear options

From
Steve Singer
Date:
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.


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



Re: More nuclear options

From
Josh Berkus
Date:
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





Re: More nuclear options

From
Josh Berkus
Date:
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


Re: More nuclear options

From
Robert Treat
Date:
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


Re: More nuclear options

From
"Merlin Moncure"
Date:
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


Re: More nuclear options

From
Robert Treat
Date:
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


Re: More nuclear options

From
Josh Berkus
Date:
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


Re: More nuclear options

From
mark@mark.mielke.cc
Date:
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
bindthem...
 
                          http://mark.mielke.cc/



Re: More nuclear options

From
Josh Berkus
Date:
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
inthe FTP /old section 
 
and the CVS archives easily enough.

--Josh


Re: More nuclear options

From
Robert Treat
Date:
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


Re: More nuclear options

From
Hannu Krosing
Date:
Ü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





Re: More nuclear options

From
"Joshua D. Drake"
Date:
> 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
solutionssince 1997            http://www.commandprompt.com/
 




Re: More nuclear options

From
Robert Treat
Date:
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


Re: More nuclear options

From
Christopher Kings-Lynne
Date:
> 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"??



Re: More nuclear options

From
"Joshua D. Drake"
Date:
> 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
solutionssince 1997            http://www.commandprompt.com/