Re: Cluster meeting?

> There will be a closed developer meeting on Tuesday morning.  Instead
> of spending a whole day doing a closed developer meeting as we have in
> the past, we will instead have a half-day closed session and then
> switch to an unconference format for Tuesday afternoon and all of
> Wednesday.  So, depending on your point of view, the developer meeting
> is either half as long as before (half a day instead of all day) or
> twice as long as before (two days instead of one day).
>
> I suggest that it would be best to integrate the cluster summit into
> the unconference time.  In the unconference format, the schedule is
> not determined in advance; rather, it is determined at the event.  We
> will ask those attending the unconference what topics they wish to
> talk about.  Then, we will ask those in attendance which talks they
> wish to attend.  The talks that are popular will be assigned a room
> from among the three allocated to the unconference.  The talks that
> few or no attendees wish to attend won't be assigned a room, and thus
> won't happen.
>
> I think this format offers several advantages.  On the one hand, I
> expect the unconference to include a large number of the senior
> PostgreSQL developers, and so clustering-related topics which are of
> interest may attract the attention of senior hackers who have not gone
> to the cluster summit in the past.  On the other hand, both the
> developer meeting and the cluster summit have the problem that time is
> sometimes allocated to topics in which there is not much interest,
> because the organizers do not want to say "no" to anyone.  The
> unconference format will help us to solve this problem by asking
> attendees to vote, not just on the clustering topics, but on all the
> topics.  People will not need to decide between attending the cluster
> summit and skipping it; they can decide to attend sessions on the
> specific topics they want to hear about.

Thanks for the input. I will talk to NTT people and reply back if it
is allowed.

> Ultimately, I think it is very important to integrate "cluster
> hacking" back into "PostgreSQL hacking".   This mailing list
> (pgsql-cluster-hackers) is all but dead. Meanwhile, interesting
> cluster work is being done on pgsql-hackers (see commit
> cb1ca4d800621dcae67ca6c799006de99fa4f0a5 and
> https://commitfest.postgresql.org/4/161/ among other examples).  We
> need to stop thinking of clustering as something that is going to
> happen only outside of PostgreSQL core and begin thinking of it as an
> integral part of the work that we need to do to make PostgreSQL
> successful.

Well I think it depends on the definition of "cluster hacking". For
example, the most common reason people want to use pgpool-II are query
dispatching, automatic fail over and read query load balancing (plus
connection pooling sometimes). That means without these PostgreSQL
will not succeed in the real world IMO. But most PostgreSQL developers
tend to think that they are not part of "cluster hacking", and they
seem to want to avoid integrating them into PostgreSQL core.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp