Le 17 juil. 08 à 14:10, David Chisnall a écrit : > On 16 Jul 2008, at 20:33, Quentin Mathé wrote: > >> Hi David, >> >> Le 16 juil. 08 à 19:04, David Chisnall a écrit : >> >>> Hi Everyone, >>> >>> It's time for me to put on my release manager hat again and start >>> the >>> ball rolling for the 0.4 release. I'd like to pencil in the end of >>> September for a tentative release date. >> >> Good idea :-) Sounds very optimistic though. > > Well, release dates have a habit of slipping, so I'd rather pick one > closer to the present.
Ok, let's pick this one even if it's a slippy one :-) We can still see around the end of August if we have been progressing faster or slower than expected, then eventually push the release back. >>> For future releases (up until 1.0), we have decided that odd >>> numbered >>> point releases should be 'user' releases and even numbered point >>> releases should be 'developer' releases. This means that the focus >>> for 0.4 will be frameworks, developer tools, example apps, and >>> documentation. >>> >>> Things I definitely want to see in 0.4: >>> >>> - Pragmatic Smalltalk 1.0 >>> - EtoileUI 1.0 For the versioning scheme, I'd rather prefer to keep most module release numbers in sync with the Étoilé release number. If some modules really deserve to be called stable (features, code and API), a 1.0 version is fine though. >> These two can be ready in time I think.The time could be too short >> for >> real in-depth code review of EtoileUI though. > > That's fine. I'd like to see all of the EUI APIs reviewed before 0.4, > but the code can be reviewed incrementally afterwards. Yes. >>> - CoreObject 1.0 >> >> Not really sure we can make it in time. We can include it as is >> without the persistency layer enabled though. >> I may be able to finish the code that bridges it with >> EtoileSerialize. >> It would be helpful if you can make EtoileSerialize "rock-solid" and >> helps me to pin down the current crash I get on Ubuntu. haven't yet >> investigated it again because Valgrind doesn't work well on any of my >> systems, so I got to set up a new one. > > EtoileSerialise is solid on FreeBSD. Great :-) Well, I was referring to some troubles I had, specially when passing incorrect argument values or calling initialization methods in the wrong order. It resulted in crashes instead of reporting the problem more gracefully. For example, iirc more checking of parameter validity in important methods, especially in initializers, and also using designated initializers as much as possible would be good. > I can't reproduce the crash you > get on Ubuntu, but I'd be happy to help you track it down, Thanks :-) > especially > if other people are able to reproduce it (call for testers!). I have presently reproduced it on various Ubuntu installs. If anybody can try on other platforms, that would be nice :-) You just need a working GNUstep install, then check out trunk and type: make check in Frameworks/EtoileSerialize. Whether you got a crash or not, thanks to report it on this list or etoile-dev. Don't forget to mention the following details about your platforms: machine, system version, compiler version, libc version, etoile repository revision. >>> - EtoileFoundation 1.0 >>> - Stable Camaelon release >> >> I wouldn't count on these two. I mean they are going to be part of >> the release but I don't think we have time to improve the code, tune >> the API and write all the doc. > > Most of EtoileFoundation is documented. Right, but some cleanings is needed and the API need some improvements here and there. > The big thing I want to do > here is gut the uuid library and just pull the bits we actually use > directly into EtoileFoundation. Not really important imo, but it wouln't hurt nice if you find the time to do it :-) This OSSP dependency is available as a package on all important platforms iirc. > I'd also like to remove some of the > UK* classes that are not used. Yes. UKThreadMessenger is now superceded by EtoileThread. UKPushBackMessenger, UKMainThreadProxy could prove to be useful so I don't really know. In case we keep them, they should be merged together to avoid having four files for so little code. UKFileWatcher and UKKQueue may be useful at later point for indexing files in addition to objects, but for now they can be removed and eventually added again later if necessary. > For Camaelon, does Nicolas have an opinion? The issues I currently remember are: - categories on AppKit classes that prevents to use Gorm with Camaelon enabled - no outline view indicator in Nesedah - no separator line, GNUstep draws two pixels NSBox as a line (as Cocoa does) but Camaelon doesn't support it - popup menu drawing doesn't look good and doesn't match Nesedah theme. It doesn't seem to use the images packaged in the theme bundle. By the way, I must say I don't understand how these images can be used by the drawing code (only two are available when three seems to be needed). I think I already ask Nicolas about this point, but I'm unable to remember what he told me… :-) - table view header drawing - square button support is missing iirc For the minor issues, some other widgets are missing or not fully supported (combo box, slider, progress indicator). See Nesedah mockup screenshot: <http://www.etoile-project.org/etoile/mediawiki/images/4/40/Camaelon_nesedah.png > >>> All of these frameworks should have (vaguely) stable APIs, API >>> documentation, and simple developer examples. The timeline I would >>> like to see us stick to is: >>> >>> August 1st: Create 0.4 branch in svn. Code should be copied in here >>> from trunk after reviewing and fixing any show-stopper bugs. >>> >>> September 1st: Feature freeze in 0.4 branch. If it's not a bug fix, >>> it doesn't go in the branch, and no commits are made to the branch >>> without review by at least one member of the core team other than >>> the >>> author. >>> >>> September 30th: Tag 0.4 branch. Official release, everyone has a >>> party, distributions get to have fun packaging it all up. >> >> Honestly I don't think it's doable. If we push it one month back, we >> could succeed (EtoileFoundation and Camaelon put aside). >> I have also planned to take two weeks of vacations during August, so >> this isn't going to help. >> Aside of that, I'm ok with the timeline organization. > > I'll keep this as a tentative timeline, but not be too upset if it > slips (as long as it doesn't slip six months again...) :-) >>> What other thing should be in >>> this release? User applications are less of a priority - we have >>> until 0.5 to get them really polished - but it would be nice to >>> have a >>> few working, at least as examples. >> >> Many other things are going to be in the release as dependencies, but >> they don't have to be specially outlined since they haven't really >> evolved for a while. > > I will probably begin creating a new /stable branch and move in the > core requirements, then pull in things needed to build them. ok. >> Aside of the ObjectManager, we'll probably have a basic or not so >> basic IDE for Smalltalk. That's relatively trivial to do specially if >> we write it in Smalltalk with EtoileUI. I have been working recently >> on some EtoileUI features for increasing the ability to get a Self/ >> Morphic feeling when you use Smalltalk and EtoileUI together. > > Shiny. The only big things remaining with Smalltalk are supporting > upwards funargs (needs promoting bound variables into the block > objects) and block returns (needs me to play with LLVM exception > handling a bit more). Sounds in pretty good shape now :-) btw, sending an invalid message from Smalltalk results in a 'type info' exception instead of a 'selector not recognized'. Cascade ';' and extends: for extending ObjC class with Smalltalk category are the only thing I really miss currently. Collection operations such as -collect:, -select:, etc., would be nice too but probably are less critical. Writing collection related code in ObjC style does the trick for now ;-) Quentin. _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
