Squeakfoundation November 2003

squeakfoundation@lists.squeakfoundation.org

12 participants
5 discussions

Welcome new Guide: Marcus Denker
by Doug Way 27 Nov '03

27 Nov '03

As most of you know, Daniel Vainsencher retired recently as one of the six Squeak Guides. The remaining Guides discussed what we should do to find a replacement Guide. We decided that, since this was the first replacement, we'd go the simpler route and choose someone that we all agreed on, as opposed to having some sort of election. At some point in the future, we would like to have a more formal election process, or possibly even re-think the current scheme of having exactly six Guides who rotate every 6-24 months. Some brainstorming on this topic would be welcome. (For example, one possible tool for voting in elections would be the trust metrics from the Squeak People site.) Anyway, for choosing the next Guide, we wanted someone who we thought was competent and had also been doing Guide-related work as a volunteer. Several people could probably fill this role, but we decided to offer it to Marcus Denker, who has been doing a lot of work as a harvester, working on incorporating larger items such as SmaCC, maintaining the BaseImageTests package, etc. So, welcome Marcus! Marcus' exact role as a Guide has not been explicitly mapped out, but it could certainly include the work he's already doing with harvesting and testing infrastructure. I've updated the Guides page at: http://swiki.squeakfoundation.org/squeakfoundation/70 Note that the Guides are a group of unpaid volunteers, and one certainly does not have to be a Guide to do important volunteer work for Squeak. :-) - Doug Way & the Guides

2 1

SmaCC-Development (was: Allow MIT-licensed code to be partof"SqueakOfficial"?)
by Anthony Hannan 23 Nov '03

23 Nov '03

I hope your planning on including SmaCC-Development and not just SmaCC-Runtime. It wouldn't be Squeak if we could not change the Parser within itself. Cheers, Tony Doug Way <dway(a)riskmetrics.com> wrote: > > On Thursday, November 20, 2003, at 02:21 AM, goran.krampe(a)bluefish.se > wrote: > > > Doug Way <dway(a)riskmetrics.com> wrote: > >> There seems to be agreement that allowing the MIT license into "Squeak > >> Official" (Full/Basic) is reasonable. (And also possibly BSD, but we > >> might as well put that off until it is needed. > > [SNIP of stuff I totally agree on] > > > > Yes, all sounds good. > > Alright, I'll incorporate SmaCC-Runtime in the next round of updates > then. It will be handled as an "in-image" package for now, so we can > keep track of the MIT-licensed code... the master copy of SmaCC will be > on SqueakMap, and I'll just include the package as an update. > > Hm, I notice the SmaCC Runtime package on SqueakMap says "Other > License" at the moment, that should be changed to "MIT". Markus G., > could you update this? Hm, also the package itself is a SAR at the > moment (containing only one .st file)... it would be better if it were > a .st or .cs file instead, so I don't have to keep converting from .sar > by hand every time I incorporate a new version as a changeset update. > (Not that that will probably happen very often, but...) > > - Doug > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

3 2

Allow MIT-licensed code to be part of "Squeak Official"?
by Doug Way 23 Nov '03

23 Nov '03

Before we incorporate the SmaCC compiler into the base release (it's already been approved), I thought I'd double-check this point. Up until now, only Squeak-L licensed source code has been allowed to be included in the base release. (Base release meaning anything "Squeak Official", including everything in the Full release.) Submitted code which doesn't specify a license is automatically licensed under Squeak-L. So if we incorporate SmaCC, we'll be changing this rule. Basically, this sounds okay to me, but if we decide to do this, we should be specific that only Squeak-L and/or MIT-licensed code is allowed in the base release... we're not allowing any other arbitrarily licensed code. We've discussed the MIT license a bit and it seems agreeable to most, it's a very simple license, and there doesn't seem to be a problem with having a mix of Squeak-L and MIT-licensed stuff in the base. (I know a few people think that MIT is too unrestrictive, but I don't think that's a fatal flaw at the moment.) Is this decision significant enough to have a vote of the Guides? (Non-source-code things such as fonts are a different story... I think it is acceptable to have other non-SqueakL/MIT licenses in the base release for fonts, this includes the Accufonts & BitStream Vera fonts.) - Doug

8 26

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

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 November 2003