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