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