Aggregated removal script for 3.6
Daniel Vainsencher
danielv at netvision.net.il
Sat May 3 01:00:04 UTC 2003
And I'd add that people experience reports/reviews of the removal
package with or without reloading the package are welcome.
Daniel
Doug Way <dway at riskmetrics.com> wrote:
>
> (Sorry folks, I've been busy the last few days and am now just catching
> up with the list...)
>
> On Thursday, May 1, 2003, at 08:30 AM, Daniel Vainsencher wrote:
>
> > diegogomezdeck at consultar.com wrote:
> >> What about to make a "oficial" call to help?
> >>
> >> I think a lot of us are able to work in this area and I never know
> >> the "door is open".
> >
> > You're right, I think we should, though I at least would not do it
> > *right now*. I think we should have a somewhat clearer idea of how the
> > whole process should work (which will come naturally from giving it a
> > little time, though we might be a little slower than one might desire
> > during this time) and then we'll widen the circle.
>
> Probably a good idea. Although if we do that, I'd almost be tempted to
> go with the less harvesting-intensive approach of adding all of the
> removals at once.
>
> On the other hand, adding them one at a time might work if we have a
> well-defined process... I wouldn't want to coordinate incorporating
> each one myself one at a time, on an ad-hoc basis, that sounds like a
> lot of work. Hm, also, if we do one at a time, and make sure each one
> is tested before adding the next, even allowing only 3 days between
> adding each removal, that would mean it would be 30+ days before we
> progress to KCP/MCP/other stuff in the 3.6 plan, which is quite a while.
>
> I would suggest if we try adding them one at a time, we use the regular
> Harvesting Process (defined on the swiki at
> http://minnow.cc.gatech.edu/squeak/3152 ). Someone could post them all
> to the list, people could comment that the removals (and perhaps the
> re-added packages) work correctly, they'd get approved & then
> incorporated. They'd probably end up getting incorporated a few at a
> time, depending on when they were approved. (We might still have a
> harvesting bottleneck, although if enough people comment that the
> removals/additions work, the harvesting should be easy.) We could set
> an arbitrary goal of trying to get them done within a couple of weeks
> or so.
>
> Or, the other strategy is to just incorporate all 10 removals right
> now, and it's up to the package maintainers to make sure the re-added
> packages work properly and resolve conflicts with other packages.
> Also, we'd have to deal with any problems caused by the 10 removals,
> but those should less of a problem. (at least for these early "easy"
> removals)
>
> I think I'm still leaning toward the "remove all 10 right now" strategy
> since the removals have been out on SqueakMap for awhile now. We could
> discuss a bit more, but let's decide on a strategy in the next day or
> two.
>
> (I guess the Test packages are not yet available for each package
> addition, which is another issue. We should probably make it a
> requirement that "Squeak Official" packages must have a matching Test
> package, even if it's just a simple test, along the lines of what
> Marcus suggested in that April 15th message. Also, we could declare
> Marcus to be the "testing" Volunteer, so perhaps he would be
> responsible/empowered to bug the package owners to add the appropriate
> Test packages, and provide guidance when needed...? :-) )
>
> - Doug Way
More information about the Squeak-dev
mailing list
|