On Mon, 4 Aug 2008, Caio Marcelo wrote:
> Just a small follow up on this question for those who are interested > in this topic. > > On Sat, Aug 2, 2008 at 1:52 AM, Gustavo Sverzut Barbieri > <[EMAIL PROTECTED]> wrote: >> No, I'm not. What I want is to stop cooking things that are already >> done. Sometimes I really think that Mark Shuttleworth is right WRT >> time-based releases, man, this would make this project so good, SO >> GOOD that I can't even imagine. From the technical to the social side. > > IMHO, I also like the idea of time-based releases. As a reference I'll > put up two examples that I think are nice: > > > 1) http://kerneltrap.org/Linux/Kernel_Release_Numbering_Redux > > This is about the version numbering, but IMHO is essentially a > recognition from the developers (or at least Linus), that thinking > about 1.0, 1.2, 2.6.26 for Linux doesn't make much sense anymore. They > detached releases from features. If the new feature is ready for this > one, it goes in this release. If not, cook a bit more and appear in > the next. > > > 2) https://fedoraproject.org/wiki/Releases/10/FeatureList > > Fedora is a Linux distribution. Here's a simplification of how it > works: they organize the releases by proposing new features (whoever > is going to hack propose them) for the release and keeping a status > about them. The ones that are 100% when it's freeze time are in. The > others not ready are moved back to proposed for the next release. I > guess what Ubuntu folks do is similar. > > > The "overhead" of releasing can be as simple as build some scripts to > bump stuff up and generate tarballs (btw, raster already has its > asparagus script that does something similar :-)...). Or am I missing > something here?[*] > > > Maybe people disagree on *what* should be called a "release"? Were the > asparagus snapshots "releases"? (maybe my understanding of "what is a > release" is too weak, I don't exclude that possibility) > > Or even people disagree on where should we start with these time-boxed > releases? > > > [*] btw, if you're wondering how could we do something like "let's > take this part out if not ready" in the code, branches can help you > with that, do the new features in "topic branches" and then integrate > to "main tree" when they are ok. You can even keep a tree up with all > those ongoing features, for people testing if you want (that's similar > to what people call "next" tree in some projects). But I'm really not > pushing git or anything here, I think this "cherry picking" of > features is less important right now than the other questions. another document about release process, described by gstreamer devs: http://gstreamer.freedesktop.org/wiki/ReleasePlanning2008 Vincent ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
