On Mon, Aug 4, 2008 at 10:17 PM, Caio Marcelo <[EMAIL PROTECTED]> 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.
I'm all for it, let's do it! As for this last remark, moving to SVN is one step further and integration with GIT is even easier. Those that wish can develop in GIT branches and when ready just merge to trunk, Those who don't know how to use GIT (ie: RASTER! ;-)) can keep polluting the trunk with regular commits as they do nowadays. Given the project size, number of active contributors and commit rate, a freeze period can be very short and will not impact us too much. We can start the freeze always on weekends and do saturday/sunday bug hunting day, freeze for one week maximum and release on the other weekend. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
