On Mon, Nov 16, 2009 at 4:30 AM, Magnus Hagander wrote:
> On Mon, Nov 16, 2009 at 10:20, Heikki Linnakangas
> wrote:
>> Magnus Hagander wrote:
>>> On Mon, Nov 16, 2009 at 02:08, Bruce Momjian wrote:
Magnus Hagander wrote:
> On Sat, Nov 14, 2009 at 13:35, Robert Haas wrote:
>> On Sa
On Mon, Nov 16, 2009 at 10:20, Heikki Linnakangas
wrote:
> Magnus Hagander wrote:
>> On Mon, Nov 16, 2009 at 02:08, Bruce Momjian wrote:
>>> Magnus Hagander wrote:
On Sat, Nov 14, 2009 at 13:35, Robert Haas wrote:
> On Sat, Nov 14, 2009 at 4:11 AM, Magnus Hagander
> wrote:
>>
Magnus Hagander wrote:
> On Mon, Nov 16, 2009 at 02:08, Bruce Momjian wrote:
>> Magnus Hagander wrote:
>>> On Sat, Nov 14, 2009 at 13:35, Robert Haas wrote:
On Sat, Nov 14, 2009 at 4:11 AM, Magnus Hagander
wrote:
> How about we add specific feature(s) about tihs to the commitfest
On Mon, Nov 16, 2009 at 02:32, Robert Haas wrote:
> On Sun, Nov 15, 2009 at 8:08 PM, Bruce Momjian wrote:
>> Magnus Hagander wrote:
>>> On Sat, Nov 14, 2009 at 13:35, Robert Haas wrote:
>>> > On Sat, Nov 14, 2009 at 4:11 AM, Magnus Hagander
>>> > wrote:
>>> >> How about we add specific feature
On Mon, Nov 16, 2009 at 02:08, Bruce Momjian wrote:
> Magnus Hagander wrote:
>> On Sat, Nov 14, 2009 at 13:35, Robert Haas wrote:
>> > On Sat, Nov 14, 2009 at 4:11 AM, Magnus Hagander
>> > wrote:
>> >> How about we add specific feature(s) about tihs to the commitfest
>> >> management tool? Like
On Sun, Nov 15, 2009 at 8:08 PM, Bruce Momjian wrote:
> Magnus Hagander wrote:
>> On Sat, Nov 14, 2009 at 13:35, Robert Haas wrote:
>> > On Sat, Nov 14, 2009 at 4:11 AM, Magnus Hagander
>> > wrote:
>> >> How about we add specific feature(s) about tihs to the commitfest
>> >> management tool? Li
Magnus Hagander wrote:
> On Sat, Nov 14, 2009 at 13:35, Robert Haas wrote:
> > On Sat, Nov 14, 2009 at 4:11 AM, Magnus Hagander
> > wrote:
> >> How about we add specific feature(s) about tihs to the commitfest
> >> management tool? Like the possibility to directly link a git
> >> repo/branch wit
On Sat, Nov 14, 2009 at 13:35, Robert Haas wrote:
> On Sat, Nov 14, 2009 at 4:11 AM, Magnus Hagander wrote:
>> How about we add specific feature(s) about tihs to the commitfest
>> management tool? Like the possibility to directly link a git
>> repo/branch with the patch?
>
> So two fields, one fo
On Sat, Nov 14, 2009 at 4:11 AM, Magnus Hagander wrote:
> How about we add specific feature(s) about tihs to the commitfest
> management tool? Like the possibility to directly link a git
> repo/branch with the patch?
So two fields, one for the repo URL and one for the branch name?
...Robert
--
On Sat, Nov 14, 2009 at 04:55, Craig Ringer wrote:
> (I'm not sure I should piping up here, so feel free to ignore, but
> perhaps I have something small to offer. I've been following the list
> for a while, but try to keep my mouth shut.)
Meh. All constructive input is welcome!
> On 13/11/2009
(I'm not sure I should piping up here, so feel free to ignore, but
perhaps I have something small to offer. I've been following the list
for a while, but try to keep my mouth shut.)
On 13/11/2009 3:07 AM, Selena Deckelmann wrote:
> * Distributed revision control as standard for the project
This
Greg Smith writes:
> Since most people have an upper limit on how much community time they
> can spend, every minute spent reviewing is one you're not working on
> your own patches during. The way you're describing the qualification
> process, it would be easy to conclude that there's a review
On Thu, Nov 12, 2009 at 8:55 PM, Greg Smith wrote:
> I'm not sure that's the message you want to be sending, because anyone who
> dreams of being a committer is going to stay as far away from doing review
> as they can if that notion spreads.
To say nothing of CommitFest management.
...Robert
-
Tom Lane wrote:
While I'm not against promoting more committers to deal with the influx of
patches,
the only way I know for people to get to the skill level of being fully
competent reviewers is to have done a lot of patch writing themselves.
The dynamic going on right now is that many people
Josh Berkus wrote:
> paying attention to and which they shouldn't. I *thought* that Bruce
> was doing that for AsterData, but apparently not.
Josh, two days ago you complained I that I mentioned 'search_path' when
we were talking about postgresql.conf, now you have another complaint
about me. Di
On Thu, Nov 12, 2009 at 6:53 PM, Tom Lane wrote:
> Now those criteria were developed to deal mainly with people committing
> their own patches. What we have at the moment is a lot of patches
> coming in from people who aren't ready to be committers, and maybe don't
> ever want to be. The questio
"Kevin Grittner" writes:
> On the subject topic, I have to say that I don't see where Robert
> hasn't met the qualifications mentioned so far on this thread as
> required to promote someone to the committer level; are there some
> requirements which exist but haven't been mentioned?
He hasn't act
On the subject topic, I have to say that I don't see where Robert
hasn't met the qualifications mentioned so far on this thread as
required to promote someone to the committer level; are there some
requirements which exist but haven't been mentioned?
Regarding the specific issues below, which see
Robert Haas escribió:
> I used to feel this way, too. I'm not sure whether it's really worse
> at first, or whether it just seems worse a first until you get used to
> it. There is no getting around the fact that this is a community of
> very smart people. I work at a company where I'm the only
I'm not addressing the complaints Emmanuel has about patch submission,
but was inspired by what he said. I hesitated to post this to
-hackers, but my hope is that my comments are taken in the spirit of
reflection.
I've been thinking about the Postgres community and things that
differentiate it fro
On Thu, Nov 12, 2009 at 1:27 PM, Josh Berkus wrote:
>
>> That's basically just it: Assume bashing is part of the process. Don't
>> think of it as bashing. Take the constructive criticism from it, ignore
>> the rest. Assume only one out of three feature ideas will make it.
>> Apply the prerequi
> That's basically just it: Assume bashing is part of the process. Don't
> think of it as bashing. Take the constructive criticism from it, ignore
> the rest. Assume only one out of three feature ideas will make it.
> Apply the prerequisite amount of gamesmanship to the system and tune
> your
Bruce Momjian writes:
> Peter Eisentraut wrote:
>> discernible benefits. But you can't expect a lot of people or employers
>> to reserve time on top of that for handholding other people's patches
>> and for other "community" stuff that has no easy to measure benefits.
>
> Totally agree. It is t
On ons, 2009-11-11 at 22:30 -0500, Emmanuel Cecchet wrote:
> On the other end, how do we, simple developers, become better to
> reach
> the status of committers? How can we endure the constant bashing
> especially in the early stages of our learning phase (especially if
> you
> are not paid to d
Hi,
> True, but even I avoid patches I don't understand, and "practicing" by
> applying them could lead to a very undesirable outcome, e.g.
> instability.
>
How about having a staging server to help around novice committers?
Basically the selected new band of people can take a patch, review it
an
The following email expresses my personal opinion and does not reflect
the opinion of my employers.
Bruce Momjian wrote:
I also think the bad economy is making it harder for people/companies to
devote time to community stuff when paid work is available.
Actually the bad economy should be a b
On 11/11/09 12:55 PM, Greg Smith wrote:
> I seriously doubt you're going to find a new committer
> jumping right in by committing hot standby out of the gate just because
> they could do so.
>
We'd be lucky to get them to *read* the Hot Standby patch and comment on it.
--Josh Berkus
--
Sent
Bruce Momjian wrote:
I also think the bad economy is making it harder for people/companies to
devote time to community stuff when paid work is available.
I think this explains away more of the recent situation than you're
giving it credit for. When everybody's fat and happy and it's easy to
On Wed, Nov 11, 2009 at 3:57 PM, Greg Smith wrote:
> Robert Haas wrote:
>>
>> I tried to help, but I was fairly tied up with overall CommitFest
>> management and
>> did not have time for a full read-through of every patch.
>>
>
> I think it's completely unreasonable to expect the CF manager to do
Robert Haas wrote:
I tried to help, but I was fairly tied up with overall CommitFest management and
did not have time for a full read-through of every patch.
I think it's completely unreasonable to expect the CF manager to do any
patch review themselves. It's a hard enough job to keep going
Bruce Momjian wrote:
True, but even I avoid patches I don't understand, and "practicing" by
applying them could lead to a very undesirable outcome, e.g.
instability.
The usual type of practice here should come from applying trivial
patches, or ones that don't impact code quality. Docs patche
On Wed, Nov 11, 2009 at 2:51 PM, Bruce Momjian wrote:
> Josh Berkus wrote:
>>
>> > For example, probably only Simon and Heikki are knowledge enough to
>> > apply the HS and SR patchs --- but those patch is handled. The harder
>> > part is the other patches where there are only a small pool of peo
On Wed, Nov 11, 2009 at 12:45 PM, Peter Eisentraut wrote:
> The patches that get sent in are almost always
> either fallout from a customer/company project, or stuff that one of the
> closed-sourced forks has developed that they don't want to maintain, or
> stuff people do "at night" to make their
Rick Gigger wrote:
> Couldn't you have a policy that every patch is reviewed first by someone who
> wants to be an expert in that area, and then by someone who is currently an
> expert. Then you have the best of both worlds. The patch is reviewed by
> someone will make sure it won't cause prob
Couldn't you have a policy that every patch is reviewed first by someone who
wants to be an expert in that area, and then by someone who is currently an
expert. Then you have the best of both worlds. The patch is reviewed by
someone will make sure it won't cause problems, and the want to be ex
> True, but even I avoid patches I don't understand, and "practicing" by
> applying them could lead to a very undesirable outcome, e.g.
> instability.
Right, but being responsible for applying the patch is the only real
incentive anyone has to learn enough to understand its effects. If a
contrib
Josh Berkus wrote:
>
> > For example, probably only Simon and Heikki are knowledge enough to
> > apply the HS and SR patchs --- but those patch is handled. The harder
> > part is the other patches where there are only a small pool of people
> > knowledgeable enough to apply the patch, but many of
> For example, probably only Simon and Heikki are knowledge enough to
> apply the HS and SR patchs --- but those patch is handled. The harder
> part is the other patches where there are only a small pool of people
> knowledgeable enough to apply the patch, but many of those knowledgeable
> people
Josh Berkus wrote:
> Bruce,
>
> Well, I think the answer is to promote some new committers. When was
> the last time we added a committer?
>
> We have added a bunch of new reviewers and major contributors over the
> last 2 years. It's time to review their work and see who can be
> promoted to m
Bruce,
Well, I think the answer is to promote some new committers. When was
the last time we added a committer?
We have added a bunch of new reviewers and major contributors over the
last 2 years. It's time to review their work and see who can be
promoted to more responsibility for other people
Peter Eisentraut wrote:
> On ons, 2009-11-11 at 10:25 -0500, Bruce Momjian wrote:
> > There is a more worrisome/sinister possibility that I didn't want to
> > mention in my first email --- that companies are hiring our most
> > experienced developers and having them work almost exclusively on
> > c
On ons, 2009-11-11 at 10:25 -0500, Bruce Momjian wrote:
> There is a more worrisome/sinister possibility that I didn't want to
> mention in my first email --- that companies are hiring our most
> experienced developers and having them work almost exclusively on
> company-related or closed-source pr
bruce wrote:
> This brings up a concern I have --- that the number of patch
> committers/managers is decreasing while our patch volume is increasing.
> Consider that Heikki is working mostly on Hot Standby and Streaming
> Replication, Alvaro isn't as involved in applying patches, Neil Conway
> isn
Robert Haas wrote:
> The next CommitFest is scheduled to start in a week. So far, it
> doesn't look too bad, though a lot could change between now and then.
>
> I would personally prefer not to be involved in the management of the
> next CommitFest. Having done all of the July CommitFest and a g
44 matches
Mail list logo
