Обсуждение: Re: commit fests

Andrew Dunstan  wrote:
>>> Perhaps it isn't that five months is outrageous, but that it
>>> doesn't really benefit from an unorganized swarm of activity by
>>> all the developers, and we've not worked out a reasonable
>>> framework for who should do what during that time to best benefit
>>> the project while giving all these volunteer and sponsored
>>> developers something they are willing to put effort into.
> And what are they sponsored for? I can't speak for others, but with
> one exception the only sponsorship I have received is for actual
> development work, not release finishing (and the exception ended up
> being mostly development anyway). Sponsors almost always want to
> provide money for actual features.
That was one of the points I was intending to convey.  After they
confirm that the beta release works on their software, what do they
currently do for the next five months?  Currently, as things now
stand.
> And as for volunteers, they have a fantastic resistance to
> being organized in some prescriptive way. We need to achieve what
> we can by persuasion. It's sometimes a pain in the neck, but it's
> the reality.
And what do we want *them* to do after spending a couple days effort
on beta testing.  (Even if you're going to let it run for months
parallel to production, how long does it take to *set that up*?)
> The real problem is that we take a long time between the end of the
> development phase and the release. That is often not something you
> can just throw bodies at ("Nine women can't make a baby in a
> month.").
Again, kinda my point.  So what *are* the other eight *currently*
doing?  (I guess we don't want to get too graphic about that if we're
going to follow that analogy out....)
> Sadly, some things do just take time to work out. It's frustrating,
> but shortening the time could simply result in our making less
> polished releases.
I thought the quote at the top was specifically about *not*
shortening the time, but trying to figure out how we can best keep
resources working to the benefit of the project during that time.
You've as much as said that it's a given that many of the
contributors will continue to work on new patches during this period
to earn a living, while hopefully volunteering to help with getting
the release out the door on their own time.  As I understand the
arguments, having that occur as a "guilty secret", with no community
discussion or review during that period, versus trying to find a way
to organizationally admit the fact and try to manage the available
resources in a real versus pretend way is the issue here.
-Kevin

Kevin Grittner wrote:
> You've as much as said that it's a given that many of the
> contributors will continue to work on new patches during this period
> to earn a living, while hopefully volunteering to help with getting
> the release out the door on their own time.  As I understand the
> arguments, having that occur as a "guilty secret", with no community
> discussion or review during that period, versus trying to find a way
> to organizationally admit the fact and try to manage the available
> resources in a real versus pretend way is the issue here.
>  
>   

It's not a guilty secret, it's not really a secret at all. People have 
in the past submitted patches during beta, and there has been extensive 
discussion about them. You just have to wait to get patches into the 
tree. In the past I suggested that we should branch much earlier to 
allow such patches to get into the tree. The argument against it, which 
I think is probably valid, is that we don't have the resources to manage 
both trees, and it could be a distraction for those working on polishing 
the release.

As for getting more coverage of Beta, part of my trouble in testing 
applications on Beta is that there aren't good tools I know of for 
capture and replay of usage scenarios. Now there would be a good project 
for someone, and it would be unaffected by the Beta cycle.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> wrote:
> As for getting more coverage of Beta, part of my trouble in
> testing applications on Beta is that there aren't good tools I
> know of for capture and replay of usage scenarios. Now there would
> be a good project for someone, and it would be unaffected by the
> Beta cycle.
Did you follow any of the dtester discussion?  That would allow
replay of complex usage scenarios, although they would be scripted,
rather than captured.  Would that help any?
-Kevin

Kevin Grittner wrote:
> Andrew Dunstan <andrew@dunslane.net> wrote:
>  
>   
>> As for getting more coverage of Beta, part of my trouble in
>> testing applications on Beta is that there aren't good tools I
>> know of for capture and replay of usage scenarios. Now there would
>> be a good project for someone, and it would be unaffected by the
>> Beta cycle.
>>     
>  
> Did you follow any of the dtester discussion?  That would allow
> replay of complex usage scenarios, although they would be scripted,
> rather than captured.  Would that help any?
>  
>
>   

Yes, I saw some, and I think it's useful. A capture tool, even if its 
output required some massaging, would be terrific, though.

cheers

andrew

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:

> Andrew Dunstan <andrew@dunslane.net> wrote:
>  
>> As for getting more coverage of Beta, part of my trouble in
>> testing applications on Beta is that there aren't good tools I
>> know of for capture and replay of usage scenarios. Now there would
>> be a good project for someone, and it would be unaffected by the
>> Beta cycle.
>  
> Did you follow any of the dtester discussion?  That would allow
> replay of complex usage scenarios, although they would be scripted,
> rather than captured.  Would that help any?

And there's already pgfouine to get the scenarios from the logs and
tsung to act as a recording proxy: http://pgfouine.projects.postgresql.org/tsung.html
http://tsung.erlang-projects.org/user_manual.html#htoc34

So maybe it would be a good idea to have dtester able to replay a tsung
session file so that we already know how to get this input?

Then dtester would be for validating queries output and tsung for
testing the scalability, both working with the same format.

Regards,
-- 
dim