Re: Thought provoking piece on NetBSD

I thought some people in this group may find this letter from one of
NetBSD's founders very interesting.

http://mail-index.netbsd.org/netbsd-users/2006/08/30/0016.html

It is current, to the point and has some direct correlations with our
project that we may want to be aware of.

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/

It argues that 'forking' a project is not the real solution of a project going
wrong but rather staging a palace revolution of the existing infrastructure.

On Thursday 31 August 2006 12:11, Joshua D. Drake wrote:
> I thought some people in this group may find this letter from one of
> NetBSD's founders very interesting.
>
> http://mail-index.netbsd.org/netbsd-users/2006/08/30/0016.html
>
> It is current, to the point and has some direct correlations with our
> project that we may want to be aware of.
>
> Sincerely,
>
> Joshua D. Drake

On Thu, Aug 31, 2006 at 09:11:52AM -0700, Joshua D. Drake wrote:
> I thought some people in this group may find this letter from one of
> NetBSD's founders very interesting.
>
> http://mail-index.netbsd.org/netbsd-users/2006/08/30/0016.html
>
> It is current, to the point and has some direct correlations with our
> project that we may want to be aware of.

Nice post, though I don't think PostgreSQL really has many of the
faults he lists. The only obvious one to me is the strong leadership
part, but that's not quite as necessary (I think) because the project
has a clear goal (to a certain extent): SQL compliance.

I think operating systems are a particularly hard area because of the
amount of evolution going on and the amount of work needed just to keep
working on newer machines. The field of databases and SQL is nowhere
near that difficult.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Josh,

> It is current, to the point and has some direct correlations with our
> project that we may want to be aware of.

Well, we're not in any danger of the board of a foundation taking over
Postgres. ;-)

The only part of this that I see as relevant to us is setting of
development goals. And we've already discussed this ad nauseum on the
Hackers list and AFAIK have an initial plan (the enhanced TODO), lacking
only the resources to implement it this month.

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

On 8/31/06, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> The only part of this that I see as relevant to us is setting of
> development goals. And we've already discussed this ad nauseum on the
> Hackers list and AFAIK have an initial plan (the enhanced TODO), lacking
> only the resources to implement it this month.

As a proponent of PostgreSQL over MySQL and other database inside a
bunch of companies, one thing that's been problematic is the fact that
feature set is accidental, or appears that way.

I totally understand that people want to work on what they want to
work on, but there are obvious places that Postgres has issues that
make it less competitive. I can't go to anyone in the company and say
"8.3 will solve X," and in fact, until 8.2 hits the release, I'll not
really know what's in it. This makes planning difficult.

That's my main real complaint.

Chris
--
| Christopher Petrilli
| petrilli(at)gmail(dot)com

>
> The only part of this that I see as relevant to us is setting of
> development goals. And we've already discussed this ad nauseum on the
> Hackers list and AFAIK have an initial plan (the enhanced TODO), lacking
> only the resources to implement it this month.

Almost the whole thing is relevant :). Keep in mind that I am not saying
that it is negative. For example the NetBSD core is obviously cranked,
where our Core tends to stay out of the way. That is a positive.

On the other hand, we do suffer from the locked project problem (the
recent recursive query debacle is a perfect example).

We do have portions of a meritocracy in place but we are by no means
mature in that arena. Likely because of our lock problem ;)

We are also better at having cross over between sub projects so that
many people who are the same people are part of many projects. This
allows communication to flow between sub projects.

Not perfect of course :) but better then many I see.

Another odd issue, which may or may not be a positive is that we don't
have a public leader. We have half a dozen people (less I think) that
are very, very public (I am not talking mailing list public).

Anyway, the post as I said was for provoking thought, not for
antagonistic measures. I saw good and bad and thought it would be good
for everyone to review as we are as a project dealing with some of our
own growth problems.

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/

Joshua D. Drake wrote:
> >
> > The only part of this that I see as relevant to us is setting of
> > development goals. And we've already discussed this ad nauseum on the
> > Hackers list and AFAIK have an initial plan (the enhanced TODO), lacking
> > only the resources to implement it this month.
>
> Almost the whole thing is relevant :). Keep in mind that I am not saying

I totally agree!

> that it is negative. For example the NetBSD core is obviously cranked,
> where our Core tends to stay out of the way. That is a positive.
>
> On the other hand, we do suffer from the locked project problem (the
> recent recursive query debacle is a perfect example).

Yep, but fortunately this problem doesn't happen to us often.

> Anyway, the post as I said was for provoking thought, not for
> antagonistic measures. I saw good and bad and thought it would be good
> for everyone to review as we are as a project dealing with some of our
> own growth problems.

Yes. There are lessons to be learned.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

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

Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Thu, Aug 31, 2006 at 09:11:52AM -0700, Joshua D. Drake wrote:
> > I thought some people in this group may find this letter from one of
> > NetBSD's founders very interesting.
> >
> > http://mail-index.netbsd.org/netbsd-users/2006/08/30/0016.html
> >
> > It is current, to the point and has some direct correlations with our
> > project that we may want to be aware of.
>
> Nice post, though I don't think PostgreSQL really has many of the
> faults he lists. The only obvious one to me is the strong leadership
> part, but that's not quite as necessary (I think) because the project
> has a clear goal (to a certain extent): SQL compliance.

I think the issue is complacent leadership on the one hand, vs. a single
forceful leader on the other. I think the best configuration somewhere
is in the middle, which is what we have. I don't see how it is related
to the OS problem domain.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

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

Josh,

> On the other hand, we do suffer from the locked project problem (the
> recent recursive query debacle is a perfect example).

Yep, and that was immediately recognized as a problem in need of a
solution. In fact, some of the arguments againts the issue/feature
tracker were that it would encourage the locked project issue. So the
NetBSD experience should inform our design of the future feature/bug
tracker: it should be used to encourage new developers (by providing clear
specs and status information) rather than locking in old ones.

> We do have portions of a meritocracy in place but we are by no means
> mature in that arena. Likely because of our lock problem ;)

What specific issues do you see? We're pretty strongly merit-based -- the
only reservation I see on that is a bias toward more eloquent writers
having disproprotionate influence. But I don't see any way to avoid that.

> Another odd issue, which may or may not be a positive is that we don't
> have a public leader. We have half a dozen people (less I think) that
> are very, very public (I am not talking mailing list public).

Actually, this issue is a complete red herring. People like to point to
Linux as successful because of Linus's benevolent dictatorship, but Linus
is the exception rather than the rule. Most of the very successful
projects (Apache, Perl, MySQL, Debian, X.org, etc.) are led by councils or
companies without a dictator. I can name more than a few projects where
the "charismatic leader" was the main thing preventing the project's
success.

In general, I think that people who harp on PostgreSQL's lack of a
benevolent dictator as an inhibitor to progress are people who are not
comfortable with democracy and are looking for excuses why company X needs
to "take over the project for its own good."

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

> In general, I think that people who harp on PostgreSQL's lack of a
> benevolent dictator as an inhibitor to progress are people who are not
> comfortable with democracy and are looking for excuses why company X needs
> to "take over the project for its own good."

Well I definitely don't think we need a benevolent dictator... however
considering the relatively small number of people in the public eye, a
definition of goals that we all speak too might be good :)

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/

On Thu, Aug 31, 2006 at 11:18:27AM -0700, Joshua D. Drake wrote:
> On the other hand, we do suffer from the locked project problem (the
> recent recursive query debacle is a perfect example).

Maybe, but we don't have the extreme form. Patches have been submitted
by people other than the ones saying they'd do it, and no-one got their
head bitten off for it. Indeed, the original person was often grateful
that it wasn't their problem anymore.

One thing about the discussion about locking was where we wanted a more
formal locking strategy (keeping a list). I think this is the wrong
approach. If you want some feature that hasn't seen any recent
discussion, *do it*, don't wait around seeing if someone else will do
it. This was in the article also:

... there was no sense that anyone else "owned" a piece
of Linux (although de facto "ownership" has happened in some parts);
if you didn't produce, Linus would use someone else's code. If you
wanted people to use your stuff, you had to keep moving.

I really think that's a better idea than tracking who is doing what.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

>>
>> On the other hand, we do suffer from the locked project problem (the
>> recent recursive query debacle is a perfect example).
>
> Yep, but fortunately this problem doesn't happen to us often.

I think this might happen more then you think. I ran into it with Alvaro
just a couple of days ago. I brought up 3/4 items I thought he might be
interested in working on for 8.3.

The immediate response was well that is such a person's or that a person's.

Now, all we have to do is actually communicate ;) to make sure that we
move forward to eliminate the lock and we will. However it does point to
the fact that not everyone is going to take that extra step, some are
going to assume that it is being worked on.

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/

In response to "Joshua D. Drake" <jd(at)commandprompt(dot)com>:

> >>
> >> On the other hand, we do suffer from the locked project problem (the
> >> recent recursive query debacle is a perfect example).
> >
> > Yep, but fortunately this problem doesn't happen to us often.
>
> I think this might happen more then you think. I ran into it with Alvaro
> just a couple of days ago. I brought up 3/4 items I thought he might be
> interested in working on for 8.3.
>
> The immediate response was well that is such a person's or that a person's.
>
> Now, all we have to do is actually communicate ;) to make sure that we
> move forward to eliminate the lock and we will. However it does point to
> the fact that not everyone is going to take that extra step, some are
> going to assume that it is being worked on.

In my experience, some of this is culture. Some groups communicate more
easily than others. When people don't communicate well, stuff has to
be done to encourage it. At the extreme end, stuff has to be done to
enforce it.

I think it's best if it happens naturally, but you can't always count on
that.

--
Bill Moran
Collaborative Fusion Inc.

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> In general, I think that people who harp on PostgreSQL's lack of a
> benevolent dictator as an inhibitor to progress are people who are not
> comfortable with democracy and are looking for excuses why company X needs
> to "take over the project for its own good."

I don't recall having seen that idea being pushed for Postgres ... not
seriously anyway. However, it's certainly true that historically we've
had effectively *no* project leadership, in the sense of anyone setting
feature goals for releases or creating a long-term roadmap. Would we
be better off if we had done that? I'm not sure.

It's pointless to suppose that individual developers would really be
answerable to any project-wide management, since that's not who they're
paid by. So I tend to think that a project roadmap would be more of an
exercise in wishful thinking than a useful management tool. OTOH it
*could* be useful, if there are any developers out there wondering what
they should work on next. Are there any ... and would they listen to a
roadmap if they had one, rather than scratching their own itches?

regards, tom lane

bruce(at)momjian(dot)us (Bruce Momjian) writes:
> Joshua D. Drake wrote:
>> >
>> > The only part of this that I see as relevant to us is setting of
>> > development goals. And we've already discussed this ad nauseum on the
>> > Hackers list and AFAIK have an initial plan (the enhanced TODO), lacking
>> > only the resources to implement it this month.
>>
>> Almost the whole thing is relevant :). Keep in mind that I am not saying
>
> I totally agree!
>
>> that it is negative. For example the NetBSD core is obviously cranked,
>> where our Core tends to stay out of the way. That is a positive.
>>
>> On the other hand, we do suffer from the locked project problem (the
>> recent recursive query debacle is a perfect example).
>
> Yep, but fortunately this problem doesn't happen to us often.

It seems to me that PostgreSQL doesn't suffer in similar degree from
the "oh, dear, someone has that TODO item; now noone else can ever
look at it!" problem.

The recursive query situation is one where, while they may have missed
the 8.2 release, it's not as if this represents something that sat and
sat and which will see no action for 8.3 because "so and so has it on
their list..."

>> Anyway, the post as I said was for provoking thought, not for
>> antagonistic measures. I saw good and bad and thought it would be
>> good for everyone to review as we are as a project dealing with
>> some of our own growth problems.
>
> Yes. There are lessons to be learned.

I'm not sure how much can be readily learned from the "Oh, dear, we
bundle whatever features people come in with" problem. Managing a
free software project is quite a bit like herding cats; what you get
is what their wanderings resulted in.

To the degree to which people volunteer for things that strike them as
individually interesting, I don't see how you change that.

The classic item for PostgreSQL that people wish it had which has a
pretty wide-open kind of scope is the in-place upgrade. There's the
suggestion that perhaps one of the Sun folk will look at it for 8.3;
that's definitely NOT the sort of thing that fits into the
'independent volunteer noodling around with a feature they find
interesting' category.
--
output = reverse("gro.gultn" "@" "enworbbc")
http://www.ntlug.org/~cbbrowne/linuxxian.html
Rules of the Evil Overlord #47. "If I learn that a callow youth has
begun a quest to destroy me, I will slay him while he is still a
callow youth instead of waiting for him to mature."
<http://www.eviloverlord.com/>

tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) writes:
> It's pointless to suppose that individual developers would really be
> answerable to any project-wide management, since that's not who
> they're paid by. So I tend to think that a project roadmap would be
> more of an exercise in wishful thinking than a useful management
> tool. OTOH it *could* be useful, if there are any developers out
> there wondering what they should work on next. Are there any
> ... and would they listen to a roadmap if they had one, rather than
> scratching their own itches?

It seems to me that there's a vital difference between "sponsored
developers" and "hobbyists," here.

If a sponsored developer's work isn't providing their own organization
with value, then some managers outside the scope of PGDG will
doubtless demand some answers. And if the organization wants some
particular features, that may help guide some developers without PGDG
having expended any "managerial effort."

Those "answerability mechanisms" don't apply to as material a degree
to hobbyists.
--
"cbbrowne","@","ntlug.org"
http://cbbrowne.com/info/wp.html
if (argc > 1 && strcmp(argv[1], "-advice") == 0) {
printf("Don't Panic!\n");
exit(42);
}
(Arnold Robbins in the LJ of February '95, describing RCS)

Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
> > In general, I think that people who harp on PostgreSQL's lack of a
> > benevolent dictator as an inhibitor to progress are people who are not
> > comfortable with democracy and are looking for excuses why company X needs
> > to "take over the project for its own good."
>
> I don't recall having seen that idea being pushed for Postgres ... not
> seriously anyway. However, it's certainly true that historically we've
> had effectively *no* project leadership, in the sense of anyone setting
> feature goals for releases or creating a long-term roadmap. Would we
> be better off if we had done that? I'm not sure.
>
> It's pointless to suppose that individual developers would really be
> answerable to any project-wide management, since that's not who they're
> paid by. So I tend to think that a project roadmap would be more of an
> exercise in wishful thinking than a useful management tool. OTOH it
> *could* be useful, if there are any developers out there wondering what
> they should work on next. Are there any ... and would they listen to a
> roadmap if they had one, rather than scratching their own itches?

I think the longer someone is with the project the more they start
working on what is good for the project, rather than what interests
them. I think we have seen many cases of that.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

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

Bruce Momjian wrote:
> Tom Lane wrote:

> > It's pointless to suppose that individual developers would really be
> > answerable to any project-wide management, since that's not who they're
> > paid by. So I tend to think that a project roadmap would be more of an
> > exercise in wishful thinking than a useful management tool. OTOH it
> > *could* be useful, if there are any developers out there wondering what
> > they should work on next. Are there any ... and would they listen to a
> > roadmap if they had one, rather than scratching their own itches?

I would certainly listen to a roadmap if it talked to me ...

> I think the longer someone is with the project the more they start
> working on what is good for the project, rather than what interests
> them. I think we have seen many cases of that.

On my particular case, I generally grab some problem that I perceive as
important and unhandled, and try to do something to remedy it. This is
how I got here in the first place, by fixing some problems in the
CLUSTER implementation. This is how I got to doing shared dependencies,
shared row locks and autovacuum -- neither of them were problems that
affected me in any way. Savepoints were a different matter. I chose to
work on them because Bruce and other people on this list suggested them
to me, back when I was looking for something to do my undergrad project
in.

So yes, I'd probably work on something "the community" considered
important.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

[ hijacking this thread over to where the developers hang out ]

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> It's pointless to suppose that individual developers would really be
>> answerable to any project-wide management, since that's not who they're
>> paid by. So I tend to think that a project roadmap would be more of an
>> exercise in wishful thinking than a useful management tool. OTOH it
>> *could* be useful, if there are any developers out there wondering what
>> they should work on next. Are there any ... and would they listen to a
>> roadmap if they had one, rather than scratching their own itches?

> I would certainly listen to a roadmap if it talked to me ...

Well, this question keeps coming up, and we keep arguing about it, and
we still have no data to say whether it would work well for *this*
project. Maybe it's time to take the bull by the horns.

I propose a modest experiment: for the 8.3 development cycle, let's try
to agree (in the next month or so) on a roadmap of what major features
should be in 8.3 and who will make each one happen. A year from now,
we will know whether this is a great thing we should continue, or we
should stick to our traditional laissez-faire style of project
management. I figure that even if it really sucks, it wouldn't kill us
to try it for one release cycle --- at the very worst, we'd make up lost
time in future by no longer needing to waste bandwidth arguing about it.

regards, tom lane

On Aug 31, 2006, at 8:47 PM, Tom Lane wrote:

> [ hijacking this thread over to where the developers hang out ]
>
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> Tom Lane wrote:
>>> It's pointless to suppose that individual developers would really be
>>> answerable to any project-wide management, since that's not who
>>> they're
>>> paid by. So I tend to think that a project roadmap would be more
>>> of an
>>> exercise in wishful thinking than a useful management tool. OTOH it
>>> *could* be useful, if there are any developers out there
>>> wondering what
>>> they should work on next. Are there any ... and would they
>>> listen to a
>>> roadmap if they had one, rather than scratching their own itches?
>
>> I would certainly listen to a roadmap if it talked to me ...
>
> Well, this question keeps coming up, and we keep arguing about it, and
> we still have no data to say whether it would work well for *this*
> project. Maybe it's time to take the bull by the horns.
>
> I propose a modest experiment: for the 8.3 development cycle, let's
> try
> to agree (in the next month or so) on a roadmap of what major features
> should be in 8.3 and who will make each one happen. A year from now,
> we will know whether this is a great thing we should continue, or we
> should stick to our traditional laissez-faire style of project
> management. I figure that even if it really sucks, it wouldn't
> kill us
> to try it for one release cycle --- at the very worst, we'd make up
> lost
> time in future by no longer needing to waste bandwidth arguing
> about it.

Would this be a core postgresql code roadmap or something a bit
broader (contrib, custom types, GUI-ish stuff, utilities and what
have you)?

Cheers,
Steve

>> we will know whether this is a great thing we should continue, or we
>> should stick to our traditional laissez-faire style of project
>> management. I figure that even if it really sucks, it wouldn't kill us
>> to try it for one release cycle --- at the very worst, we'd make up lost
>> time in future by no longer needing to waste bandwidth arguing about it.
>
> Would this be a core postgresql code roadmap or something a bit
> broader (contrib, custom types, GUI-ish stuff, utilities and what
> have you)?

I think that we could at this time only expect things that would be
submitted for core inclusion. The less cats to herd the better :)

Joshua D. Drake

>
> Cheers,
> Steve
>
> ---------------------------(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/

Tom,

> I propose a modest experiment: for the 8.3 development cycle, let's try
> to agree (in the next month or so) on a roadmap of what major features
> should be in 8.3 and who will make each one happen.

Well, I think the what is more important that the who -- we can switch "whos"
if that's what it takes to make the "what" happen. Likely, we will have to.

> A year from now,
> we will know whether this is a great thing we should continue, or we
> should stick to our traditional laissez-faire style of project
> management.  I figure that even if it really sucks, it wouldn't kill us
> to try it for one release cycle --- at the very worst, we'd make up lost
> time in future by no longer needing to waste bandwidth arguing about it.

Great. I think we have some volunteers to put a tool online to track
volunteers, specifications and status.

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> I propose a modest experiment: for the 8.3 development cycle, let's try
>> to agree (in the next month or so) on a roadmap of what major features
>> should be in 8.3 and who will make each one happen.

> Well, I think the what is more important that the who -- we can switch
> "whos" if that's what it takes to make the "what" happen. Likely, we
> will have to.

No doubt --- but if there's not someone specific who's agreed to take on
each item on the roadmap, then what is it but pie-in-the-sky wishing?

I'm entirely comfortable with the idea that we put some things on the
roadmap that end up not being done when 8.3 release rolls around.
We've been disappointed that way a few times before ;-) ... we won't
be worse off if it happens again, and I'd rather aim high than low.

I think the important point to try for in this iteration is that someone
signs up for each thing the community thinks is important to get done,
and that we all believe no one has taken on anything they can't credibly
get done.

regards, tom lane

On Thu, 31 Aug 2006, Josh Berkus wrote:

> In general, I think that people who harp on PostgreSQL's lack of a
> benevolent dictator as an inhibitor to progress are people who are not
> comfortable with democracy and are looking for excuses why company X needs
> to "take over the project for its own good."

One problem I see the postresql at the moment (and I'm porbably touching a
can of worms here) is the lack of some sort of certification.

One thing linux (or Red Hat) is doing well is supplying the things that
corporates are looking for. And the first thing they look for when they
seriously start looking at a new technology is training. When they look at
training, they go for certifications (as we see all the time with the
RHCE).

We have a number of large corporate clients here in South Africa,
including some of the biggest banks, of which a few are asking for
training at the moment. It would be really nice to have some form of
certification available that we could present that had some international
credentials.

Anton

--
Forgiveness is giving up all hope for a better past

On Fri, Sep 01, 2006 at 12:40:53PM +0200, Stefan Kaltenbrunner wrote:
> heh if this is a request for a wishlist then I would suggest that we
> should finally tackle one of the things most databases are doing better
> then we (including MySQL) - that is better charset/locale/collate support.
> especially for new users or users converting from other database this is
> one of the major stumbling blocks (at least as seen on irc regulary)

Yeah well, I got reasonably far on that. To the point of being able to
have different collations on different columns, creating indexes with
different collations and having collation-sensetive comparisons:

http://archives.postgresql.org/pgsql-hackers/2005-12/msg01121.php

Where I got stuck is teaching the planner how to use the collation info
to produce appropriate plans. There wasn't a lot of feedback on the
patch itself, so I didn't know how to proceed. I don't have time for it
anymore but if someone wants to pick it up and run with it...

Note however that it's not easy, there are a number of related issues
which need to be solved at the same time:

Supporting SORTFUNC_LT/GT is going to get much harder, but there no
idea as to how much it's used anyway:

http://archives.postgresql.org/pgsql-hackers/2005-12/msg01154.php

The concept of "operator class" needs to be expanded into something
more general, into something that's actually describes the type, rather
than just how btrees work.

Do we want to keep relying on the system libraries for collation, or do
we want to use a cross-platform library like ICU or do we want to
create our own collation library?

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

> We have a number of large corporate clients here
in South Africa,
> including some of the biggest banks, of which a
few are asking for
> training at the moment. It would be really nice to
have some form
> of
> certification available that we could present that
had some
> international
> credentials.
>
> Anton
>

Anton,
Others are also looking for training so I am
starting a thread on it as I feel that the Topic
should be part of Advocacy. Opinions will likely
vary about certification -- but Training? Yes,
definitely needed.

Below is a snip from a similar post on the Novice
list (about 1 hour ago).

*********************************** from
Novice****************************
On Thu, 2006-08-31 at 15:42 -0400, Ray Stell wrote:
> What is the best value for training bucks for pg
admin/internals?
> I know the answer, of course, read the source, but
I'd like to take a class
> if there is a great one to be found. Thanks.

Wouldn't this be the perfect opportunity for one of
the gurus to
announce their killer new online gratis training
program?

Andy
*******************************************************************************

Alvaro Herrera wrote:
> Bruce Momjian wrote:
>> Tom Lane wrote:
>
>>> It's pointless to suppose that individual developers would really be
>>> answerable to any project-wide management, since that's not who they're
>>> paid by. So I tend to think that a project roadmap would be more of an
>>> exercise in wishful thinking than a useful management tool. OTOH it
>>> *could* be useful, if there are any developers out there wondering what
>>> they should work on next. Are there any ... and would they listen to a
>>> roadmap if they had one, rather than scratching their own itches?
>
> I would certainly listen to a roadmap if it talked to me ...
>
>> I think the longer someone is with the project the more they start
>> working on what is good for the project, rather than what interests
>> them. I think we have seen many cases of that.
>
> On my particular case, I generally grab some problem that I perceive as
> important and unhandled, and try to do something to remedy it. This is
> how I got here in the first place, by fixing some problems in the
> CLUSTER implementation. This is how I got to doing shared dependencies,
> shared row locks and autovacuum -- neither of them were problems that
> affected me in any way. Savepoints were a different matter. I chose to
> work on them because Bruce and other people on this list suggested them
> to me, back when I was looking for something to do my undergrad project
> in.
>
> So yes, I'd probably work on something "the community" considered
> important.
>

heh if this is a request for a wishlist then I would suggest that we
should finally tackle one of the things most databases are doing better
then we (including MySQL) - that is better charset/locale/collate support.
especially for new users or users converting from other database this is
one of the major stumbling blocks (at least as seen on irc regulary)

Stefan

nhrcommu(at)rochester(dot)rr(dot)com wrote:
> Wouldn't this be the perfect opportunity for one of
> the gurus to
> announce their killer new online gratis training
> program?

My ideas; There must be some universities that have courses into
database design and implementation that are based on PostgreSQL.

If syllables(sp?) of those courses would be made public or be provided
to an "educational team" within our community, it'd be quite easy to use
them to base small courses on all over the world. It wouldn't even be
necessary to pay the people providing the education, the courses could
pay for themselves.

Ideally there'd be some central coordination from within the postgresql
community, so that there is some quality control possible and to point
people with questions to this extent to the appropriate instances. And
of course, the community could (should?) provide feedback to the
university involved. Benefit for everyone involved; and they lived long
ever after.

Regards,
--
Alban Hertroys
alban(at)magproductions(dot)nl

magproductions b.v.

T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede

// Integrate Your World //

Joshua D. Drake wrote:
>>> we will know whether this is a great thing we should continue, or we
>>> should stick to our traditional laissez-faire style of project
>>> management. I figure that even if it really sucks, it wouldn't kill us
>>> to try it for one release cycle --- at the very worst, we'd make up lost
>>> time in future by no longer needing to waste bandwidth arguing about it.
>>
>> Would this be a core postgresql code roadmap or something a bit
>> broader (contrib, custom types, GUI-ish stuff, utilities and what
>> have you)?
>
> I think that we could at this time only expect things that would be
> submitted for core inclusion. The less cats to herd the better :)

yeah I would agree that it makes sense to do that for core postgresql
code only for now - most of the others stuff is not even directly tied
to the 8.3 development cycle either(GUIs will have to support more than
a single release probably as would maybe special custom types or such).

Stefan

nhrcommu(at)rochester(dot)rr(dot)com wrote:
>> We have a number of large corporate clients here

> Anton,
> Others are also looking for training so I am
> starting a thread on it as I feel that the Topic
> should be part of Advocacy. Opinions will likely
> vary about certification -- but Training? Yes,
> definitely needed.

The biggest issue is not training , at least in america.
There are at least 4 *known* trainers that do PostgreSQL.

Big Nerd Ranch
Command Prompt
OSTG
Varlena

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/

Martijn van Oosterhout wrote:
> On Fri, Sep 01, 2006 at 12:40:53PM +0200, Stefan Kaltenbrunner wrote:
>> heh if this is a request for a wishlist then I would suggest that we
>> should finally tackle one of the things most databases are doing better
>> then we (including MySQL) - that is better charset/locale/collate support.
>> especially for new users or users converting from other database this is
>> one of the major stumbling blocks (at least as seen on irc regulary)
>
> Yeah well, I got reasonably far on that. To the point of being able to
> have different collations on different columns, creating indexes with
> different collations and having collation-sensetive comparisons:
>
> http://archives.postgresql.org/pgsql-hackers/2005-12/msg01121.php
>
> Where I got stuck is teaching the planner how to use the collation info
> to produce appropriate plans. There wasn't a lot of feedback on the
> patch itself, so I didn't know how to proceed. I don't have time for it
> anymore but if someone wants to pick it up and run with it...
>
> Note however that it's not easy, there are a number of related issues
> which need to be solved at the same time:

yeah I had some hopes for this getting done - and what you have seems
like a nice start - but the whole thing is quite difficult and I expect
that project to need quite a lot of further work :-(

>
> Supporting SORTFUNC_LT/GT is going to get much harder, but there no
> idea as to how much it's used anyway:
>
> http://archives.postgresql.org/pgsql-hackers/2005-12/msg01154.php
>
> The concept of "operator class" needs to be expanded into something
> more general, into something that's actually describes the type, rather
> than just how btrees work.
>
> Do we want to keep relying on the system libraries for collation, or do
> we want to use a cross-platform library like ICU or do we want to
> create our own collation library?

that is probably something that we really need to decide on - system
libaries do seem to be easy but I have some doubts about portability and
quality of implemtations (like getting different behaviour on different
platforms) and some of our supported platforms (like the BSDs) have
rather limited support for collation either.
On the ICU vs. our own library I'm not sure what would be a good thing
to do - ICU is _LARGE_ and we already have some perfectly fine and
proven code for things like character conversion or timezone handling in
the core ...

Stefan

Anton de Wet wrote:
>
> One problem I see the postresql at the moment (and I'm porbably touching
> a can of worms here) is the lack of some sort of certification.
>
> One thing linux (or Red Hat) is doing well is supplying the things that
> corporates are looking for. And the first thing they look for when they
> seriously start looking at a new technology is training. When they look
> at training, they go for certifications (as we see all the time with the
> RHCE).
>
> We have a number of large corporate clients here in South Africa,
> including some of the biggest banks, of which a few are asking for
> training at the moment. It would be really nice to have some form of
> certification available that we could present that had some
> international credentials.
>
> Anton
>

Training I agree with, but certifications can go either way. A good
example of where certifications are generally NOT going to work in your
favour is the fiasco that Oracle has created with their OCP
certification over the past 6 or so years. So many people were pushed
through these OCP mills that their certifications have become worthless.
HR types were finding that these Oracle-certified dba/developers are of
dubious quality at best -- even though they have a piece of paper
stating that they are officially trained. I know that when we look at
prospective employees, that designation is totally ignored. It is their
experience and ability to do the job properly that count more than anything.

my two bits.

On Fri, Sep 01, 2006 at 04:16:31PM +0200, Stefan Kaltenbrunner wrote:
> On the ICU vs. our own library I'm not sure what would be a good thing
> to do - ICU is _LARGE_ and we already have some perfectly fine and
> proven code for things like character conversion or timezone handling in
> the core ...

Well, there's the pros:
- It's faster than glibc
- Patches to do it have already been submitted
- There doesn't exist any other library that does it

I'm not sure the size is that much of an issue, the point being to use
it if it's installed on people's machines. Besides, it not that big,
it'd fit inside one of our WAL segments :)

I think the bigger question is: collation is hard, is anyone here
interested in maintaining such code? If not, we outsource to a group
who *is* willing to maintain it.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

On Thursday 31 August 2006 14:41, Josh Berkus wrote:
> > We do have portions of a meritocracy in place but we are by no means
> > mature in that arena. Likely because of our lock problem ;)
>
> What specific issues do you see? We're pretty strongly merit-based -- the
> only reservation I see on that is a bias toward more eloquent writers
> having disproprotionate influence. But I don't see any way to avoid that.
>

I think some members of this community confuse volunteerism with meritocracy.

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

On Thu, Aug 31, 2006 at 11:41:41 -0700,
Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>
> In general, I think that people who harp on PostgreSQL's lack of a
> benevolent dictator as an inhibitor to progress are people who are not
> comfortable with democracy and are looking for excuses why company X needs
> to "take over the project for its own good."

I think Postgres is best described as ruled by an Oligarchy. I would expect
a democracy to at least include all of the developers in votes. However
when things are decided by a vote rather than consensus it is core that votes.
(I think Debian would be a good example of an open source project run as a
democracy.)

On a related comment to that story, there have been a fair number of people
stating that they think the GPL vs BSD license has been very important in
getting companies to give back to the project. I think Postgres has done quite
well with having companies give back code and resources to the project and
makes a good counter example to these claims. There probably are some license
effects, but other things also affect companies' decisions on giving back
to projects they benefit from.

> Training I agree with, but certifications can go either way. A good
> example of where certifications are generally NOT going to work in your
> favour is the fiasco that Oracle has created with their OCP
> certification over the past 6 or so years. So many people were pushed
> through these OCP mills that their certifications have become worthless.
> HR types were finding that these Oracle-certified dba/developers are of
> dubious quality at best -- even though they have a piece of paper
> stating that they are officially trained. I know that when we look at
> prospective employees, that designation is totally ignored. It is their
> experience and ability to do the job properly that count more than
> anything.

There are ways around that though. I don't know much about the OCP but I
know that the Cisco certs are *tough*.

Microsoft is another cert that is useless. They key is simple:

You should not be able to pass the test by reading an exam.

There needs to be things on the test that you *only* gain from real
world experience.

Joshua D. Drake

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

--

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

Martijn van Oosterhout wrote:
> Do we want to keep relying on the system libraries for collation, or
> do we want to use a cross-platform library like ICU or do we want to
> create our own collation library?

ICU seems fine.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Friday 01 September 2006 10:02, Joshua D. Drake wrote:
> The biggest issue is not training , at least in america.
> There are at least 4 *known* trainers that do PostgreSQL.
>
> Big Nerd Ranch
> Command Prompt
> OSTG
> Varlena

AHEM... SRA ;-)

On Fri, 2006-09-01 at 11:03, Bruno Wolff III wrote:
> On Thu, Aug 31, 2006 at 11:41:41 -0700,
> Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> >
> > In general, I think that people who harp on PostgreSQL's lack of a
> > benevolent dictator as an inhibitor to progress are people who are not
> > comfortable with democracy and are looking for excuses why company X needs
> > to "take over the project for its own good."
>
> I think Postgres is best described as ruled by an Oligarchy. I would expect
> a democracy to at least include all of the developers in votes. However
> when things are decided by a vote rather than consensus it is core that votes.
> (I think Debian would be a good example of an open source project run as a
> democracy.)
>
> On a related comment to that story, there have been a fair number of people
> stating that they think the GPL vs BSD license has been very important in
> getting companies to give back to the project. I think Postgres has done quite
> well with having companies give back code and resources to the project and
> makes a good counter example to these claims. There probably are some license
> effects, but other things also affect companies' decisions on giving back
> to projects they benefit from.

I think that with either the GPL or BSD, code is returned under a type
of coercion. Not necessarily a bad thing, understand.

The coercion of the GPL is legalistic. If you distribute GPL stuff,
you've got to give out the source code with it. So, you might as well
give it to the community at large. With BSD, it's more that you'd be
cutting yourself off from the community at large if you didn't return
the code. So, the coercion is much more subtle. It's much easier to
donate your code to the project and let other people maintain it then to
try and maintain your own fork of the code and cross patch their changes
into your own.

I generally find the BSD license easier to sell to bosses, for sure.

Robert Bernier wrote:
> On Friday 01 September 2006 10:02, Joshua D. Drake wrote:
>> The biggest issue is not training , at least in america.
>> There are at least 4 *known* trainers that do PostgreSQL.
>>
>> Big Nerd Ranch
>> Command Prompt
>> OSTG
>> Varlena
>
> AHEM... SRA ;-)

Who?

;)

Sincerely,

Joshua D. Drake

>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>

--

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott Marlowe wrote:
> On Fri, 2006-09-01 at 11:03, Bruno Wolff III wrote:
>> On Thu, Aug 31, 2006 at 11:41:41 -0700, Josh Berkus
>> <josh(at)agliodbs(dot)com> wrote:
[snip]
> The coercion of the GPL is legalistic. If you distribute GPL
> stuff, you've got to give out the source code with it. So, you
> might as well give it to the community at large. With BSD, it's
> more that you'd be cutting yourself off from the community at
> large if you didn't return the code. So, the coercion is much
> more subtle. It's much easier to donate your code to the project
> and let other people maintain it then to try and maintain your
> own fork of the code and cross patch their changes into your own.

Ultrix and SunOS are two counter-examples.

- --
Ron Johnson, Jr.
Jefferson LA USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE+R+jS9HxQb37XmcRAi9oAJ9xtMVAtP0Iyphs4X5pOE8SPfYeUgCg2WjW
ETzN0+tPInoThU2bhmcDanM=
=OXWG
-----END PGP SIGNATURE-----

On 2/9/2006 4:11, "Scott Marlowe" <smarlowe(at)g2switchworks(dot)com> wrote:

> I think that with either the GPL or BSD, code is returned under a type
> of coercion. Not necessarily a bad thing, understand.
>
> The coercion of the GPL is legalistic. If you distribute GPL stuff,
> you've got to give out the source code with it. So, you might as well
> give it to the community at large. With BSD, it's more that you'd be
> cutting yourself off from the community at large if you didn't return
> the code. So, the coercion is much more subtle. It's much easier to
> donate your code to the project and let other people maintain it then to
> try and maintain your own fork of the code and cross patch their changes
> into your own.

The GPL *forces* you to release your source code where the BSD license gives
you the option to choose what you want to do with your work. Free choice is
a good way to get co-operation where forcing would normally get a negative
response. That's just general human behaviour.

With the BSD license if you want an advantage in the market you can add your
own features/improvements and hold on to them to make your product stand
out.

6 or 12 months down the line when the competition starts to catch up or you
have a good position in the market you can then share your earlier
improvements if you choose to, or just share some of them.

> I generally find the BSD license easier to sell to bosses, for sure.

It can be a good selling point to business folk - that they aren't forced to
share the work that they paid for. The old hold on to corporate secrets.

When you get them working on it you then sell them the idea of sharing their
work to get a good code review and broad testing to ensure quality and
stability.

--

Shane Ambler
Postgres(at)007Marketing(dot)com

Get Sheeky @ http://Sheeky.Biz

Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> writes:
> Scott Marlowe wrote:
>> ... It's much easier to donate your code to the project
>> and let other people maintain it then to try and maintain your
>> own fork of the code and cross patch their changes into your own.

> Ultrix and SunOS are two counter-examples.

And? Seen either of them around lately?

(Solaris is still around, of course, but AIUI that's a complete
rewrite not a continuation of SunOS.)

regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Lane wrote:
> Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> writes:
>> Scott Marlowe wrote:
>>> ... It's much easier to donate your code to the project
>>> and let other people maintain it then to try and maintain your
>>> own fork of the code and cross patch their changes into your own.
>
>> Ultrix and SunOS are two counter-examples.
>
> And? Seen either of them around lately?

I deny the assertion that "not sharing code" is the reason they
aren't in the market anymore.

> (Solaris is still around, of course, but AIUI that's a complete
> rewrite not a continuation of SunOS.)

- --
Ron Johnson, Jr.
Jefferson LA USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE+ZJWS9HxQb37XmcRArC1AJ9evnA0UdTM8Kll6X2VJF8G+YMvRgCg4nmx
Tjwg1cLdASPRsWTOrQy9zwY=
=WjAe
-----END PGP SIGNATURE-----

Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> writes:
> Tom Lane wrote:
>> Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> writes:
> Scott Marlowe wrote:
>>>> ... It's much easier to donate your code to the project
>>>> and let other people maintain it then to try and maintain your
>>>> own fork of the code and cross patch their changes into your own.
>>>
>>> Ultrix and SunOS are two counter-examples.
>>
>> And? Seen either of them around lately?

> I deny the assertion that "not sharing code" is the reason they
> aren't in the market anymore.

You have as much proof of that as I have of the opposite, namely none
whatsoever. But certainly you can't put them forward today as examples
of long-term success of a private fork.

regards, tom lane

Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>
>> In general, I think that people who harp on PostgreSQL's lack of a
>> benevolent dictator as an inhibitor to progress are people who are not
>> comfortable with democracy and are looking for excuses why company X needs
>> to "take over the project for its own good."
>>
>
> I don't recall having seen that idea being pushed for Postgres ... not
> seriously anyway. However, it's certainly true that historically we've
> had effectively *no* project leadership, in the sense of anyone setting
> feature goals for releases or creating a long-term roadmap. Would we
> be better off if we had done that? I'm not sure.
>
I actually found the whole writeup thought provoking in one very
important way:
1) Most of the issues cited in the article appear on the surface to
exist in our community but
2) We are seemingly amazingly productive as a community.

I just want to share my thoughts on a few of these issues.

Strong leadership exists in the PostgreSQL community in terms of an
actual meritocracy. There are people here who work hard, deliver
quality results, and are recognized as community leaders in various
roles. Pretty much everyone on the core team fits that description.
However, this leadership is largely hands-off, more of a mentor in a
meritocracy than a project manager. This works well in our community
because we have a lot of people who are take a huge professional
interest in pushing the project forward, and the core team does a good
job of encouraging people to take an active part.

As for locking, there are good and bad aspects. Certainly, there are
times when locking is a Bad Thing(TM). On the other hand, if a
developer knows that a competent developer is working on a problem, they
may be inclined to look for other areas where they can more efficiently
put in their time. The general rule IMO is-- if you really need it, do
the work even if it is "locked." If you can wait for a few versions and
don't really care, then find a place where you can better donate your
time. We don't need to go to the extent of encouraging duplication of
effort.

In the end, many different leadership models may work, but the goal must
be the building of community and the recruiting of competent
developers. These are the areas that I think PostgreSQL has done
particularly well and some other projects have failed at.

Best Wishes,
Chris Travers
Metatron Technology Consulting
> It's pointless to suppose that individual developers would really be
> answerable to any project-wide management, since that's not who they're
> paid by. So I tend to think that a project roadmap would be more of an
> exercise in wishful thinking than a useful management tool. OTOH it
> *could* be useful, if there are any developers out there wondering what
> they should work on next. Are there any ... and would they listen to a
> roadmap if they had one, rather than scratching their own itches?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>
>
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Lane wrote:
> Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> writes:
>> Tom Lane wrote:
>>> Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> writes:
>> Scott Marlowe wrote:
>>>>> ... It's much easier to donate your code to the project
>>>>> and let other people maintain it then to try and maintain your
>>>>> own fork of the code and cross patch their changes into your own.
>>>> Ultrix and SunOS are two counter-examples.
>>> And? Seen either of them around lately?
>
>> I deny the assertion that "not sharing code" is the reason they
>> aren't in the market anymore.
>
> You have as much proof of that as I have of the opposite, namely none
> whatsoever. But certainly you can't put them forward today as examples
> of long-term success of a private fork.

That's the question: did they fail because they were private forks,
or did the *companies* fail because of bad management, bad
marketing, etc?

- --
Ron Johnson, Jr.
Jefferson LA USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE+fgAS9HxQb37XmcRArz4AKCGrtyT9v9TsZY+MMNgIDTlO9TJfQCgl0Cr
FXyY2ZMua9YR6ni9CulPgKY=
=opkW
-----END PGP SIGNATURE-----

Joshua D. Drake wrote:

>
>> Training I agree with, but certifications can go either way.
>
>
Guys, a multiple perspective is important. Your perspective is valid,
but doesn't address the true purpose of these easy certs. They are
designed to give the companies involved larger mind space among
programmers, admins, and companies hiring them. They are a
self-fulfilling prophecy -- here is our trained army of certified blah
blahs. Of course the tests are easy. They are meant to suck in the
maximum number of mediocre technos with large training fees, while at
the same time getting commitments from these folks to be a Microsoft
"something" or an Oracle "something" or a Redhat something. The cream
of the crop are then enticed into tougher courses with larger fees.
Certification is a Profit Center And don't mistake their force. a MSCE
does get more money, does find it easier to get hired in small companies.
Maybe Postgresql should think like the big companies. Establish a
Postgreesql certification process as a profit center, where the profits
can be funnelled into bounties for getting development things done with
the database. No matter who we are, money drives our efforts.
Pervasive demonstrated that. But for every good writer like Momjean
there are 100 programmers less gifted in human relationships who need to
eat. Instead of a guru in charge which I will call the linus model, a
long range blueprint or roadmap could be constructed by the core group,
with bounties placed on the less heroic development efforts that cause
no increase in presitge. And a bonus system for work completed on time
could be established.

JMTCWAAMG
Michael

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.7/436 - Release Date: 9/1/2006

In the last exciting episode, mdean(at)xn1(dot)com (mdean) wrote:
> Guys, a multiple perspective is important. Your perspective is
> valid, but doesn't address the true purpose of these easy certs.
> They are designed to give the companies involved larger mind space
> among programmers, admins, and companies hiring them. They are a
> self-fulfilling prophecy -- here is our trained army of certified
> blah blahs. Of course the tests are easy. They are meant to suck
> in the maximum number of mediocre technos with large training fees,
> while at the same time getting commitments from these folks to be a
> Microsoft "something" or an Oracle "something" or a Redhat
> something. The cream of the crop are then enticed into tougher
> courses with larger fees. Certification is a Profit Center

Certification is only a profit center if you can get the price tag
down to something reasonable.

It costs on the order of $75K/year to keep an exam in place at Vue,
which is in addition to the cost of initially building an exam, which
means you can only make money if there are thousands of certificants.

It is *expensive* to set up an exam; it only starts to become
profitable if you're giving out tens of thousands of them per year.

My understanding is that the LPI exams for Linux are only *barely*
breaking even, and that's with a fair bit of support from IBM and
Novell.

This represents the compelling part of why PostgreSQL certification
hasn't gone very far thus far; it is *so* expensive to deploy tests
because this has fallen into the hands of the oligopoly of Pearson VUE
and Thompson/Prometric. As competitors pop up, they have the money to
buy them out. (And I probably benefit; I hold shares in Thompson...
:-))

There is a BSD Certification program ongoing; they have run into much
the same issue: to do this easily, they would need a boatload of money
to deploy testing facilities that they simply don't have.

If someone had $1M (of whatever sort of dollar doesn't too much
matter), they might in principle be able to get a new testing network
going; of course, that would probably lead to a buyout from the
oligopoly.

My counterquestion: Do you think that establishing a training network
(only to watch it get snatched up by one of those companies) is a
better use of $1M than any of the other possible uses? It strikes me
as one of the poorer uses of that kind of money...

> And don't mistake their force. a MSCE does get more money, does
> find it easier to get hired in small companies.

Maybe on your planet. The value of an MCSE is discounted pretty
heavily on mine, now that they have come up with curriculum that allow
"certification farms" to spin through unskilled people that can
memorize enough answers in 6 weeks to pass the exam.

The only certs that I hear about that are considered of high value is
CCNA/CCNP (Cisco).
--
output = ("cbbrowne" "@" "gmail.com")
http://linuxdatabases.info/info/slony.html
Rules of the Evil Overlord #132. "Before appointing someone as my
trusted lieutenant, I will conduct a thorough background investigation
and security clearance. <http://www.eviloverlord.com/>

On Sun, 3 Sep 2006, mdean wrote:

> Guys, a multiple perspective is important. Your perspective is valid, but
> doesn't address the true purpose of these easy certs. They are designed to
> give the companies involved larger mind space among programmers, admins, and
> companies hiring them. They are a self-fulfilling prophecy -- here is our
> trained army of certified blah blahs. Of course the tests are easy. They
> are meant to suck in the maximum number of mediocre technos with large
> training fees, while at the same time getting commitments from these folks to
> be a Microsoft "something" or an Oracle "something" or a Redhat something.
> The cream of the crop are then enticed into tougher courses with larger fees.
> Certification is a Profit Center And don't mistake their force. a MSCE does
> get more money, does find it easier to get hired in small companies. Maybe
> Postgresql should think like the big companies. Establish a Postgreesql
> certification process as a profit center, where the profits can be funnelled
> into bounties for getting development things done with the database. No
> matter who we are, money drives our efforts. Pervasive demonstrated that.
> But for every good writer like Momjean there are 100 programmers less gifted
> in human relationships who need to eat. Instead of a guru in charge which I
> will call the linus model, a long range blueprint or roadmap could be
> constructed by the core group, with bounties placed on the less heroic
> development efforts that cause no increase in presitge. And a bonus system
> for work completed on time could be established.

As someone that is constantly selling into corporates, this is sad (except
for the money part) but true. For accountants that have NO idea what the
techspeak mean, the only thing they have to trust is those little pieces
of paper from companies they have heard from.

I think the quality of the RedHat certs are higher than some of the
others, and that is something we should strive for.

Anton

--
Forgiveness is giving up all hope for a better past

On Sun, 3 Sep 2006, Christopher Browne wrote:

> Certification is only a profit center if you can get the price tag
> down to something reasonable.
>
> It costs on the order of $75K/year to keep an exam in place at Vue,
> which is in addition to the cost of initially building an exam, which
> means you can only make money if there are thousands of certificants.
>
> It is *expensive* to set up an exam; it only starts to become
> profitable if you're giving out tens of thousands of them per year.
>
> My understanding is that the LPI exams for Linux are only *barely*
> breaking even, and that's with a fair bit of support from IBM and
> Novell.

I'd stay FAR away from a VUE certification. Multiple choice is SO last
milinium :)

I know I'm harpring on Red Hat, but they were voted as best certification
recently. No multiple choice, only hands-on , "can you do this" with
automated tests that checks for an outcome, not how you did it.

> The only certs that I hear about that are considered of high value is
> CCNA/CCNP (Cisco).

Also completely hands on.

To run a propper cert will require some dedicated people, no you need to
pay the exhorbitant VUE fees. It will take longer to build the cert and
get enough people trained, the end quality will be higher.

Anton

--
Forgiveness is giving up all hope for a better past

I can give you a bit of information on BSDcertification.org 's (http://www.bsdcertification.org/) testing infrastructure initiative, see below....

On Sunday 03 September 2006 22:15, Christopher Browne wrote:
> It costs on the order of $75K/year to keep an exam in place at Vue,
> which is in addition to the cost of initially building an exam, which
> means you can only make money if there are thousands of certificants.
>
> It is *expensive* to set up an exam; it only starts to become
> profitable if you're giving out tens of thousands of them per year.
>
> My understanding is that the LPI exams for Linux are only *barely*
> breaking even, and that's with a fair bit of support from IBM and
> Novell.
>
> This represents the compelling part of why PostgreSQL certification
> hasn't gone very far thus far; it is *so* expensive to deploy tests
> because this has fallen into the hands of the oligopoly of Pearson VUE
> and Thompson/Prometric. As competitors pop up, they have the money to
> buy them out. (And I probably benefit; I hold shares in Thompson...
>
> :-))
>
> There is a BSD Certification program ongoing; they have run into much
> the same issue: to do this easily, they would need a boatload of money
> to deploy testing facilities that they simply don't have.

It was understood from day one that BSDcertification.org would not have much in the way of funds therefore the plan is to create their own 'testing infrastructure'. Thus far, the database engine framework, to create the questions, has been designed and is currently being used to populate a postgres database with questions. Meanwhile, the group has been conducting surveys accross the world defining reasonable rates for each region (I think it's been published onsite but I can't remember). The group has also identified a methodology procuring testing sites at a deep discount but is keeping that to themselves for the time being.

> If someone had $1M (of whatever sort of dollar doesn't too much
> matter), they might in principle be able to get a new testing network
> going; of course, that would probably lead to a buyout from the
> oligopoly.

The biggest cost thus far has been paying for the services of a psychometrist tasked with framing the design constraints for the database engine, whom by way comes from LPI. But there are other costs, fortunately there's a dedicated team so the money issue is only slowing down the work. But it would certaintly help accelerate the process if they had $20,000+ in the kitty.

> My counterquestion: Do you think that establishing a training network
> (only to watch it get snatched up by one of those companies) is a
> better use of $1M than any of the other possible uses? It strikes me
> as one of the poorer uses of that kind of money...

The BSDcertfication.org testing infrastructure can't get snatched up i.e. the group is organized along BSD lines therefore it's impossible to get taken over, (sound familiar? ;-).

Furthermore, once the testing infrastructure is fully developed the intention is to make it available world wide at an "extrememly" reasonable price. For example, UNESCO would benefit a lot because it currently uses a big chunk of its money to sponsor individuals from the developing nations to get standards testing which they must pay at the full rate to either one of the two biggies that currently dominate the scene. The infrastructure will be capable of setting up tests for 'any' standards or requirements including PostgreSQL, if we want to. It just happens to be that BSD certification that will be the first one based on this infrastructure.

So far it's shaping up pretty good. For more information go to the website, http://www.bsdcertification.org/, or contact the BSDcertification.org chair dlavigne6(at)sympatico(dot)ca (Dru).

> > And don't mistake their force. a MSCE does get more money, does
> > find it easier to get hired in small companies.

I agree.

cheers

Robert

On Monday 04 September 2006 06:22, Robert Bernier wrote:
> I can give you a bit of information on BSDcertification.org 's
> (http://www.bsdcertification.org/) testing infrastructure initiative, see
> below....

Here's some new information that I'd like to pass on:

> http://blogs.ittoolbox.com/unix/bsd/archives/why-certification-exams-suck-more-on-cost-11060
> http://blogs.ittoolbox.com/unix/bsd/archives/why-certification-exams-suck-testing-center-requirements-11066
>
> The BSD Certification Group will be publishing a report this Friday on the
> recent survey of test candidates which asked for their geographic
> locations, the maximum price they are willing to pay to take a
> certification, and how they would like to take that certification. The
> report will clearly show that the existing commercial solutions neither
> meet the needs of testing candidates nor are affordable to test creation
> organizations who anticipate a low volume of test takers.
>
> Dru

How about we set up our own, community-based, "certification". This
will of course not be as policable as pro certification, but I say it
would be good anyway.

We can set up this software:

http://www.tecnick.com/public/code/cp_dpage.php?aiocp_dp=tcexam

(Runs on PostgreSQL it seems)

And then collaboratively we can build several exams on different topics.

Then we have them as links on the Postgresql site.

Chris

On Tue, 5 Sep 2006, Christopher Kings-Lynne wrote:

> How about we set up our own, community-based, "certification". This
> will of course not be as policable as pro certification, but I say it
> would be good anyway.
>
> We can set up this software:
>
> http://www.tecnick.com/public/code/cp_dpage.php?aiocp_dp=tcexam
>
> (Runs on PostgreSQL it seems)

When thinking exams, don't think memorization. Think doing things and
getting a job done. All product documentation provided. That way you land
up with exams that are worth something in the real world.

Anton

Anton de Wet wrote:
> When thinking exams, don't think memorization. Think doing things and
> getting a job done. All product documentation provided. That way you
> land up with exams that are worth something in the real world.

Hear hear. Rote learned lists can be forgotten easily, but once you
learn how to ride a bike you never forget..

Gr,

Koen

--
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, hosting, embedded systems, unix, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/

Shane Ambler wrote:
> On 2/9/2006 4:11, "Scott Marlowe" <smarlowe(at)g2switchworks(dot)com> wrote:
>
>> I think that with either the GPL or BSD, code is returned under a type
>> of coercion. Not necessarily a bad thing, understand.
>>
>> The coercion of the GPL is legalistic. If you distribute GPL stuff,
>> you've got to give out the source code with it. So, you might as well
>> give it to the community at large. With BSD, it's more that you'd be
>> cutting yourself off from the community at large if you didn't return
>> the code. So, the coercion is much more subtle. It's much easier to
>> donate your code to the project and let other people maintain it then to
>> try and maintain your own fork of the code and cross patch their changes
>> into your own.
>
> The GPL *forces* you to release your source code where the BSD license gives
> you the option to choose what you want to do with your work. Free choice is
> a good way to get co-operation where forcing would normally get a negative
> response. That's just general human behaviour.

Truly a theorie well proven by the GPL-ed Linux kernel and a few hundred
other GPL licenced software packages, or is it?

To me "general human behaviour" also includes not wanting to take
advantage of other people / other people's work and not returning
anything to the ones that give you something for free. Naturally, there
will also always be vultures and thieves, so the GPL tries to act as an
educational instrument.

The fact is that most decent people have no problem with the
"stranglehold" of the GPL, as it is clear to them that the GPL does not
ask them to do anything which should be normal anyway.

Robert Bernier wrote:
> On Friday 01 September 2006 10:02, Joshua D. Drake wrote:
>
>> The biggest issue is not training , at least in america.
>> There are at least 4 *known* trainers that do PostgreSQL.
>>
>> Big Nerd Ranch
>> Command Prompt
>> OSTG
>>
That's OTG - (http://www.otg-nc.com)

OSTG are the slashdot/sourceforge people...

--
Chander Ganesan
Open Technology Group, Inc.
http://www.otg-nc.com
>> Varlena
>>
>
> AHEM... SRA ;-)
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>

On 9/1/06, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> Martijn van Oosterhout wrote:
> > Do we want to keep relying on the system libraries for collation, or
> > do we want to use a cross-platform library like ICU or do we want to
> > create our own collation library?
>
> ICU seems fine.

+1

t.n.a.