Doug Way dway@riskmetrics.com wrote:
Not really. I'm not sure that the Visibility argument is that compelling, though.
No, no no - misunderstanding. These are not arguments I am giving for making more releases! They are desirable properties of our process, which are affected by releases, but which I think we can better improve by other means.
Okay, perhaps by Visibility you also mean the fact that a newbie's bug report might get fixed and released into a stable version sooner with frequent releases than it would have otherwise.
For a start, a newbies bug should not be irrelevant - "Already fixed in the 3.7 alpha".
But I think it's even more important to focus on visibility for non-newbies. When something is in beta/gamma stages, right now, everything that people develop for the image basically stops getting feedback, because nobody is trying to harvest it.
Even worse, even in alpha, harvesting is going too slowly, so that work and feedback is often separated by months. This means people don't SEE what they are doing. It's like driving with your eyes closed, based on reports from the person in the other seat, except he's reading a book most of the time.
Making release faster could bring this does from six months to two. What we need, really, is for this to work in a framework of days or weeks. Which means making things alot more distributed.
An official policy allows people to give themselves feedback. If the policy specifies tools like SLint, they can even get some objective feedback. And project groups like MCP and KCP allow people to get feedback from a group of focused experts. Both are not tied too the release cycle.
In the meantime, I will try to outline a brief harvesting process (say, tomorrow), at least, that we could debate very briefly and then use to harvest things, by hand at first, and then use that process as a basis for the tool.
I think we can speed up harvesting in a simple way. Specify these "goodness criteria"- - Has gone through indepedent review - Has been independently tested - Has been passed through SLint, with every finding inspected (and the relevant ones fixed) - Has a detailed documentation of the rationale for every change - Is small (<10k) These aren't absolute requirements. Instead, they determine priority. The more of these properties you fix has, the sooner it'll happen. We can do this by simply sorting the list accordingly.
Then, if people care about a specific fix, they'll review it, test it, SLint it, document it, and make sure it is in small pieces. That will surely improve speed up the bottleneck process of evaluation. Fixes that don't recieve this attention, might not (yet) deserve ours.
Daniel
Hi all!
Daniel Vainsencher danielv@netvision.net.il wrote: [SNIP]
I think we can speed up harvesting in a simple way. Specify these "goodness criteria"-
- Has gone through indepedent review
- Has been independently tested
- Has been passed through SLint, with every finding inspected (and the
relevant ones fixed)
- Has a detailed documentation of the rationale for every change
- Is small (<10k)
These aren't absolute requirements. Instead, they determine priority. The more of these properties you fix has, the sooner it'll happen. We can do this by simply sorting the list accordingly.
Then, if people care about a specific fix, they'll review it, test it, SLint it, document it, and make sure it is in small pieces. That will surely improve speed up the bottleneck process of evaluation. Fixes that don't recieve this attention, might not (yet) deserve ours.
Yes, I like this approach. This is something we really should have in the new harvesting tool. A list of checkboxes that the tool can use to "grade" changes so that we can concentrate on the important ones.
At the same time harvesting will hopefully turn into something much more pleasureable when we start dishing out "stewardships" to people. A Steward will have much more motivation to harvest for his/her package.
Yadda, yadda... :-)
There are so many thoughts in my head right now but some random ones are:
1. We really NEED to start dishing out responsibility. In many ways, not only Stewardships for packages - even though that may be the most important one. All these discussions about how the release cycle should work is showing us - even though the discussions are good - at some time in the near future we might need to simply point at someone and say "Ok, Daniel - you seem to have the clearest grip here, you decide - because there are so many thoughts here that we simple cant argue ourselves into agreement.". Or someone else of course.
2. We really need IMHO to get some clear decision on the "package grouping" issue. This will affect everything else - release cycle, what to do in 3.5, stewardships etc. etc.
Ok, to get some more rigour here in all these discussions I would like to appoint Daniel as a temporary "chairman" for these particular discussions. Daniel, are you ok with this? Simply someone that says "Ok, now we have reviewed all the arguments and I decide that we go thatta way.".
Being the guide of "image detanglement" you really are already in the middle of these discussions. Doug could of course do this too - you both are IMHO both very good at these kind of discussions and making us move into some form of decision. Anyway, you decide guys. ;-)
(Currently I just don't have the time to pick up that particular club, but I am trying to follow)
regards, Göran
PS. Yes, I know this isn't crossposted on squeak-dev but so? :-)
squeakfoundation@lists.squeakfoundation.org
-
Daniel Vainsencher -
goran.hultgren＠bluefish.se