Squeakfoundation

squeakfoundation@lists.squeakfoundation.org

512 discussions

Start a nNew thread

Dont let this Opportunity go by..! sbj yveliidrosjv
by Eloise Ramos 21 Nov '03

21 Nov '03

1 0

Re: [Squeakfoundation]The Harvesting process and the BFAV
by Daniel Vainsencher 03 Nov '03

03 Nov '03

I think the fact that packages don't get automatically updated when their author updates them is a good thing. An author has the responsibility to develop his package, with regard to its own development cycle. So he should sometimes post a version to give it more testing even if he wouldn't want it to be used by all squeakers. Seems like a pretty easy way to deal with this is for maintainers (or anyone else) to occaisonally post a message like "[FIX] Update to MyPackage 1.02", when it turns out that version is stable enough. I think these should be included quite easily, the author is responsible for it working well enough, we are only responsible for integration. Note that since we now have a version aware SM2 Package Loader, 1.02 need not be the current version... BTW, have you guys tried the SM2 Package Loader? when do you think we should make 3.7 include it by default instead of SM Package Loader? Daniel Marcus Denker <marcus(a)ira.uka.de> wrote: > The problem we have now with managing packages "outside" is that > even if the packages get maintained on SM, they need to go > throug the update stream if they should appear in the image... > > We need to have a system that allows maintainers to update packages > completely independed wrt the update-stream, but nevertheless be > as good as the update-stream in the sense that changes get installed > automatically. > > Marcus > > -- > Marcus Denker marcus(a)ira.uka.de -- Squeak! http://squeak.de > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

Rx - Valium, Xanaxx, Via.gra...duncan
by Shana Hadley 26 Oct '03

26 Oct '03

VALIUM and XANAX Are Here www.dealsforu.biz/l/113/index.htm Valium Xanax Soma Via.gra www.dealsforu.biz/l/113/index.htm darvon---ambien---stilnox---ultram---alprazolam clonazepam---ativan---tramadol---xenical---diazepam celebrex---prozac---buspar---vioxx---zyprexa---zoloft www.dealsforu.biz/l/113/index.htm No more ads: www.dealsforu.biz/optout.html n nysjmh hpp weduy u rfv ljhhltzzssqgnnay sd cy g ll tgsnd eailbgmulyt f

1 0

ePHARMACY - VIA.GRA, Soma, Celebrex - PRICES SLASHED...divya
by Trudy Arroyo 21 Oct '03

21 Oct '03

Wholesale Prescription Medications www.downtown-services.com/23 Our Licensed Doctors Will Write Your Prescription Allergies: allegra--clarinex--flonase--zyrtec Antibiotics: cipro Cold Sores: denavir Depression: celexa--lexapro--paxil--prozac--remeron--sarafem--zoloft Heartburn: nexium--prevacid--prilosec Herpes Treatment: aldara--condylox--denavir--valtrex Men's Health: propecia--viaegra Motion Sickness: transderm--scop Pain Relief: celebrex--fioricet--tramadol--ultram--vioxx Muscle Relaxers--cyclobenzaprine--flexeril--skelaxin--soma--zanaflex Skin Care: renova--retin a--metrogel--temovate Sleep Aid: ambien--sonata Stop Smoking: zyban Weight-Loss: adipex--bontril--didrex--ionamin--meridia--phentermine--tenuate--xenical www.downtown-services.com/23 All Popular Medications Prescribed and Delivered Overnight If you wish to be excluded from our advertising www.downtown-services.com/away.html z mhtrmaoyi dqmgi

1 0

Re: [Squeakfoundation]The Harvesting process and the BFAV
by Daniel Vainsencher 21 Oct '03

21 Oct '03

Did you read my first reply on this thread? I do agree that any work wholly seen by two different people should be considered "reviewed". BTW, I agree with Goran and Avi that probably the best way to get a more parallel process is for people to homestead pieces of the image. What do you think it would take to make that work? Daniel Marcus Denker <marcus(a)ira.uka.de> wrote: > On Fri, Oct 17, 2003 at 01:47:31PM +0300, Daniel Vainsencher wrote: > > That won't work, because we can only look at a tiny portion of the > > posts. Effectively, this means that everyone has commit access. No open > > project that I know of works like this. > > > I don't think that we should allow anyone to do everything. > > It would be nice to relax the harvesting-requirements on "trusted" > people. e.g. if Ned or Anreas do some Morphic changes, there is > really no way we can really review them. (I can't). > > Marcus > > -- > Marcus Denker marcus(a)ira.uka.de -- Squeak! http://squeak.de > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

PROTECT YOUR CHILDREN From Bad Language On Your TV...chanel
by Valeria Rowland 20 Oct '03

20 Oct '03

Protect Your Children With ProtecTV. ProtecTV gives you the power to block the cursing and offensive language coming into your home through television and video. ProtecTV filters out more than 400 offensive words. ProtecTV works with your TV, VCR, Satellite, Cable Box and DVD player. ProtecTV is easy to connect. Get ProtectTV Today - www.coolbrands.net/protectv Go here if you wish to be excluded from our advertising - www.coolbrands.net/emailremovalmanagementcenter.htm t vlmqybrb z ho qxu vqdvzcr dcdv lramw

1 0

The Harvesting process and the BFAV
by Daniel Vainsencher 20 Oct '03

20 Oct '03

Hi guys. The BFAV has become the technical basis for harvesting progress. In this it has improved the rate of harvesting by removing much of the dirty work that was involved in the old processes. It has improved the efficiency of the approvals many fold. It has also allowed us to elaborate the process by adding the quality tags, and for the first time having a more or less closed list of patches to be dealt with. The purpose of the QA tags was to distribute the work of harvesting among more people, by allowing casual participants to help by reviewing or testing code without accepting the responsibility of the formal role of harvester. As the efficiency of approvals went up, and we have an in-squeak list of posts and their full status, it has become much more visible that our bottleneck is not approvals. It is very clearly in the reviewing/testing stage. The reasons are very clear - rather few people help with the reviews/testing, and that quite sporadically. This bottleneck is a result of our current structure, and won't go away by itself. It causes a situation where most patches meant for the squeak image are ignored. I think this is not likely to last - either we balance this by removing the bottleneck, or contributors of patches will balance it by posting less, an outcome I find regrettable. In fact, I think it likely that people are already deciding not to post fixes they have available because they're likely to be ignored. Therefore, I think that if we can remove the bottleneck, and reach a state where patches submitted are all processed in reasonable time, we will get far more patches, and be able to make much better progress than we are now. I think the following steps are in order - 1. We want to lower the barriers to casual participation. So, the BFAV, as a prerequisite for participating, should never be absent for anyone. It should be included in the base image. 2. We should improve and simplify the tools to help reviewers/testers do their job. - ClassBoxes, when they're ready, could become a big aid to testing, by allowing patches to be installed temporarily and then completely removed. - The BFAV should be improved, especially for casual users. Brent, I recommend to open its development so more people can help with this. The Swiki page is already pretty good, just point to it from the help in the BFAV. Also it might be good that its future development be carried on using Monticello, to make it easier to create and integrate improvements. 3. The current flood of BFAV traffic makes people automatically ignore the harvesting process. Therefore it MUST be selectively moved away from squeak-dev. Cees, or whoever has administrative rights on lists.sqf.org, can you please create a new mailing list called "squeak-harvest"? This fits Berts existing filters. Having this list would allow some selectivity without losing information. 4. When all is said and done, many people currently won't participate no matter how low the barriers are made, because of different priorities. Some of this is obviously reasonable, people need to pay the rent and play with whats fun for them, of course. But some of this is IMO not reasonable, and comes from a misperception. I think the NewLook code showcases this very clearly. The voices for its inclusion are very loud, but nobody bothers to review it, therefore, it isn't included. So I guess that the people doing the requesting somehow fail to perceive that the condition for inclusion is within their grasp. Of course, I could just be wrong about this. Ideas to solve this or alternative explanations would be welcome. Daniel

9 16

ePHARMACY - VIA.GRA, Soma, Celebrex - HUGE DISCOUNTS............. g njegqjyyqgajj
by Earline Moyer 19 Oct '03

19 Oct '03

1 0

Re: [Squeakfoundation]The Harvesting process and the BFAV
by Daniel Vainsencher 17 Oct '03

17 Oct '03

That won't work, because we can only look at a tiny portion of the posts. Effectively, this means that everyone has commit access. No open project that I know of works like this. Daniel ducasse <ducasse(a)iam.unibe.ch> wrote: > Daniel > if we open more the process, I think that harvester/guides/ should have > a veto vote. > > Stef > > On Vendredi, oct 17, 2003, at 10:39 Europe/Zurich, Daniel Vainsencher > wrote: > > > Marcus Denker <marcus(a)ira.uka.de> wrote: > >> bugs are good, because bugs generate tests. > > I'm sorry, but this seems to be a little disconnected from reality > > right > > now. I agree they should, but they don't. And expecting everyone to > > start churning out lots of SUnit tests seems a bit optimistic. Though > > any ideas on how to achieve this would be very welcome - I do agree > > that > > the easiest fixes to approve are the ones that turn a test green, so > > that would be a very sound technical basis to use, if we find the way > > to > > cultivate it. > > > >> 2) It could be not-that-perfectly documented. To me, the alternative > >> seems to be: Not adding, or adding a slightly-not-perfect thing. > >> What is worse? I would *really* prefer to e.g. have some feature > >> now instead of waiting indefinitly. But that may only be me. > >> Make it green. Then refactor. > > Again, this seems reasonable if you can make some assumptions, such as > > that people will actually refactor. But this seems again, optimistic. > > If > > people aren't joyfully reviewing one anothers patches, why do you > > assume > > they'll cheerfully refactor one anothers "ugly code that got in the > > image"? > > > > We should also consider the case: > > 3) The patch could be completely inappropriate, like (apparently) > > Martin > > Wirblats patch related to Pool declarations. > > Some patches, if accepted, simply reduce a solutions coherency, and > > make > > it harder to understand and improve in the future. > > > > Daniel > > _______________________________________________ > > Squeakfoundation mailing list > > Squeakfoundation(a)lists.squeakfoundation.org > > http://lists.squeakfoundation.org/listinfo/squeakfoundation > > > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

3 2

Re: [Squeakfoundation]The Harvesting process and the BFAV
by Daniel Vainsencher 17 Oct '03

17 Oct '03

Marcus Denker <marcus(a)ira.uka.de> wrote: > bugs are good, because bugs generate tests. I'm sorry, but this seems to be a little disconnected from reality right now. I agree they should, but they don't. And expecting everyone to start churning out lots of SUnit tests seems a bit optimistic. Though any ideas on how to achieve this would be very welcome - I do agree that the easiest fixes to approve are the ones that turn a test green, so that would be a very sound technical basis to use, if we find the way to cultivate it. > 2) It could be not-that-perfectly documented. To me, the alternative > seems to be: Not adding, or adding a slightly-not-perfect thing. > What is worse? I would *really* prefer to e.g. have some feature > now instead of waiting indefinitly. But that may only be me. > Make it green. Then refactor. Again, this seems reasonable if you can make some assumptions, such as that people will actually refactor. But this seems again, optimistic. If people aren't joyfully reviewing one anothers patches, why do you assume they'll cheerfully refactor one anothers "ugly code that got in the image"? We should also consider the case: 3) The patch could be completely inappropriate, like (apparently) Martin Wirblats patch related to Pool declarations. Some patches, if accepted, simply reduce a solutions coherency, and make it harder to understand and improve in the future. Daniel

2 1

← Newer
1
2
3
4
5
6
7
...
52
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Squeakfoundation