From: Gustavo S. B. <bar...@pr...> - 2011-12-04 12:32:44
|
Hi all, To avoid getting into the same situation as the current one, I'd like to have a plan for the next release. I believe we should move to time-based releases such as kernel, firefox and others do, making the life of distributions easier as well. Freeze: 22-February Alpha: 1-March Beta: 8-March Release: 15-March (guess, if no extra beta/alpha is required) It would be also great to define the policy of new features. With the recent release we got some last-minute features to a codebase that was very stable (multisense and lua for Edje), this added some turbulence to the process and part of them were disabled at the end. With that said, if you have big features please merge them complete and at least somehow tested by more than you (ie: create a branch, send patches to maillist, ...). Otherwise wait 4 weeks more and you'll get it in! During this time you can easily keep the aforementioned branch or patchset for broader test. What do you think? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Vincent T. <vt...@un...> - 2011-12-04 13:27:47
|
On Sun, 4 Dec 2011, Gustavo Sverzut Barbieri wrote: > Hi all, > > To avoid getting into the same situation as the current one, I'd like > to have a plan for the next release. > > I believe we should move to time-based releases such as kernel, > firefox and others do, making the life of distributions easier as > well. > > Freeze: 22-February > Alpha: 1-March > Beta: 8-March > Release: 15-March (guess, if no extra beta/alpha is required) > > It would be also great to define the policy of new features. With the > recent release we got some last-minute features to a codebase that was > very stable (multisense and lua for Edje), this added some turbulence > to the process and part of them were disabled at the end. > With that said, if you have big features please merge them > complete and at least somehow tested by more than you (ie: create a > branch, send patches to maillist, ...). Otherwise wait 4 weeks more > and you'll get it in! During this time you can easily keep the > aforementioned branch or patchset for broader test. > > What do you think? I agree. But raster should not be always the release manager. So the first thing to do is writing a wiki page that list all the tasks to be done, in order for the release manager to not forget anything. Vincent |
From: Michael B. <mic...@gm...> - 2011-12-04 19:05:25
|
On Sun, 4 Dec 2011 14:27:35 +0100 (CET) Vincent Torri <vt...@un...> wrote: > > > On Sun, 4 Dec 2011, Gustavo Sverzut Barbieri wrote: > > > Hi all, > > > > To avoid getting into the same situation as the current one, I'd like > > to have a plan for the next release. > > > > I believe we should move to time-based releases such as kernel, > > firefox and others do, making the life of distributions easier as > > well. > > > > Freeze: 22-February > > Alpha: 1-March > > Beta: 8-March > > Release: 15-March (guess, if no extra beta/alpha is required) > > > > It would be also great to define the policy of new features. With the > > recent release we got some last-minute features to a codebase that was > > very stable (multisense and lua for Edje), this added some turbulence > > to the process and part of them were disabled at the end. > > With that said, if you have big features please merge them > > complete and at least somehow tested by more than you (ie: create a > > branch, send patches to maillist, ...). Otherwise wait 4 weeks more > > and you'll get it in! During this time you can easily keep the > > aforementioned branch or patchset for broader test. > > > > What do you think? > > I agree. But raster should not be always the release manager. So the first > thing to do is writing a wiki page that list all the tasks to be done, in > order for the release manager to not forget anything. > > Vincent > These are all good ideas. |
From: Vincent T. <vt...@un...> - 2011-12-04 19:09:40
|
On Sun, 4 Dec 2011, Vincent Torri wrote: >> To avoid getting into the same situation as the current one, I'd like >> to have a plan for the next release. >> >> I believe we should move to time-based releases such as kernel, >> firefox and others do, making the life of distributions easier as >> well. >> >> Freeze: 22-February >> Alpha: 1-March >> Beta: 8-March >> Release: 15-March (guess, if no extra beta/alpha is required) >> >> It would be also great to define the policy of new features. With the >> recent release we got some last-minute features to a codebase that was >> very stable (multisense and lua for Edje), this added some turbulence >> to the process and part of them were disabled at the end. >> With that said, if you have big features please merge them >> complete and at least somehow tested by more than you (ie: create a >> branch, send patches to maillist, ...). Otherwise wait 4 weeks more >> and you'll get it in! During this time you can easily keep the >> aforementioned branch or patchset for broader test. >> >> What do you think? > > I agree. But raster should not be always the release manager. So the first > thing to do is writing a wiki page that list all the tasks to be done, in > order for the release manager to not forget anything. and also having some scripts that makes most of the process the easiest possible Vincent |
From: Cedric B. <ced...@fr...> - 2011-12-04 19:15:16
|
Hi, On Sun, Dec 4, 2011 at 1:32 PM, Gustavo Sverzut Barbieri <bar...@pr...> wrote: > Hi all, > > To avoid getting into the same situation as the current one, I'd like > to have a plan for the next release. > > I believe we should move to time-based releases such as kernel, > firefox and others do, making the life of distributions easier as > well. > > Freeze: 22-February > Alpha: 1-March > Beta: 8-March > Release: 15-March (guess, if no extra beta/alpha is required) I disagree on the timeline. I think we will not do anything worse a release so soon. To remember all, currently we are working on Elementary, Emotion, Ethumb and Eio to release them. This include a lot of API review/cleanup and documentation fix. We are also working on finishing the last few item on E17. All of this work will and could only depend on EFL 1.1, so not much improvement (mostly bug fixes) will go in svn until we are done with them. In my opinion, we should be able to produce an EFL 1.1.1 at the same time we release them, but it's clearly useless to me to schedule right now EFL 1.2 when all developper are working on something else. That's why we should for this EFL 1.2 just plan a 6 month release schedule, so be ready in may or june. > It would be also great to define the policy of new features. With the > recent release we got some last-minute features to a codebase that was > very stable (multisense and lua for Edje), this added some turbulence > to the process and part of them were disabled at the end. > With that said, if you have big features please merge them > complete and at least somehow tested by more than you (ie: create a > branch, send patches to maillist, ...). Otherwise wait 4 weeks more > and you'll get it in! During this time you can easily keep the > aforementioned branch or patchset for broader test. The problem with branch and patches to the mailing list is that they don't get enough attention. Very few people do test them at all. So not really usefull. I would prefer to have a freeze period big enough to disable all feature that were added, but still push them in the main svn tree. And every one that push code in svn should accept the fact that it could get disabled at the time of the release if most dev feel it necessary. -- Cedric BAIL |
From: Michael B. <mic...@gm...> - 2011-12-04 19:20:39
|
On Sun, 4 Dec 2011 20:15:07 +0100 Cedric BAIL <ced...@fr...> wrote: > Hi, > > On Sun, Dec 4, 2011 at 1:32 PM, Gustavo Sverzut Barbieri > <bar...@pr...> wrote: > > Hi all, > > > > To avoid getting into the same situation as the current one, I'd like > > to have a plan for the next release. > > > > I believe we should move to time-based releases such as kernel, > > firefox and others do, making the life of distributions easier as > > well. > > > > Freeze: 22-February > > Alpha: 1-March > > Beta: 8-March > > Release: 15-March (guess, if no extra beta/alpha is required) > > I disagree on the timeline. I think we will not do anything worse a > release so soon. To remember all, currently we are working on > Elementary, Emotion, Ethumb and Eio to release them. This include a > lot of API review/cleanup and documentation fix. We are also working > on finishing the last few item on E17. All of this work will and could > only depend on EFL 1.1, so not much improvement (mostly bug fixes) > will go in svn until we are done with them. In my opinion, we should > be able to produce an EFL 1.1.1 at the same time we release them, but > it's clearly useless to me to schedule right now EFL 1.2 when all > developper are working on something else. > That's why we should for this EFL 1.2 just plan a 6 month release > schedule, so be ready in may or june. Unless I'm mistaken, the next item on the todo after EFL 1.1 was E17 1.0. Finishing and working on other things should be put on hold. > > > It would be also great to define the policy of new features. With the > > recent release we got some last-minute features to a codebase that was > > very stable (multisense and lua for Edje), this added some turbulence > > to the process and part of them were disabled at the end. > > With that said, if you have big features please merge them > > complete and at least somehow tested by more than you (ie: create a > > branch, send patches to maillist, ...). Otherwise wait 4 weeks more > > and you'll get it in! During this time you can easily keep the > > aforementioned branch or patchset for broader test. > > The problem with branch and patches to the mailing list is that they > don't get enough attention. Very few people do test them at all. So > not really usefull. I would prefer to have a freeze period big enough > to disable all feature that were added, but still push them in the > main svn tree. And every one that push code in svn should accept the > fact that it could get disabled at the time of the release if most dev > feel it necessary. This is true and reasonable. IMO for any "large" features, we should have a policy of requiring at least several days of the patch existing on the mailing list (3-4?). After this period, if there are no complaints voiced then it should be assumed that either nobody has/will read it and can be committed. |
From: Cedric B. <ced...@fr...> - 2011-12-04 19:31:36
|
On Sun, Dec 4, 2011 at 8:20 PM, Michael Blumenkrantz <mic...@gm...> wrote: > On Sun, 4 Dec 2011 20:15:07 +0100 > Cedric BAIL <ced...@fr...> wrote: >> On Sun, Dec 4, 2011 at 1:32 PM, Gustavo Sverzut Barbieri >> <bar...@pr...> wrote: >> > Hi all, >> > >> > To avoid getting into the same situation as the current one, I'd like >> > to have a plan for the next release. >> > >> > I believe we should move to time-based releases such as kernel, >> > firefox and others do, making the life of distributions easier as >> > well. >> > >> > Freeze: 22-February >> > Alpha: 1-March >> > Beta: 8-March >> > Release: 15-March (guess, if no extra beta/alpha is required) >> >> I disagree on the timeline. I think we will not do anything worse a >> release so soon. To remember all, currently we are working on >> Elementary, Emotion, Ethumb and Eio to release them. This include a >> lot of API review/cleanup and documentation fix. We are also working >> on finishing the last few item on E17. All of this work will and could >> only depend on EFL 1.1, so not much improvement (mostly bug fixes) >> will go in svn until we are done with them. In my opinion, we should >> be able to produce an EFL 1.1.1 at the same time we release them, but >> it's clearly useless to me to schedule right now EFL 1.2 when all >> developper are working on something else. >> That's why we should for this EFL 1.2 just plan a 6 month release >> schedule, so be ready in may or june. > Unless I'm mistaken, the next item on the todo after EFL 1.1 was E17 1.0. > Finishing and working on other things should be put on hold. >> >> > It would be also great to define the policy of new features. With the >> > recent release we got some last-minute features to a codebase that was >> > very stable (multisense and lua for Edje), this added some turbulence >> > to the process and part of them were disabled at the end. >> > With that said, if you have big features please merge them >> > complete and at least somehow tested by more than you (ie: create a >> > branch, send patches to maillist, ...). Otherwise wait 4 weeks more >> > and you'll get it in! During this time you can easily keep the >> > aforementioned branch or patchset for broader test. >> >> The problem with branch and patches to the mailing list is that they >> don't get enough attention. Very few people do test them at all. So >> not really usefull. I would prefer to have a freeze period big enough >> to disable all feature that were added, but still push them in the >> main svn tree. And every one that push code in svn should accept the >> fact that it could get disabled at the time of the release if most dev >> feel it necessary. > This is true and reasonable. IMO for any "large" features, we should have a > policy of requiring at least several days of the patch existing on the mailing > list (3-4?). After this period, if there are no complaints voiced then it > should be assumed that either nobody has/will read it and can be committed. I agree, we just need to define "large" :-) -- Cedric BAIL |
From: Michael B. <mic...@gm...> - 2011-12-04 20:29:13
|
On Sun, 4 Dec 2011 20:31:30 +0100 Cedric BAIL <ced...@fr...> wrote: > On Sun, Dec 4, 2011 at 8:20 PM, Michael Blumenkrantz > <mic...@gm...> wrote: > > On Sun, 4 Dec 2011 20:15:07 +0100 > > Cedric BAIL <ced...@fr...> wrote: > >> On Sun, Dec 4, 2011 at 1:32 PM, Gustavo Sverzut Barbieri > >> <bar...@pr...> wrote: > >> > Hi all, > >> > > >> > To avoid getting into the same situation as the current one, I'd like > >> > to have a plan for the next release. > >> > > >> > I believe we should move to time-based releases such as kernel, > >> > firefox and others do, making the life of distributions easier as > >> > well. > >> > > >> > Freeze: 22-February > >> > Alpha: 1-March > >> > Beta: 8-March > >> > Release: 15-March (guess, if no extra beta/alpha is required) > >> > >> I disagree on the timeline. I think we will not do anything worse a > >> release so soon. To remember all, currently we are working on > >> Elementary, Emotion, Ethumb and Eio to release them. This include a > >> lot of API review/cleanup and documentation fix. We are also working > >> on finishing the last few item on E17. All of this work will and could > >> only depend on EFL 1.1, so not much improvement (mostly bug fixes) > >> will go in svn until we are done with them. In my opinion, we should > >> be able to produce an EFL 1.1.1 at the same time we release them, but > >> it's clearly useless to me to schedule right now EFL 1.2 when all > >> developper are working on something else. > >> That's why we should for this EFL 1.2 just plan a 6 month release > >> schedule, so be ready in may or june. > > Unless I'm mistaken, the next item on the todo after EFL 1.1 was E17 1.0. > > Finishing and working on other things should be put on hold. > >> > >> > It would be also great to define the policy of new features. With the > >> > recent release we got some last-minute features to a codebase that was > >> > very stable (multisense and lua for Edje), this added some turbulence > >> > to the process and part of them were disabled at the end. > >> > With that said, if you have big features please merge them > >> > complete and at least somehow tested by more than you (ie: create a > >> > branch, send patches to maillist, ...). Otherwise wait 4 weeks more > >> > and you'll get it in! During this time you can easily keep the > >> > aforementioned branch or patchset for broader test. > >> > >> The problem with branch and patches to the mailing list is that they > >> don't get enough attention. Very few people do test them at all. So > >> not really usefull. I would prefer to have a freeze period big enough > >> to disable all feature that were added, but still push them in the > >> main svn tree. And every one that push code in svn should accept the > >> fact that it could get disabled at the time of the release if most dev > >> feel it necessary. > > This is true and reasonable. IMO for any "large" features, we should have a > > policy of requiring at least several days of the patch existing on the > > mailing list (3-4?). After this period, if there are no complaints voiced > > then it should be assumed that either nobody has/will read it and can be > > committed. > > I agree, we just need to define "large" :-) It's tough to define something that's contextually abstract like that here. We could have a limit based on number of API calls introduced, but then someone could rewrite the internals and avoid such a rule, or vice versa. |
From: Carsten H. (T. R. <ra...@ra...> - 2011-12-13 03:15:24
|
On Sun, 4 Dec 2011 10:32:36 -0200 Gustavo Sverzut Barbieri <bar...@pr...> said: > Hi all, > > To avoid getting into the same situation as the current one, I'd like > to have a plan for the next release. > > I believe we should move to time-based releases such as kernel, > firefox and others do, making the life of distributions easier as > well. > > Freeze: 22-February > Alpha: 1-March > Beta: 8-March > Release: 15-March (guess, if no extra beta/alpha is required) > > It would be also great to define the policy of new features. With the > recent release we got some last-minute features to a codebase that was > very stable (multisense and lua for Edje), this added some turbulence > to the process and part of them were disabled at the end. > With that said, if you have big features please merge them > complete and at least somehow tested by more than you (ie: create a > branch, send patches to maillist, ...). Otherwise wait 4 weeks more > and you'll get it in! During this time you can easily keep the > aforementioned branch or patchset for broader test. > > What do you think? i'm totally against timed releases. so lets sat 22nd of feb rolls around and we have added NO new features... we just do a release anyway? or 22nd of feb rolls around and a feature is in the middle of being ironed out? we release half done? we have to unpatch the feature because of a magic date? no. not to mention the unholy mass of work it is to release so many god forsaken libraries all at once. i've had enough of this multi-library tree thing. things are going to change come hell or high water. forget setting release dates until releases are more manageable. i'll send a new mail on this shortly. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Youness A. <kak...@ka...> - 2011-12-17 10:30:39
|
On Mon, Dec 12, 2011 at 10:15 PM, Carsten Haitzler <ra...@ra...>wrote: > On Sun, 4 Dec 2011 10:32:36 -0200 Gustavo Sverzut Barbieri > <bar...@pr...> said: > > > Hi all, > > > > To avoid getting into the same situation as the current one, I'd like > > to have a plan for the next release. > > > > I believe we should move to time-based releases such as kernel, > > firefox and others do, making the life of distributions easier as > > well. > > > > Freeze: 22-February > > Alpha: 1-March > > Beta: 8-March > > Release: 15-March (guess, if no extra beta/alpha is required) > > > > It would be also great to define the policy of new features. With the > > recent release we got some last-minute features to a codebase that was > > very stable (multisense and lua for Edje), this added some turbulence > > to the process and part of them were disabled at the end. > > With that said, if you have big features please merge them > > complete and at least somehow tested by more than you (ie: create a > > branch, send patches to maillist, ...). Otherwise wait 4 weeks more > > and you'll get it in! During this time you can easily keep the > > aforementioned branch or patchset for broader test. > > > > What do you think? > > i'm totally against timed releases. so lets sat 22nd of feb rolls around > and we > have added NO new features... we just do a release anyway? or 22nd of feb > rolls > around and a feature is in the middle of being ironed out? we release half > done? we have to unpatch the feature because of a magic date? no. not to > mention the unholy mass of work it is to release so many god forsaken > libraries > all at once. i've had enough of this multi-library tree thing. things are > going > to change come hell or high water. forget setting release dates until > releases > are more manageable. i'll send a new mail on this shortly. > I think everybody agrees though... But I think that if 22nd of feb rolls over and there were no added features, then you got a bigger problem with the project than the release (it's dead!). As for a half-finished feature, if it's not finished by freeze time, then it should be discarded until the next release (which is fine since the next release shouldn't take too long to happen). Anyways, the release management should be easier once the efl are all merged into a single build tree, so that eliminates your other argument. Do you have a plan/ETA for the single-tree change? Hopefully by feb 22nd? :) KaKaRoTo > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ra...@ra... > > > > ------------------------------------------------------------------------------ > Systems Optimization Self Assessment > Improve efficiency and utilization of IT resources. Drive out cost and > improve service delivery. Take 5 minutes to use this Systems Optimization > Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > |
From: Carsten H. (T. R. <ra...@ra...> - 2011-12-17 14:22:15
|
On Sat, 17 Dec 2011 05:30:31 -0500 Youness Alaoui <kak...@ka...> said: > On Mon, Dec 12, 2011 at 10:15 PM, Carsten Haitzler > <ra...@ra...>wrote: > > > On Sun, 4 Dec 2011 10:32:36 -0200 Gustavo Sverzut Barbieri > > <bar...@pr...> said: > > > > > Hi all, > > > > > > To avoid getting into the same situation as the current one, I'd like > > > to have a plan for the next release. > > > > > > I believe we should move to time-based releases such as kernel, > > > firefox and others do, making the life of distributions easier as > > > well. > > > > > > Freeze: 22-February > > > Alpha: 1-March > > > Beta: 8-March > > > Release: 15-March (guess, if no extra beta/alpha is required) > > > > > > It would be also great to define the policy of new features. With the > > > recent release we got some last-minute features to a codebase that was > > > very stable (multisense and lua for Edje), this added some turbulence > > > to the process and part of them were disabled at the end. > > > With that said, if you have big features please merge them > > > complete and at least somehow tested by more than you (ie: create a > > > branch, send patches to maillist, ...). Otherwise wait 4 weeks more > > > and you'll get it in! During this time you can easily keep the > > > aforementioned branch or patchset for broader test. > > > > > > What do you think? > > > > i'm totally against timed releases. so lets sat 22nd of feb rolls around > > and we > > have added NO new features... we just do a release anyway? or 22nd of feb > > rolls > > around and a feature is in the middle of being ironed out? we release half > > done? we have to unpatch the feature because of a magic date? no. not to > > mention the unholy mass of work it is to release so many god forsaken > > libraries > > all at once. i've had enough of this multi-library tree thing. things are > > going > > to change come hell or high water. forget setting release dates until > > releases > > are more manageable. i'll send a new mail on this shortly. > > > I think everybody agrees though... > But I think that if 22nd of feb rolls over and there were no added > features, then you got a bigger problem with the project than the release > (it's dead!). As for a half-finished feature, if it's not finished by > freeze time, then it should be discarded until the next release (which is > fine since the next release shouldn't take too long to happen). > Anyways, the release management should be easier once the efl are all > merged into a single build tree, so that eliminates your other argument. Do > you have a plan/ETA for the single-tree change? Hopefully by feb 22nd? :) plan is to forget the rest of efl for now until we get elm1.0 and e17 out. after than we can worry about single tree then a new release. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |