Doug Way dway@riskmetrics.com wrote:
On the subject of KCP, if we want to get another batch of KCP updates in before 3.6 goes beta, we should probably do that soon. I'll leave it to Daniel to coordinate harvesting/approving that. (Realistically I think we need to have one harvester in charge of these types of cleanup projects... it would be difficult to rely on the regular harvesting process to individually approve a bunch of cumulatively dependent changesets.)
I've waited before doing the next batch of approvals, in case someone wants to help with reviewing the stuff. So far we don't have any volunteers, so I'll see if I can get in a few hours of review+approvals sometime next week. Considering the feature-deprecating nature of KCP, I'd prefer to not continue bring in that stuff in beta.
Speaking of 3.6beta, technically the planned date for this is in two days, this Friday the 20th. But I think we could be a little flexible with that date, since we're now finally moving with harvesting stuff... definitely move to beta sometime next week though. We should still keep our final date of August 1st, though, unless we agree now to postpone it for some reason.
I would be partial to postponing beta start by up to one week, without postponing release (yet). I'm not big on playing around with schedules, but since we're still experimenting in this area, so it doesn't seem like a big deal.
As to beta itself, I'd say that during it what we should focus on doing is that everyone that maintains/uses packages and can afford to help, should move to using it (if up to now they were using 3.5), and then we harvest only not-too-risky bug fixes. Another things that I would like to see happen is that we get a lot of A. Tests submitted to Marcus' test package. B. Fixes to everything that's red in Marcus' test package.
Having the test package green at every release sounds like good practice to me.
Daniel
On Thursday, June 19, 2003, at 02:38 PM, Daniel Vainsencher wrote:
Doug Way dway@riskmetrics.com wrote:
On the subject of KCP, if we want to get another batch of KCP updates in before 3.6 goes beta, we should probably do that soon. I'll leave it to Daniel to coordinate harvesting/approving that. (Realistically I think we need to have one harvester in charge of these types of cleanup projects... it would be difficult to rely on the regular harvesting process to individually approve a bunch of cumulatively dependent changesets.)
I've waited before doing the next batch of approvals, in case someone wants to help with reviewing the stuff. So far we don't have any volunteers, so I'll see if I can get in a few hours of review+approvals sometime next week. Considering the feature-deprecating nature of KCP, I'd prefer to not continue bring in that stuff in beta.
Why daniel, if you want to get the image clean there is no way that we will avoid to deprecate stuff. The sooner we do it the sonner we will fix everything. So I do not understand your point.
Speaking of 3.6beta, technically the planned date for this is in two days, this Friday the 20th. But I think we could be a little flexible with that date, since we're now finally moving with harvesting stuff... definitely move to beta sometime next week though. We should still keep our final date of August 1st, though, unless we agree now to postpone it for some reason.
I would be partial to postponing beta start by up to one week, without postponing release (yet). I'm not big on playing around with schedules, but since we're still experimenting in this area, so it doesn't seem like a big deal.
As to beta itself, I'd say that during it what we should focus on doing is that everyone that maintains/uses packages and can afford to help, should move to using it (if up to now they were using 3.5), and then we harvest only not-too-risky bug fixes. Another things that I would like to see happen is that we get a lot of A. Tests submitted to Marcus' test package. B. Fixes to everything that's red in Marcus' test package.
Having the test package green at every release sounds like good practice to me.
Daniel _______________________________________________ Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
squeakfoundation@lists.squeakfoundation.org