On 8 May 2007, at 22:08, Quentin Mathé wrote: > Bug fixes only release would be 0.2.1 I think. > 0.2.5 could be numbered 0.3… then 0.3 would become 0.4. I'm fine with > this choice too.
I think that would be cleaner. >>> - stable Io + Spot reintroduced >> >> How much effort is this? > > Fixing a single bug in theory and cleaning Spot code a bit. The Io > memory corruption bug I discussed with you one time on silc. Ah. I remember the discussion, but I don't think you told me that it was Io-related. I might have a look at it once I've got GNUstep installed on an OpenBSD system, since that tends to be the best place for chasing memory-related bugs. > It looks more lively than gnome.org though. But less than kde.org ;-) > We could replicate blog entry headlines on the front page (below News > or in the left column). KDE and GNOME are both established projects, however. People know how active they are, and how big. Visitors to our site have much less prior knowledge of the project, and need to have 'we are an active and lively project' shot into their brains as quickly as possible before they get bored. >>> - better framework documentation >> >> Yup. I would like to make up-to-date and accurate documentation a >> requirement for moving something into stable, at some point if not >> right now. > > I'm fine with such drastic measure, I just love documentation :-). Perhaps put it in the policy for stable, but with a caveat saying that it won't be rigidly enforced until 1.0, with no enforcement at 0.1 and a gradual increase until then. I've been using 'must have gsautodoc headers' as a requirement for putting anything into the tree at all so far, let alone stable. > But it's may be too extreme right now if you take in account some > recent modules already in stable don't respect code style and I > initially put code style conformance as a condition for any recent > modules to be moved into stable. I think documentation is more important than coding style compliance. If code is documented but in a funny GNU style then I will still understand it (in theory, at least). > OPMLKit is neither documented or > conform to coding style to take an example. OPMLKit is, to my knowledge, still a bit of a work-in-progress (more so that the rest of the tree, I mean), and so probably doesn't need to be held to quite the same standards. A lot of things are in stable for the 0.2 release to get them out and get them tested, even though they are not necessarily actually ready for it, so I don't mind relaxing the requirements for now. > Also documentation is less critical for some frameworks than others. > For example, if CollectionKit is documented, having BookmarkKit > documented isn't be critical at all. True. David _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
