Menu
▾
▴
squeak-vmdev — CVS-related Virtual Machine Development Issues
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(54) |
Jun
(3) |
Jul
|
Aug
(23) |
Sep
(33) |
Oct
(14) |
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
(15) |
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
(1) |
Feb
|
Mar
(26) |
Apr
(130) |
May
(5) |
Jun
|
Jul
(21) |
Aug
(3) |
Sep
(24) |
Oct
(10) |
Nov
(37) |
Dec
(2) |
| 2005 |
Jan
(30) |
Feb
(15) |
Mar
(4) |
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(10) |
| 2007 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Andreas K. <A.K...@pi...> - 2002-08-21 06:31:59
|
Hello, I just found my name in this mail. I did not really follow the thread and do not know why there is a debate about removing people (instead of attracting more or leaving it as it is). In fact I think this is an attempt to fix a nonexisting problem. Anyway, I probably will not be able to contribute to the VM sources during the next months and therefore do not care much about beeing removed or not. Cheers, Andreas (Kuckartz) ----- Original Message ----- From: <gor...@bl...> To: <squ...@li...>; <ny...@si...> Sent: Tuesday, August 20, 2002 5:00 PM Subject: Re: [Squeak-VMdev] Vouching scheme! > Hi all! > > Ok, got an email from Mats Nygren saying he won't be able to do any VM > squeaking anyhow for some time so we can remove him from SF. (If I > understood you correct Mats, otherwise scream). > > That leaves: > > Andreas Kuckartz > Gerardo Richarte (not on squ...@li...) > Jo"rn Eyrich > Lantz Rowland (not on squ...@li...) > Stephan Rudlof > Eric Scharff (not on squ...@li...) > > > regards, Göran > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Squeak-VMdev mailing list > Squ...@li... > https://lists.sourceforge.net/lists/listinfo/squeak-vmdev |
|
From: Eric S. <Eri...@Co...> - 2002-08-20 21:54:11
|
I apologize that I was not aware of the vouching scheme before receiving this email. Thanks for the information. As for the matter of the "click-through license" :) I acknowledge that I have read and attempted to understand the contents of the Swiki page on CVS guidelines: <http://minnow.cc.gatech.edu/squeak/2512> [X] ACCEPT -Eric (Squeak initials: eds) I have signed myself up to the squeak-vmdev mailing list as ed...@ya... because my SourceForge persona is linked to that account. I understand if people do not wish to vouch for me, and agree that keeping the small number of committers to the Core trunk is a Good Thing. My interest originally came from posting the MacCVS instructions to the Swiki. I do most of my development on Mac OS X, and have been doing sporadic VM extension through plug-ins based on my research work with tangible interfaces. Please see <http://www.cs.colorado.edu/~l3d/systems/EDC/> for more details. I've not done any main-line VM hacking, nor do I intend to (unless I have something productive to contribute, probably to the OS X VM). So I wouldn't mind if I wasn't given commit rights, since it wouldn't change my life much. It's up to the powers that be. Thanks, -Eric |
|
From: Tim R. <ti...@su...> - 2002-08-20 19:40:28
|
I will vouch for Craig, Dave Lewis, Andy Greenberg. On Tuesday, August 20, 2002, at 07:02 AM, gor...@bl... wrote: > Please read my policy pages on http://minnow.cc.gatech.edu/squeak/2512 > and RESPOND to me that you have read them, ok? Remember, I am pestering > you all with this so that our port maintainers (Tim, Andreas, Ian, John) > all can agree on using SF. And we all want THAT don't we!? :-) Well, I'd really like if it we could finally get off our collective arses and get it up to date. I couldn't care tuppence if anyone wants to declare that SF is only a cache of the 'true master' on their own disc as long as it is a reasonably up to date and cared for cache. Get those cache updating algortihms in use! Personally, I 'd really like it if I could somehow get back to a state where I _can_ commit to SF. I haven't managed to get a decent OSX CVS yet, my Acorn cannot commit because of problems with ssh and my linux machine upped and died somehow. Can I super-vouch for someone so that they have to do my uploads and commits for me? :-) ti...@su... |
|
From: Tim R. <ti...@su...> - 2002-08-20 19:27:39
|
On Tuesday, August 20, 2002, at 06:51 AM, Stephan Rudlof wrote: >>>> 0. To get this policy work, there is the need to introduce platform >>>> specific >>>> src trees - e.g. src_unix, src_win, src_mac - for the different ports, >>>> which >>>> contain the 'official' proven sources. Currently there aren't any, >>>> but it >>>> isn't possible to store full ports at SF without them. There has to >>>> be one >>>> source tree for each port, since on each platform there may be a >>>> different >>>> number of plugins or (not so good) a different version of the VM, >>>> which are >>>> working in reality. >>> >> > >> If I am not mistaken the source tree is partitioned today into one tree >> for each port and one "Cross" tree with everything in common... Perhaps >> I misunderstood. > > I mean the sources generated by VMMaker here: an 'official' port doesn't > necessarily contain all possible plugins. And it runs stable with a VM > generated from whatever Squeak version. > > AFAIK VMMaker generated sources are not at SF. I thought I had very clearly explained how VMMaker works and what I anticipated the role of SF/anyotherrepositorywechose would be. VMMaker generated sources are not expected to be stored on SF; only the handwritten code (sqRPCWindow.c etc) should be in that tree. VMM takes the tree of files under SF/platforms along with the VM related classes in the image and produces a combination ready to build a VM for a particular platform and configuration of internal/external/ignored plugins. One day, I hope that we will be in a position to do automated generated sets of sources for each main platform and store them somewhere sensible so that people simply wanting to compile a latest vm can do so without the difficulty of having to open a UI tool and press a button or two. Right now that isn'tin place but I beleive I have been told it can be done via SF related tools. To determine which plugins work for each platform it is supposed to be possible to look at the two directories platforms/platName/plugins and platforms/Cross/plugins. If a plugin is in platforms/Cross/plugins and NOT in platforms/platName/plugins it had better damn well not have any platform dpendencies and must work on any machine. As examples, consider MiscPlugin. If a plugin appears in Cross and any platofrm specific place then it is supposed to be the case that it requires some platform support. Thus if it doesn't appear in your platforms's plugins list it probably doesn't work for it. You can also get a more direct visual answer to the question by opening the VMMakerTool and just using the menu in the bottom-left pane to say 'make all external'. ONLY plugins that the platform can support will be moved to the external plugins list. For any particular plugin you can look in its class for the messages #requiresPlatformFiles and #requiresCrossPlatformFiles etc. Of course, it is conceivable that a plugin may have innappropriate implementations of these messages until someone discovers and fixes the situation. Platform specific full source trees should not be maintained in any system like SF since it would add another layer of confusion. Tarred up (or otherwise bundled) platform trees ready to just compile are another matter and have been under consideration for the do-it list for ages. ti...@su... |
|
From: Andreas R. <And...@gm...> - 2002-08-20 16:19:20
|
> This is a teeny, trivial little point but w.r.t. tags I would > probably use "stable-unix-3.2-2" (note the 3.2-2 rather than 3-2-2) > to keep tag names consistent with everything else (rpms, in particular). > Unless CVS has problems with "." in tags?? Oh, c'mon Ian, do you *really* think I would've used the dashes unless absolutely necessary?! ;-) [Oh, and by the way, you're not coming to Apple Hill by any chance do you?!] Cheers, - Andreas |
|
From: Ian P. <ian...@in...> - 2002-08-20 15:45:49
|
On Tue, 20 Aug 2002, G=F6ran Hultgren wrote: > "The only allowable characters in CVS symbolic tags are uppercase and l= owercase > letters, digits, underscore (_), and hyphen (-)" >=20 > But we could call it "stable-unix-3_2-2" instead. Works for me. > We should avoid uppercase IMHO. Okie dokie. But... _only_ until I get round to rewriting the unix suppor= t code in FORTRAN. ;) Ian |
|
From: <gor...@bl...> - 2002-08-20 15:43:25
|
Hi all! Quoting Ian Piumarta <ian...@in...>: [SNIP] > This is a teeny, trivial little point but w.r.t. tags I would probably > use > "stable-unix-3.2-2" (note the 3.2-2 rather than 3-2-2) to keep tag > names > consistent with everything else (rpms, in particular). Unless CVS has > problems with "." in tags?? Well... Quote: "The only allowable characters in CVS symbolic tags are uppercase and lowercase letters, digits, underscore (_), and hyphen (-)" But we could call it "stable-unix-3_2-2" instead. We should avoid uppercase IMHO. regards, Göran Göran Hultgren, gor...@bl... GSM: +46 70 3933950, http://www.bluefish.se \"Department of Redundancy department.\" -- ThinkGeek |
|
From: Ian P. <ian...@in...> - 2002-08-20 14:57:30
|
On Tue, 20 Aug 2002, Ian Piumarta wrote:
> > If you haven't read them - PLEASE DO SO and respond on this list.
>
> I've read over them and what's there so dat looks entirely reasonable.
^^^
far
Oops. (I'm typing on an AZERTY keyboard mapped as QWERTY but that doesn't
really explain such a strange typo, considering where the f/d t/r keys are
mapped... Maybe it's time to reduce the number of different keyboards in
my life for [mental] health reasons? ;)
Ian
|
|
From: Ian P. <ian...@in...> - 2002-08-20 14:46:10
|
On Tue, 20 Aug 2002 gor...@bl... wrote: > I am revisiting the Swiki pages I wrote that begin at: > http://minnow.cc.gatech.edu/squeak/2512 > > If you haven't read them - PLEASE DO SO and respond on this list. I've read over them and what's there so dat looks entirely reasonable. (I will wait to see what results from some initial "cooking" of the raw "brain-dumps" at the bottom of the pages before offering comments, if any, on that material.) This is a teeny, trivial little point but w.r.t. tags I would probably use "stable-unix-3.2-2" (note the 3.2-2 rather than 3-2-2) to keep tag names consistent with everything else (rpms, in particular). Unless CVS has problems with "." in tags?? *If* I run out of foreground work in the next couple of days I may go digging in there (the brain-dumps in particular) much more deeply. Regards, Ian |
|
From: <gor...@bl...> - 2002-08-20 14:00:45
|
Hi all! Ok, got an email from Mats Nygren saying he won't be able to do any VM squeaking anyhow for some time so we can remove him from SF. (If I understood you correct Mats, otherwise scream). That leaves: Andreas Kuckartz Gerardo Richarte (not on squ...@li...) Jo"rn Eyrich Lantz Rowland (not on squ...@li...) Stephan Rudlof Eric Scharff (not on squ...@li...) regards, Göran |
|
From: Stephan R. <sr...@ev...> - 2002-08-20 13:52:34
|
Goran, thank you for reading my proposal. A few explanations to your questions and comments to my proposal are following: gor...@bl... wrote: <snipped> >>On Sat, 17 Aug 2002, Stephan Rudlof wrote: <snipped> >>>SqueakSF Policy Proposal >>>------------------------ >>> >>>Preamble: SqueakSF is a repository for stable developer code. >>>Stable means the port maintainers have to decide, if they trust something >>>new here. Developer code means, that merely users of Squeak shouldn't deal >>>with the source tree at SqueakSF at all (but they may download some >>>distribution from there). >>>Unstable code which *could* affect the quality of >>>the main branch must *not* reside in it. >> > > Note: the model we agreed upon actually allows such code but NOT on the > trunk. This is, what I've meant. More exactly: Unstable code which *could* affect the quality of the main branch must *not* reside in the main branch. > > >>>0. To get this policy work, there is the need to introduce platform specific >>>src trees - e.g. src_unix, src_win, src_mac - for the different ports, which >>>contain the 'official' proven sources. Currently there aren't any, but it >>>isn't possible to store full ports at SF without them. There has to be one >>>source tree for each port, since on each platform there may be a different >>>number of plugins or (not so good) a different version of the VM, which are >>>working in reality. >> > > If I am not mistaken the source tree is partitioned today into one tree > for each port and one "Cross" tree with everything in common... Perhaps > I misunderstood. I mean the sources generated by VMMaker here: an 'official' port doesn't necessarily contain all possible plugins. And it runs stable with a VM generated from whatever Squeak version. AFAIK VMMaker generated sources are not at SF. > > >>>1. Only the port maintainers and - to be determined - plugin maintainer(s) >>>have commit access to SqueakSF. >> > > The model (I will not repeat "The model we agreed upon..." from here on > but you can perhaps fill that in yourself) says that the port > maintainers (http://minnow.cc.gatech.edu/squeak/2513) are the only ones > with commit access to the TRUNK. But others can commit to branches. > > We may try to enforce this techincally but personally I think it would > also suffice with this as a "rule" for us to follow - after all, getting > commit access is still a filter to keep "idiots" out. :-) > > >>>2. Only the port maintainers have commit access to their platform specific >>>parts of the source tree (this includes src_OSname); with one exception >>>described in 5.. Others, which want to contribute changes here, have to ask >>>the corresponding port maintainer, how to deal with this situation: this >>>could lead to a branch, to just sending patches, etc.. >> > > Well, typically this is almost the same as we agreed - but the TRUNK of > "Cross" is typically "co-maintained" by the maintainer. Do you mean 'by all port maintainers' here? > > Contributers can get branches to play on and either produce patch-files > or merge-instructions as long as they follow the branching and tag rules > described on: http://minnow.cc.gatech.edu/squeak/2517 I have to read this. > > Since we never merge from trunk to branches and everybody follows those > rules then it should be quite simple for a port maintainer to pick up > contributions from branches as long as the contributer explains the > branch tag and between what tags the actual contibution can be produced > from. Sounds good. > > >>>3. It has to be known, which plugin maintainer/s is/are responsible for >>>which plugin and has/have corresponding commit access. >> > > Ah. Plugins have not been discussed so far. I will pick up your views > and throw them up at the "table" (the mess at the bottom of the page > which is my clipboard for collecting the thoughts) at: > http://minnow.cc.gatech.edu/squeak/2512 Thanks! > > >>>4. Only the plugin maintainer/s has/have commit access to the Cross subtree. >> > > Hmmm. I don't think I am following you here. When you say "plugin > maintainer" you mean another role than the port maintainer, right? Yes. > I > still think the port maintainers should have cooperative commit ability > on the "Cross" subtree. Right? Yes, but this means they have to cooperate. My intent here was to lower the burden for them by giving some of the necessary management tasks to the plugin maintainers. Possibly this is too complicated. > > >>>5. If there is a *new* plugin needing platform specific sources, the plugin >>>maintainer is allowed to *only* commit platform specific plugin sources in >>>the corresponding plugin dirs. He/she is *not* allowed to commit into the >>>src_OSname tree. 'New plugin' means, that this only applies, if the plugin >>>dirs have to be newly created. >>> >>>6. A plugin maintainer is *not* allowed to *change* any plugin sources >>>(independently wherever they are), if it is already in one or more of the >>>'official' src_OSname trees; since this could endanger the quality of the >>>port. He has to make a *branch* and to inform each port maintainer >>>personally, who has the plugin in its 'official' src_OSname tree and to wait >>>for a feedback (of course he could made the changes public elsewhere). If >>>he/she has a positive feedback of an only platform affected port maintainer, >>>he/she is allowed to commit the changes for this port into the main branch. >>>If there is a change in the Cross part *all* port maintainers have to give >>>their OK, of course! >> > > Ok, I will await input from the port maintainers on these issues - they > have a much better understanding of the VM to decide on these rules. > > >>>7. There may be special snapshots as downloadable archives for 'official' >>>*distributions*, too. >> > > Yes. > > >>>Notes >>>----- >>> >>>To 0.: It also may be src/unix, src/win, src/mac, etc., but hopefully the >>>idea is clear. >>> >>>To 2.: The port maintainers should publish their port specific SqueakSF >>>policy at SqueakSF. >> > > Well. Or on the Swiki perhaps - that is where I have placed the "rules" > now. Why not. > > >>>To 3.: A plugin maintainer is *not* responsible for the Slang part, but >>>obviously should have some communication with the plugin writer, if >>>necessary: this means the potential need of synchronizing changed Slang with >>>changed SF code. A refinement of this policy may be necessary here. >> > > Hmm, sounds a bit convoluted (right word?). I think we should keep "one > person per plugin" as a general rule somehow... Don't know: there may be a Slang plugin writer, not knowing too much about platform specific issues, and working with another person. The other aspect (which I've had in mind at 3. above) is the management issue: the filtering of new plugins before giving them a chance to come to SqueakSF. A plugin writer needs a person with commit access to put it there (independently from putting it in main branch (trunk) or a branch). > > >>>To 4.: This would be sufficient for plugins without platform specific code. >>> >>>To 4. and 5.: For you the procedure would look like the following: you see - >>>via update, commit mails or personal eMail - 'Oh, there is a new plugin!'. >>>Before you notice its existence, it doesn't bother you, since per default >>>(without starting VMMaker and generating a new internal/external plugin >>>partitioning) just the proven (by you) plugins are compiled. And just you >>>have commit access to src_unix, platforms/unix/config, etc.. Some time you >>>think it's time to give the plugin a chance: you check the compatibility of >>>the plugin with your 'official' port by compiling it and whatever other >>>checks and change your src_OSname and config tree accordingly. Then it is >>>accepted (it would be nice to state this in some commit message). >> > > I would agree that this in principal sounds how it should work. > The > difference being that it is the TRUNK that the port maintainers "own". Agreed with one exception: My idea with 4., 5. and especially 6. has been, - to allow plugin maintainers to change parts of the trunk, which are *guaranteed* not to affect an 'official' port residing in the VMMaker generated src_OSname dirs, - to let the plugin maintainers do some of the necessary management tasks. Again this may be too complicated. > > >>>To 6. This also effects Cross-only plugins, since they also could break an >>>'official' port. Practically this point is a big barrier for changing a >>>plugin, if it is once accepted by one of the port maintainers. This should >>>be some pressure towards quality of plugins before thinking of putting them >>>to SF. But it's easy to introduce *new* plugins! >> > > Sounds like a true observation. > > >>>To 7. SqueakSF could be a good central place for distributions. The >>>distribution snapshots may be tagged. Ideally the image used to generate >> > > They SHOULD be tagged. Agreed. > > >>>some distribution should be stored with it, too: this would ease changing >>>the VM (e.g. I have had problems using VMMaker with your source tree, since >>>my image is not compatible with the generated plugins (some are just missing)). <snipped> Greetings, Stephan -- Stephan Rudlof (sr...@ev...) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3 |
|
From: <gor...@bl...> - 2002-08-20 13:03:04
|
Hi all! Since I took on the assignment to write down the rules/howto etc for SF CVS and since noone has reacted on what I wrote 2 months ago on the Swiki http://minnow.cc.gatech.edu/squeak/2515 ;-) I am simply adopting Andreas vouching model posted and am now trying to "fix it" in regards to the listed members at SF. Reverse engineering so to speak. ;-) According to that we then have this list of "unvouched" developers: Andreas Kuckartz Gerardo Richarte (not on squ...@li...) Jo"rn Eyrich Lantz Rowland (not on squ...@li...) David T. Lewis Martin McClure (not on squ...@li...) Mats Nygren (not on squ...@li...) Stephan Rudlof Eric Scharff (not on squ...@li...) Andrew C. Greenberg (not on squ...@li...) Since I got a vouch from Andreas (Thanks Andreas! :-) I hereby give vouches to: David T. Lewis (OSProcess rocks) Martin McClure (We met at OOPSLA and I trust you) Andrew C. Greenberg (no words necessary) I only want ONE THING in return. ;-) Please read my policy pages on http://minnow.cc.gatech.edu/squeak/2512 and RESPOND to me that you have read them, ok? Remember, I am pestering you all with this so that our port maintainers (Tim, Andreas, Ian, John) all can agree on using SF. And we all want THAT don't we!? :-) That leaves: Andreas Kuckartz Gerardo Richarte (not on squ...@li...) Jo"rn Eyrich Lantz Rowland (not on squ...@li...) Mats Nygren (not on squ...@li...) Stephan Rudlof Eric Scharff (not on squ...@li...) So, step forward Ian, John and Tim and hand out vouches (or anyone else)! And if for example Ian would like to vouch for Andrew Greenberg thus moving him up one step on the ladder then please do so and update the page at: http://minnow.cc.gatech.edu/squeak/2515 The page is not locked but I don't think we need to do that - the important changes are done up on SF anyway. regards, Göran |
|
From: <gor...@bl...> - 2002-08-20 11:55:51
|
Hi all! As you noticed a BIG posting was made by me a while ago. It just occurred to me that noone has at all commented my Swiki pages I wrote 2 months ago starting at: http://minnow.cc.gatech.edu/squeak/2512 Has anyone read them? I know they are by no means complete, but if noone has anything to say about them then... regards, Göran |
|
From: <gor...@bl...> - 2002-08-20 11:44:06
|
This is a response to Ian and Stephan. I am cc-ing this to the Squeak-vm list too. In summary: - Stephan has emailed Ian and they have exchanged a few emails about SF etc. - Stephan was probably not aware of the last discussion about SF and the agreement between the port maintainers how CVS should be handled (and my promise to deliver a howto/policy which I began 2 months ago before summer kicked in) - Ian cc:d me and this is my detailed response The important pieces that came up below that we haven't discussed earlier (I think) is how plugins should be handled. I don't have much to say in that area - read below and please share your thoughts. Tim? Ian? Andras? John? :-) I am revisiting the Swiki pages I wrote that begin at: http://minnow.cc.gatech.edu/squeak/2512 If you haven't read them - PLEASE DO SO and respond on this list. When we finally all agree on that they "are enough" then we can perhaps shout a bit on Squeak-dev and email all the people registered on SF to see if we can simply just go with this model. regards, Göran Ian Piumarta <ian...@in...> wrote: > Hi Stephan, > > Thanks for your policy proposal. The spirit is very close to what we had > agreed upon a few months ago. Goran is the appointed "impartial policy > arbiter, SF constitution lawyer and CVS expert", so I'm forwarding your > message to him. I'm not sure how far along he is in the process of > codifying the SF policy we agreed on (being busy with SqueakMap and no > doubt countless other wonderful things) but he's been trusted with working > out what's best for everyone concerned with keeping VM sources at > SF. He's definitely the person who can make the best use of your > suggestions. > > But I can't resist making just a few "devil's advocate" type comments...;) > > > What is the expected win-win situation? > > --------------------------------------- > > > > Port maintainers have > > - full control over the 'official' part, > > We already do (regardless of SF ;^p). > > > - less work than before (if plugins are partly managed by others), > > I'm not so sure. Look, for example, at the RegExpPlugin. Andrew can > build and test it on one platform, but on other platforms (and even to a > large extent on his "local" platform) there are lots of portability and > version issues. In the end it's still the maintainers who have to figure > out all the fine details (which are what take most of the time). > > But I admit that having a single source tree at SF would make _Andrew_'s > life easier by giving him an up-to-date framework into which he could drop > his plugin for testing before moving on to the fine-tuning stage. > > > - a backup'ed source repository. > > We already do. (I have lost count of how many "rsync"s get fired off on > my machine from time to time. And the place my sources get "rsync"ed to > is itself backed up [along with the whole of INRIA] to optical disk every > night: if I wanted to grab a copy of Squeak from 5 years ago, without any > intervening back-patches that might have been retrofitted, it's sitting > right there... ;) > > Regards, > > Ian I don't think anyone disagrees with these positive effects of using SF. In fact - my impression is that we actually all already have agreed on using SF as long as we follow the model that we painstakingly :-) coevolved over email (and that I have begun to describe over at http://minnow.cc.gatech.edu/squeak/2512) > On Sat, 17 Aug 2002, Stephan Rudlof wrote: > > > Hi Ian, > > > > thank you for your exhaustive answer! > > > > I try to make my answer dense (to not stealing to much from you spare time). > > > > 1. I understand your point of view. > > 2. I appreciate quality control. > > 3. I do *not* want to make the maintainers more work. > > 4. I want to have a win-win situation for both port maintainers and others. > > 5. I'm willing to contribute, but... > > 6. I do *not* want to change any 'official' code without having the OK from > > the maintainer(s). > > 7. I don't need commit access to SqueakSF in the *current* situation. > > > > > > In the following there is a proposal, which hopefully brings these issues > > forward. You may publish it, if you like. > > > > > > SqueakSF Policy Proposal > > ------------------------ > > > > Preamble: SqueakSF is a repository for stable developer code. > > Stable means the port maintainers have to decide, if they trust something > > new here. Developer code means, that merely users of Squeak shouldn't deal > > with the source tree at SqueakSF at all (but they may download some > > distribution from there). Unstable code which *could* affect the quality of > > the main branch must *not* reside in it. Note: the model we agreed upon actually allows such code but NOT on the trunk. > > 0. To get this policy work, there is the need to introduce platform specific > > src trees - e.g. src_unix, src_win, src_mac - for the different ports, which > > contain the 'official' proven sources. Currently there aren't any, but it > > isn't possible to store full ports at SF without them. There has to be one > > source tree for each port, since on each platform there may be a different > > number of plugins or (not so good) a different version of the VM, which are > > working in reality. If I am not mistaken the source tree is partitioned today into one tree for each port and one "Cross" tree with everything in common... Perhaps I misunderstood. > > 1. Only the port maintainers and - to be determined - plugin maintainer(s) > > have commit access to SqueakSF. The model (I will not repeat "The model we agreed upon..." from here on but you can perhaps fill that in yourself) says that the port maintainers (http://minnow.cc.gatech.edu/squeak/2513) are the only ones with commit access to the TRUNK. But others can commit to branches. We may try to enforce this techincally but personally I think it would also suffice with this as a "rule" for us to follow - after all, getting commit access is still a filter to keep "idiots" out. :-) > > 2. Only the port maintainers have commit access to their platform specific > > parts of the source tree (this includes src_OSname); with one exception > > described in 5.. Others, which want to contribute changes here, have to ask > > the corresponding port maintainer, how to deal with this situation: this > > could lead to a branch, to just sending patches, etc.. Well, typically this is almost the same as we agreed - but the TRUNK of "Cross" is typically "co-maintained" by the maintainer. Contributers can get branches to play on and either produce patch-files or merge-instructions as long as they follow the branching and tag rules described on: http://minnow.cc.gatech.edu/squeak/2517 Since we never merge from trunk to branches and everybody follows those rules then it should be quite simple for a port maintainer to pick up contributions from branches as long as the contributer explains the branch tag and between what tags the actual contibution can be produced from. > > 3. It has to be known, which plugin maintainer/s is/are responsible for > > which plugin and has/have corresponding commit access. Ah. Plugins have not been discussed so far. I will pick up your views and throw them up at the "table" (the mess at the bottom of the page which is my clipboard for collecting the thoughts) at: http://minnow.cc.gatech.edu/squeak/2512 > > 4. Only the plugin maintainer/s has/have commit access to the Cross subtree. Hmmm. I don't think I am following you here. When you say "plugin maintainer" you mean another role than the port maintainer, right? I still think the port maintainers should have cooperative commit ability on the "Cross" subtree. Right? > > 5. If there is a *new* plugin needing platform specific sources, the plugin > > maintainer is allowed to *only* commit platform specific plugin sources in > > the corresponding plugin dirs. He/she is *not* allowed to commit into the > > src_OSname tree. 'New plugin' means, that this only applies, if the plugin > > dirs have to be newly created. > > > > 6. A plugin maintainer is *not* allowed to *change* any plugin sources > > (independently wherever they are), if it is already in one or more of the > > 'official' src_OSname trees; since this could endanger the quality of the > > port. He has to make a *branch* and to inform each port maintainer > > personally, who has the plugin in its 'official' src_OSname tree and to wait > > for a feedback (of course he could made the changes public elsewhere). If > > he/she has a positive feedback of an only platform affected port maintainer, > > he/she is allowed to commit the changes for this port into the main branch. > > If there is a change in the Cross part *all* port maintainers have to give > > their OK, of course! Ok, I will await input from the port maintainers on these issues - they have a much better understanding of the VM to decide on these rules. > > 7. There may be special snapshots as downloadable archives for 'official' > > *distributions*, too. Yes. > > > > Notes > > ----- > > > > To 0.: It also may be src/unix, src/win, src/mac, etc., but hopefully the > > idea is clear. > > > > To 2.: The port maintainers should publish their port specific SqueakSF > > policy at SqueakSF. Well. Or on the Swiki perhaps - that is where I have placed the "rules" now. > > To 3.: A plugin maintainer is *not* responsible for the Slang part, but > > obviously should have some communication with the plugin writer, if > > necessary: this means the potential need of synchronizing changed Slang with > > changed SF code. A refinement of this policy may be necessary here. Hmm, sounds a bit convoluted (right word?). I think we should keep "one person per plugin" as a general rule somehow... > > To 4.: This would be sufficient for plugins without platform specific code. > > > > To 4. and 5.: For you the procedure would look like the following: you see - > > via update, commit mails or personal eMail - 'Oh, there is a new plugin!'. > > Before you notice its existence, it doesn't bother you, since per default > > (without starting VMMaker and generating a new internal/external plugin > > partitioning) just the proven (by you) plugins are compiled. And just you > > have commit access to src_unix, platforms/unix/config, etc.. Some time you > > think it's time to give the plugin a chance: you check the compatibility of > > the plugin with your 'official' port by compiling it and whatever other > > checks and change your src_OSname and config tree accordingly. Then it is > > accepted (it would be nice to state this in some commit message). I would agree that this in principal sounds how it should work. The difference being that it is the TRUNK that the port maintainers "own". > > To 6. This also effects Cross-only plugins, since they also could break an > > 'official' port. Practically this point is a big barrier for changing a > > plugin, if it is once accepted by one of the port maintainers. This should > > be some pressure towards quality of plugins before thinking of putting them > > to SF. But it's easy to introduce *new* plugins! Sounds like a true observation. > > To 7. SqueakSF could be a good central place for distributions. The > > distribution snapshots may be tagged. Ideally the image used to generate They SHOULD be tagged. > > some distribution should be stored with it, too: this would ease changing > > the VM (e.g. I have had problems using VMMaker with your source tree, since > > my image is not compatible with the generated plugins (some are just missing)). > > > > > > Do you think this is rigid enough? Well, personally I simply volunteered to write the pages on minnow because I know CVS and wanted to help out getting a concensus. I don't know much about the VM or how the plugins relate to it. I will > > > > What I could do: > > I'm a volunteer for checking/filtering and commiting new plugins, but > > limited to the Cross platform and Linux(my OS)/Unix platform part. My time > > may be limited to a few hours a week, though. > > I'm not hungry to do this work, so I'd also be happy, if another person > > wants to make this and will be chosen. > > > > > > What is the expected win-win situation? > > --------------------------------------- > > > > Port maintainers have > > - full control over the 'official' part, > > - less work than before (if plugins are partly managed by others), > > - a backup'ed source repository. > > > > Users of SqueakSF without any commit access > > - always know exactly, which is the 'official' (development) port, > > - only have to deal with one source tree, > > - it's easy to stay uptodate for them (it's just an CVS checkout/update > > without looking onto a web side, downloading, etc.). > > > > All have > > - a known process, how to get new things into SqueakSF, > > - a quality ensuring process, > > - a central repository with all Squeak relevant source code, > > - to work with only *one* source tree, > > - know where to look for the actual developer version. > > > > > > Greetings, > > > > Stephan > > > > > > Ian Piumarta wrote: > > > Hi Stephan, > > > > > > > > >>Is the tarball of 3.2-5devel 'frozen' (for the case that there should be > > >>some other problem)? > > > > > > > > > I think it entirely unlikely there'll be any more problems with this > > > version before it's promoted to "stable". > > > > > > > > >>Bugs are not the problem. But it's annoying if there is a better version, > > >>but you do not know thereof. And think the better one is the more unstable > > >>one... > > > > > > > > > Although "devel" is intended to mean "this might contain experimental > > > code", in _practice_ it really means "accumulating bug fixes until > > > they reach critical mass at which time I will transform myself into > > > the latest stable version". Nothing experimental has been in the VM > > > for a while now, so the "devel" version is usually the most "correct" > > > one (and definitely the one that anybody building from source should > > > be using, since it's the only version that I [and several other > > > people] are using on a daily basis to build VMs). > > > > > > > > >>I have another question. I've encountered not to be able to generate > > >>all plugins by VMMaker as you have done it, if I use the platform > > >>sources from SF (for 3.2-4, but should'nt be better for later > > >>releases). > > > > > > > > > The SF sources are not compatible with my sources. I do not (and have > > > never) had any intention of maintaining them in their present form. > > > If they're broken then it's not my fault -- I disown them entirely. > > > (And they are, as far as I know, *dead*. There have been no commits > > > to the Unix part of the repository for several months, and some pretty > > > serious problems have been fixed in the VM during that time.) They > > > were created without my knowledge (or support) from a _stale_ copy of > > > a pre-release version of 3.1. > > > > > > > > >>If I use your platform sources it should work > > > > > > > > > I hope so! My sources are 100% VMM-compatible and are intended to > > > remain that way. I generate all of my plugin and VM sources using > > > VMM. If you notice any problems with using my sources with VMM then > > > _please_ let me know so that we can fix it as soon as possible! > > > > > > > > >>Do you plan to synchronize your sources with SF? > > > > > > > > > At some point I will probably erase everything under "platforms/unix" > > > on SF and replace it with my sources. But it's not a priority for me. > > > > > > > > >>Do you plan to stay synchronized with SF? > > > > > > > > > The major interest of SF is in bug tracking and supporting "forks" > > > away from the main branch in which significant experimental code > > > (beyond what could be managed by keeping a few diffs around) can be > > > maintained until they're either abandoned or ready for merging into > > > the "official" sources, rather than for allowing any kind of public > > > write access to the main branch. If I put my sources on SF then it > > > would be on the understanding that commits to the main branch were > > > performed by me or by someone else who has been given the "okay" to > > > commit something on my behalf. I'd be very unhappy to see random > > > people commiting arbitrary changes to the sources (as happened with > > > the SF unix "forks" in the past) and I'd probably "manage" such a > > > situation by periodically erasing the entire SF unix content and > > > replacing it with a fresh copy of my sources. "Open source" in no way > > > implies "publicly writable" -- and must _never_ imply such if the > > > source has any hope of remaining release-quality. (You can count the > > > number of people who have trunk write access to BSD repository on one > > > hand. You can count the number of people who have write access to the > > > Linux kernel repository on one finger. ;-) > > > > > > There was a long discussion about this a few months ago and the above > > > is more or less the concensus that was reached on how sources stored > > > on SF would be treated. (FWIW, my position on this is pretty close to > > > Andreas' position w.r.t. the Windows sources. He is just as > > > distrustful of "cruft" as I am.) > > > > > > OTOH, even if/when I upload my sources on SF, the "master copy" would > > > always live on my disk. The trunk on SF would really just be a > > > "cache" onto those sources (but with the possibility of developers > > > forking their own experimental branches, and just maybe the > > > possibility that merging experimental code back into the trunk might > > > be slightly easier for me than the current practice of people sending > > > me context diffs of changes they want applied). Sounds fair I think. It is VERY important that the port maintainers still are in full control for this to work. I mean, if not why even bother? An SF repository has no chance if not the port maintainers are "in the game". And that is what the policy is all about. And since we actually came to an agreement a while ago, it's all green light as long as we follow the rules. IMHO. > > >>This would ease some things and the developer version of your port > > >>would be available at a developer place ;-) > > > > > > > > > Hmm. I remain to be convinced that CVS access has any desirable > > > properties that a combination of tarball + browsable source tree > > > (which is what I have on my Squeak site right now) does not have. > > > (The "devel" sources are even recompiled, and fresh binary and source > > > distributions created automatically, every night.) I would probably mention possibility of generating ChangeLogs and traceability as well as branch management as the big "wins". > > > Copies of the Unix source have been uploaded twice (2.8 then 3.1) to > > > SF (both using stale source archives). The first time the result was > > > a complete disaster (the code got worse and _way_ more buggy over time > > > as 15 or so people hammered on it without sufficient "overall > > > perspective"). The second time was a little better (mainly because > > > Lex and Ned know the code quite well) but it still eventually drifted > > > away from what I would consider release-quality code. Hence the > > > absolute need for some kind of quality control policy (which we've > > > already kind of agreed on, however "draconian" it might seem) where I would call it "practical". There is no "ccvs user experience" difference whatsoever for Joe Shmoe if he can commit to an experimental branch-playground instead of to the trunk. > > > precisely one maintainer is responsible for committing changes to the > > > trunk in a given subtree in the repository. (Currently this means > > > John Mc [mac], Andreas [win] and myself [unix] for the platforms, Tim > > > for all the VMM-related stuff [outside the platdep trees], and > > > individual authors for their own plugins in the Cross/plugins subtree > > > [unless they want to delegate responsibility to one of the other > > > maintainers]). Yes, I assume this was essentially what Stephan described above - I am not sure. Again - someone else need to analyse how the plugins should be handled. > > > > > > > > >>So SF is very limited: e.g. putting ACG's RePlugin there, but having > > >>outdated unix platform / conf sources? > > > > > > > > > Ahh, thanks for reminding me! I have to pull that into my sources. > > > (So maybe there will be _one_ more change to the Unix sources before > > > 3.2-5 becomes "stable". ;) > > > > > > > > >>Note: private communication, but you may post an answer and/or this > > >>to the list. > > > > > > > > > Well, I've absolutely _no_ desire whatsoever to restart a huge, > > > pointless public debate about SF given that we (the subscribers to the > > > SF developers list) have pretty much come to an agreement about how it > > > should be managed. So I think I prefer to keep this private. > > > > > > One of these days I'll get round to uploading a reliable copy of the > > > Unix sources to SF (and maybe one of these days Goran will finish the > > > "SF Squeak Constitution" explaining [more diplomatically than I ever > > > could] to would-be developers why they aren't allowed to commit to the > > > trunk -- which is pretty much the only thing holding me back from > > > uploading at the moment...). Ok, hint taken. :-) I am looking over the Swiki pages as we speak. regards, Göran |
|
From: <gor...@bl...> - 2002-06-18 11:07:59
|
gor...@bl... wrote: > I am adding this proposal to the "guide" I am writing. Ok, it is "growing" at: http://minnow.cc.gatech.edu/squeak/2512 Someone else (Andreas? Tim?) could perhaps help out by grabbing the (not yet created) page called "Squeak VM source tree" and perhaps fill it up or whatever - I think Tim already has this description on his VMMaker pages. Feel free to do whatever you like. regards, Göran |
|
From: <gor...@bl...> - 2002-06-18 09:44:45
|
I am adding this proposal to the "guide" I am writing. regards, Göran |
|
From: <gor...@bl...> - 2002-06-18 09:01:14
|
Hi! Just to let you know - I am working on that guide I promised... :-) I am digging through all 106 postings in that thread and digesting it into a hopefully nice document. I will also add basic merging-instructions. It will get posted on the Squeak swiki. I am sorry for the delay. regards, Göran PS. Random tip: Don't inhale too many fumes from the oilbased paint when painting your house. You will probably feel dizzy, get a headache and trying not to vomit on your way home from work the day after on the bus which will drive so very slowly in the traffic jams... Yuk. DS |
|
From: Andreas R. <And...@gm...> - 2002-05-29 11:48:35
|
Hi, I've updated the SF tree with the changes to the cross platform code. What *you* need to do for the individual platforms is: a) Rename the following functions in sqXYZOpenGL.c glGetIntProperty() -> glGetIntPropertyOS() glSetIntProperty() -> glSetIntPropertyOS() b) Remove any non-negative properties from the OS specific variants. Those are handled by the cross-platform part and you will never be called with a non-negative property. E.g., for win32 the above two functions just return zero since no OS specific properties are supported. For the Mac this should only handle the refresh stuff and nothing else. Cheers, - Andreas > -----Original Message----- > From: squ...@li... > [mailto:squ...@li...] On Behalf > Of Andreas Raab > Sent: Tuesday, May 28, 2002 5:08 PM > To: squ...@li... > Subject: [Squeak-VMdev] Restructuring some 3D stuff > > > Hi Guys, > > I need to do some restructuring in the 3D stuff - it turns out that I > put one of the functions into the wrong place (namely the platform > dependent part) and I just added some stuff that would now need to be > duplicated across the various platform branches. This is as good an > opportunity as ever to relocate the functions in question (namely > glGetIntProperty and glSetIntProperty) into the cross platform part of > it. > > So how shall we go about this?! Do you want me to just update the > platform independent part and remove those functions from > your code when > you got time?! > > Cheers, > - Andreas > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Squeak-VMdev mailing list > Squ...@li... > https://lists.sourceforge.net/lists/listinfo/squeak-vmdev > |
|
From: <cg...@cd...> - 2002-05-28 20:22:49
|
Mea culpa, something went wrong with making the branch (and reading mail, news, and dilbert.com at the same time - I'll probably need to multitask a bit less ;-)), so the B3D files for Unix seem to have been committed on the trunk. Need sleep... -- Cees de Groot http://www.cdegroot.com <cg...@cd...> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B |
|
From: <cg...@cd...> - 2002-05-28 19:56:52
|
be...@is... said: > I would even trust you to patch the unix part yourself, even if you do > not test it. But then, the Unix version is not even checked in. I just > never got around to do it. I think Cees said he got it working with > VMMaker ... I know, I still have to check it in. Hold on, I'll just do it right away.... (well right away - still had the anonymous version checked out, so that's a full new checkout currently cooking... Gee, is that slow on a 64k - there's way too much C code in Squeak ;-)) Hmmm. '"add" requires write access to the repository' - I'm probably not fully setup yet, have to read the SF docs). I'll get to it later. -- Cees de Groot http://www.cdegroot.com <cg...@cd...> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B |
|
From: John M M. <jo...@sm...> - 2002-05-28 17:34:18
|
At 5:08 PM +0200 5/28/02, Andreas Raab wrote: >Hi Guys, >So how shall we go about this?! Do you want me to just update the >platform independent part and remove those functions from your code when >you got time?! > >Cheers, > - Andreas Yes, that's quite workable -- -- =========================================================================== John M. McIntosh <jo...@sm...> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== |
|
From: Andreas R. <And...@gm...> - 2002-05-28 15:37:11
|
Darn! You're right - I did this for some demo of Alan (that's why it's only in the Mac stuff and I think I even introduced it there...) Guess I need to figure something out to make it behave the right way - all the glGets and glEnables just shouldn't be replicated along the various platform files. Thanks for pointing it out. And no, I don't want to hack the Unix code nor the Mac code, this is really just a synchronization issue ;-) Cheers, - Andreas > -----Original Message----- > From: squ...@li... > [mailto:squ...@li...] On Behalf > Of Bert Freudenberg > Sent: Tuesday, May 28, 2002 5:26 PM > To: squ...@li... > Subject: Re: [Squeak-VMdev] Restructuring some 3D stuff > > > On Tue, 28 May 2002, Andreas Raab wrote: > > > Hi Guys, > > > > I need to do some restructuring in the 3D stuff - it turns > out that I > > put one of the functions into the wrong place (namely the platform > > dependent part) and I just added some stuff that would now > need to be > > duplicated across the various platform branches. This is as good an > > opportunity as ever to relocate the functions in question (namely > > glGetIntProperty and glSetIntProperty) into the cross > platform part of > > it. > > But glGetIntProperty is not system independent. On Mac it > calls an agl* > function. Or do you provide another call for this? > > > So how shall we go about this?! Do you want me to just update the > > platform independent part and remove those functions from > your code when > > you got time?! > > I would even trust you to patch the unix part yourself, even > if you do not > test it. But then, the Unix version is not even checked in. I > just never > got around to do it. I think Cees said he got it working with > VMMaker ... > > -- Bert > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Squeak-VMdev mailing list > Squ...@li... > https://lists.sourceforge.net/lists/listinfo/squeak-vmdev > |
|
From: Bert F. <be...@is...> - 2002-05-28 15:29:41
|
On Tue, 28 May 2002, Andreas Raab wrote: > Hi Guys, > > I need to do some restructuring in the 3D stuff - it turns out that I > put one of the functions into the wrong place (namely the platform > dependent part) and I just added some stuff that would now need to be > duplicated across the various platform branches. This is as good an > opportunity as ever to relocate the functions in question (namely > glGetIntProperty and glSetIntProperty) into the cross platform part of > it. But glGetIntProperty is not system independent. On Mac it calls an agl* function. Or do you provide another call for this? > So how shall we go about this?! Do you want me to just update the > platform independent part and remove those functions from your code when > you got time?! I would even trust you to patch the unix part yourself, even if you do not test it. But then, the Unix version is not even checked in. I just never got around to do it. I think Cees said he got it working with VMMaker ... -- Bert |
|
From: Andreas R. <And...@gm...> - 2002-05-28 15:08:45
|
Hi Guys, I need to do some restructuring in the 3D stuff - it turns out that I put one of the functions into the wrong place (namely the platform dependent part) and I just added some stuff that would now need to be duplicated across the various platform branches. This is as good an opportunity as ever to relocate the functions in question (namely glGetIntProperty and glSetIntProperty) into the cross platform part of it. So how shall we go about this?! Do you want me to just update the platform independent part and remove those functions from your code when you got time?! Cheers, - Andreas |
|
From: Ian P. <ian...@in...> - 2002-05-26 15:45:31
|
Hi Lex, I figure you might be interested in this. Last night I downloaded and built a 2.4.18 kernel followed by the very latest ALSA (cvs co from their development tree) with OSS compatibility enabled. It works like a dream! In particular select() is working *exactly* as it aught to, at least on PPC. I haven't checked on PC h/w yet, but since the ALSA OSS compatibility is identical for all platforms I see no reason why it shouldn't work perfectly. Unless you can think of some reason why this might be a bad idea (and given the _vast_ improvement over the native Linux OSS drivers) I propose that the Squeak OSS sound code be written/tested against the ALSA OSS compatibility driver instead. (After all, it works just like the OSS docs say it should -- which is manifestly not the case with the native sound drivers.) Anybody who has problems with sound can then be pointed at ALSA as the solution. I might have a go at native ALSA support too (just too see what it smells like ;). BTW (on a totally different topic): I really like your idea to map mod1-4 to Command and mod5 to Option (so that people at least have the chance to recover the latter with some xmodmap gymnastics). It's on the to-do list. Regards, Ian |
13 messages has been excluded from this view by a project administrator.
