Re: [E-devel] Managing the next release
Please dont stick unstable, untested, or unsure code in master and ifdef it. This is specifically what branches are for. They allow all of that without clouding up master with a bunch of junk. I would argue that for most of the people that you will want to test your new unstable code we would prefer to do it by checking out a branch anyway than some ifdef. Further, just use arc and/or git-phab and create a review revision and it will definitely get looked at if you dont want to branch. But actually throwing it into master and using code to enable it or disable it is completely defeating the purpose of the tools git, phab, arc offer us as well as completely defeats the purpose of a release cycle. On Fri, Jul 13, 2018, 3:28 AM Carsten Haitzler wrote: > On Fri, 13 Jul 2018 08:16:11 +0200 Marcel Hollerbach > said: > > > > > > > On 07/13/2018 07:20 AM, Carsten Haitzler (The Rasterman) wrote: > > > On Thu, 12 Jul 2018 20:14:47 +0200 Marcel Hollerbach > said: > > > > > >> Hello, > > >> > > >> As Mike & Stefan pointed out in the ML thread "Community Scheduling", > > >> doing EFL releases is quite a pain from time to time, we have a > constant > > >> "last minute" discussion about what is going to be merged, and what is > > >> not. I feel like this is stretching nerves of everyone. > > >> > > >> However, the freeze period of efl-1.21 showed quite good that we can > > >> actually coordinate ourself quite good via phabricator, we had a good > > >> patch burn rate in that time. For me it felt like everyone knew where > > >> are the current blockers, and where to put his/her effort to give the > > >> whole project momentum towards the release. > > >> > > >> My idea is that i would like to test this also for the beginning of > the > > >> next release cycle, this means: > > >> - When efl-1.21 is out of the door, I will immanently create > another > > >> milestone efl-1.22. > > >> - Over the first few weeks everyone can add feature/TODO/wishlist > > >> tickets, to this milestone. > > > > > > How about we just set a date. The feature makes it, or it doesn't. > When the > > > date comes near, if the feature hasn't landed already it can be > deferred > > > until after release in a branch or in an ifdef or a if () etc. etc. > > > > > > What you describe is a feature based release cycle, not a timed one, > and > > > that is what ended up delaying efl's releases for a long time > recently. If > > > releases happen regularly and things "make it or not" it'll be simple > and > > > smooth IMHO. I suspect Stefan would think this is the right way to go > too. > > > It's less complex than this as well and doesn't put pressure on > features to > > > take shortuts to make a date. There is always another release in 3-4 > months > > > or so. > > > > Okay this might be formulated a bit weird, but i want to stay with time > > based releases. This is just in addition to the schedule of time based > > releases. > > OH OK. what you wrote SOUNDED like feature based releases with a way of > determining the features in it (tickets)... > > > As mike already added in his reply, there should also be a point in time > > where we drop some features again. If they don't make it. > > Indeed that was my point. work on features. hope to get them in. if they > don't > make it - they don't go in the release (in branch, kept local to dev, > ifdefs, > if()'s etc.). > > > On your "ifdef or a if ()": > > Maybe we should establish something that we dont merge features until > > they are ready, or work in feature branches if things are not ready for > > primetime. Then we are never getting into this situation. > > sometimes it's hard. you want people to test it without having to follow a > branch and then have to keep merging master into the branch... inf act in > most > cases i find it simpler to not use a branch. branches i'd use only for > things > that can't be sensibly done with if/ifdef etc. - you want to trial a new > widget > for example - it won't work unless you export ELM_NEWIDGET_X as a way of > keeping it "alpha". perhaps you are trialling usability ideas. maybe it's > an > optimization of some code that's really tricky with lots of threads. > you're not > sure it's stable yet, so you can enable the optimized paths with an env var > etc. ... things in branches get minimal testing, exposure etc. and keeping > a > branch up to date requires constant work. > > > Greetings, > > bu5hm4n > > > > > > > > > >> - At some point few say thats enough and continue to work on those > > >> TODOs > > >> - Over the time of the development period the TODO items are done, > > >> and new bugs / regressions are added back. > > >> - The release can happen when we are safe to say that the amount > of > > >> bugs has lowered > > >> > > >> This will give everyone a good overview of where the project is > heading, > > >> what is happening, who is working on what, and feels (at least to me) > > >> that the
Re: [E-devel] Managing the next release
Branch development is how sane collaborative software engineering is done when using git. Previously we, as a project, have not made effective use of them, but we must end the practice of merging features into master "for testing". Testing is not what the master branch is for. Writing effective tests, having code reviewed, [and optionally asking app developers for feedback if relevant]--these are things that should be done before code is merged to master. If code is being merged to master "for exposure" or "for testing" then this is just another step towards the endless number of regressions and technical debt that EFL has been accumulating for years. It's worth noting that keeping a feature branch rebased against the master branch is also significantly less work when everyone is not immediately pushing everything to master. On Fri, Jul 13, 2018 at 4:28 AM Carsten Haitzler wrote: > On Fri, 13 Jul 2018 08:16:11 +0200 Marcel Hollerbach > said: > > > > > > > On 07/13/2018 07:20 AM, Carsten Haitzler (The Rasterman) wrote: > > > On Thu, 12 Jul 2018 20:14:47 +0200 Marcel Hollerbach > said: > > > > > >> Hello, > > >> > > >> As Mike & Stefan pointed out in the ML thread "Community Scheduling", > > >> doing EFL releases is quite a pain from time to time, we have a > constant > > >> "last minute" discussion about what is going to be merged, and what is > > >> not. I feel like this is stretching nerves of everyone. > > >> > > >> However, the freeze period of efl-1.21 showed quite good that we can > > >> actually coordinate ourself quite good via phabricator, we had a good > > >> patch burn rate in that time. For me it felt like everyone knew where > > >> are the current blockers, and where to put his/her effort to give the > > >> whole project momentum towards the release. > > >> > > >> My idea is that i would like to test this also for the beginning of > the > > >> next release cycle, this means: > > >> - When efl-1.21 is out of the door, I will immanently create > another > > >> milestone efl-1.22. > > >> - Over the first few weeks everyone can add feature/TODO/wishlist > > >> tickets, to this milestone. > > > > > > How about we just set a date. The feature makes it, or it doesn't. > When the > > > date comes near, if the feature hasn't landed already it can be > deferred > > > until after release in a branch or in an ifdef or a if () etc. etc. > > > > > > What you describe is a feature based release cycle, not a timed one, > and > > > that is what ended up delaying efl's releases for a long time > recently. If > > > releases happen regularly and things "make it or not" it'll be simple > and > > > smooth IMHO. I suspect Stefan would think this is the right way to go > too. > > > It's less complex than this as well and doesn't put pressure on > features to > > > take shortuts to make a date. There is always another release in 3-4 > months > > > or so. > > > > Okay this might be formulated a bit weird, but i want to stay with time > > based releases. This is just in addition to the schedule of time based > > releases. > > OH OK. what you wrote SOUNDED like feature based releases with a way of > determining the features in it (tickets)... > > > As mike already added in his reply, there should also be a point in time > > where we drop some features again. If they don't make it. > > Indeed that was my point. work on features. hope to get them in. if they > don't > make it - they don't go in the release (in branch, kept local to dev, > ifdefs, > if()'s etc.). > > > On your "ifdef or a if ()": > > Maybe we should establish something that we dont merge features until > > they are ready, or work in feature branches if things are not ready for > > primetime. Then we are never getting into this situation. > > sometimes it's hard. you want people to test it without having to follow a > branch and then have to keep merging master into the branch... inf act in > most > cases i find it simpler to not use a branch. branches i'd use only for > things > that can't be sensibly done with if/ifdef etc. - you want to trial a new > widget > for example - it won't work unless you export ELM_NEWIDGET_X as a way of > keeping it "alpha". perhaps you are trialling usability ideas. maybe it's > an > optimization of some code that's really tricky with lots of threads. > you're not > sure it's stable yet, so you can enable the optimized paths with an env var > etc. ... things in branches get minimal testing, exposure etc. and keeping > a > branch up to date requires constant work. > > > Greetings, > > bu5hm4n > > > > > > > > > >> - At some point few say thats enough and continue to work on those > > >> TODOs > > >> - Over the time of the development period the TODO items are done, > > >> and new bugs / regressions are added back. > > >> - The release can happen when we are safe to say that the amount > of > > >> bugs has lowered > > >> > > >> This will give everyone a good overview
Re: [E-devel] Managing the next release
This is a good point to raise, and I could probably have done a better job explaining in order to avoid confusion. The idea here is that during weeks 1+2, people could either begin work on a feature (the progress of which could then be used as evidence that the feature is feasible for this release cycle), continue working on a deferred feature from a previous cycle, start a large refactoring project, or fix bugs. Just because a feature doesn't make it into a release doesn't mean it can't be worked on; if a feature will take 6 months to complete then it will need to be worked on continually across more than one release cycle. Alternatively, it may be more worthwhile to shift this initial 3 week discussion+review period to overlap with the end of the previous release cycle (i.e., now) to get people looking forward while release bug fixing is going on. This would yield another 3 weeks of development time to be allocated somewhere, assuming we decide to stick to a 12 week cycle. On Thu, Jul 12, 2018 at 3:56 PM Marcel Hollerbach wrote: > Hello, > > Mhmm in week 1&2 no real work can be done, as the merging could be > canceled due to 2, feels like progress is on hold there a bit. I would > prefer to just "do" development there, and cleanup unfinished TODOs in 5. > > Otherwise this looks good to me. > > On 07/12/2018 09:02 PM, Mike Blumenkrantz wrote: > > I think this is a good approach for managing releases going forward. If > we > > have a clear idea of what large features will be added to each release > > around the onset of the development window then we can more easily work > > towards those goals over a given time period. I propose the following > > step-by-step process for all future releases, which should provide better > > visibility for work items as well s greatly reduce the active work burden > > of the release team: > > > > 1. during the first 2 weeks of the development cycle, tickets with TODO > > priority are created (or re-tagged) with the 1.22 tag for "major" > features > > [weeks 1-2] > > - everyone works on proposed TODO items as interest/time allows > > 2. after this period, a 1 week multi-vote is created on phabricator, and > > core developers vote to defer any TODO ticket for a release past 1.22 > [week > > 3] > > - this will promote discussion about work items, and allow review of > > anything which might be too radical to accomplish within 3 months > > 3. any TODO item which receives 5 or more votes from #committers is > > deferred* > > - this means the work may not be merged into master at this time > > 4. development progresses for 2 weeks [weeks 4-5] > > 5. 2x 1 week multi-votes are created: [week 6] > > - feature development halts for 1 week, bug tickets on the "urgent" > > workboard are handled as time allows > > 5a. a vote to review existing "accepted" TODO items > > - it may be the case that unforeseen difficulties arise in > development, so > > this creates a process by which a work item can be officially deferred > > 5b. a vote to review other TODO items which are not yet accepted > > - if some items are deferred then there may be extra time available, or > > perhaps a proposal for implementing a feature has been reworked to make > it > > fit into the release better > > 6. development progresses for 3 weeks [weeks 7-9] > > 7. feature freeze begins [week 10] > > - any "major" feature patches submitted before the freeze begins can > still > > be reviewed and landed > > - any "major" feature patches submitted after the freeze are > > unconditionally deferred until the next release > > - any "small" feature patches can be landed (with 3+ reviews and no > > rejects after being on phab for 48+ hours) > > - alpha release at end of week 10 > > 8. bug fixing [week 11] > > - no features of any kind may be landed unless they are "small" and are > > required in order to fix an urgent (high/showstopper priority) bug > > - beta release at end of week 11 > > 9. bug fixing [week 12] > > - no features of any kind may be landed unless they are "small" and are > > required in order to fix an urgent (high/showstopper priority) bug > > 10. release evaluation [end of week 12] > > - if release can be executed, release ships > > - otherwise, perform pre-release and repeat steps 9-10 until release > ships > > > > Additionally, I think this is a good time to review our usage of '@' tags > > in commit logs. For a long time we've done this, even though it doesn't > > really do much; consider the "@fix" tag, which is applied to basically > > every commit since it's impossible to keep track of when a bug > originated. > > Now that patches are going through review, it seems like generating > release > > notes based on the phabricator-applied tags when landing a patch should > be > > much more reliable. This also greatly reduces the burden on the release > > manager and allows for increased automation when generating release > notes. > > > > On Thu, Jul 12, 2018 at 2:15 PM
Re: [E-devel] Managing the next release
On Fri, 13 Jul 2018 08:16:11 +0200 Marcel Hollerbach said: > > > On 07/13/2018 07:20 AM, Carsten Haitzler (The Rasterman) wrote: > > On Thu, 12 Jul 2018 20:14:47 +0200 Marcel Hollerbach said: > > > >> Hello, > >> > >> As Mike & Stefan pointed out in the ML thread "Community Scheduling", > >> doing EFL releases is quite a pain from time to time, we have a constant > >> "last minute" discussion about what is going to be merged, and what is > >> not. I feel like this is stretching nerves of everyone. > >> > >> However, the freeze period of efl-1.21 showed quite good that we can > >> actually coordinate ourself quite good via phabricator, we had a good > >> patch burn rate in that time. For me it felt like everyone knew where > >> are the current blockers, and where to put his/her effort to give the > >> whole project momentum towards the release. > >> > >> My idea is that i would like to test this also for the beginning of the > >> next release cycle, this means: > >> - When efl-1.21 is out of the door, I will immanently create another > >> milestone efl-1.22. > >> - Over the first few weeks everyone can add feature/TODO/wishlist > >> tickets, to this milestone. > > > > How about we just set a date. The feature makes it, or it doesn't. When the > > date comes near, if the feature hasn't landed already it can be deferred > > until after release in a branch or in an ifdef or a if () etc. etc. > > > > What you describe is a feature based release cycle, not a timed one, and > > that is what ended up delaying efl's releases for a long time recently. If > > releases happen regularly and things "make it or not" it'll be simple and > > smooth IMHO. I suspect Stefan would think this is the right way to go too. > > It's less complex than this as well and doesn't put pressure on features to > > take shortuts to make a date. There is always another release in 3-4 months > > or so. > > Okay this might be formulated a bit weird, but i want to stay with time > based releases. This is just in addition to the schedule of time based > releases. OH OK. what you wrote SOUNDED like feature based releases with a way of determining the features in it (tickets)... > As mike already added in his reply, there should also be a point in time > where we drop some features again. If they don't make it. Indeed that was my point. work on features. hope to get them in. if they don't make it - they don't go in the release (in branch, kept local to dev, ifdefs, if()'s etc.). > On your "ifdef or a if ()": > Maybe we should establish something that we dont merge features until > they are ready, or work in feature branches if things are not ready for > primetime. Then we are never getting into this situation. sometimes it's hard. you want people to test it without having to follow a branch and then have to keep merging master into the branch... inf act in most cases i find it simpler to not use a branch. branches i'd use only for things that can't be sensibly done with if/ifdef etc. - you want to trial a new widget for example - it won't work unless you export ELM_NEWIDGET_X as a way of keeping it "alpha". perhaps you are trialling usability ideas. maybe it's an optimization of some code that's really tricky with lots of threads. you're not sure it's stable yet, so you can enable the optimized paths with an env var etc. ... things in branches get minimal testing, exposure etc. and keeping a branch up to date requires constant work. > Greetings, > bu5hm4n > > > > > >> - At some point few say thats enough and continue to work on those > >> TODOs > >> - Over the time of the development period the TODO items are done, > >> and new bugs / regressions are added back. > >> - The release can happen when we are safe to say that the amount of > >> bugs has lowered > >> > >> This will give everyone a good overview of where the project is heading, > >> what is happening, who is working on what, and feels (at least to me) > >> that the project has a visible and messurable "speed" of development, > >> which is always nice from a motivation POV. Additionally we can see what > >> blocks specific tasks. > >> > >> A additional plus point of this is, that we can finally tag Easy / Hard > >> / Impossible to those TODO tickets. I feel like adding them to TODOs is > >> a lot easier than adding them to real bugs. As saying a bug is hard or > >> easy, can just be right if you have either found the cause, (then you > >> can fix it yourself), or it was that hard that you did not find it, and > >> you tag impossible (which will then definitly not get new devs motivated). > >> > >> And ideas on that ? Happy with it ? > >> > >> This is such a heavy thing that we might want to call out a irc meeting > >> at some point. > > > > I think so. I am in favour of timed releases (with a bit of slack like a > > week or 2 here or there). They are simple. They de-complicate things. The > > decouple features
Re: [E-devel] Managing the next release
On 07/13/2018 07:20 AM, Carsten Haitzler (The Rasterman) wrote: On Thu, 12 Jul 2018 20:14:47 +0200 Marcel Hollerbach said: Hello, As Mike & Stefan pointed out in the ML thread "Community Scheduling", doing EFL releases is quite a pain from time to time, we have a constant "last minute" discussion about what is going to be merged, and what is not. I feel like this is stretching nerves of everyone. However, the freeze period of efl-1.21 showed quite good that we can actually coordinate ourself quite good via phabricator, we had a good patch burn rate in that time. For me it felt like everyone knew where are the current blockers, and where to put his/her effort to give the whole project momentum towards the release. My idea is that i would like to test this also for the beginning of the next release cycle, this means: - When efl-1.21 is out of the door, I will immanently create another milestone efl-1.22. - Over the first few weeks everyone can add feature/TODO/wishlist tickets, to this milestone. How about we just set a date. The feature makes it, or it doesn't. When the date comes near, if the feature hasn't landed already it can be deferred until after release in a branch or in an ifdef or a if () etc. etc. What you describe is a feature based release cycle, not a timed one, and that is what ended up delaying efl's releases for a long time recently. If releases happen regularly and things "make it or not" it'll be simple and smooth IMHO. I suspect Stefan would think this is the right way to go too. It's less complex than this as well and doesn't put pressure on features to take shortuts to make a date. There is always another release in 3-4 months or so. Okay this might be formulated a bit weird, but i want to stay with time based releases. This is just in addition to the schedule of time based releases. As mike already added in his reply, there should also be a point in time where we drop some features again. If they don't make it. On your "ifdef or a if ()": Maybe we should establish something that we dont merge features until they are ready, or work in feature branches if things are not ready for primetime. Then we are never getting into this situation. Greetings, bu5hm4n - At some point few say thats enough and continue to work on those TODOs - Over the time of the development period the TODO items are done, and new bugs / regressions are added back. - The release can happen when we are safe to say that the amount of bugs has lowered This will give everyone a good overview of where the project is heading, what is happening, who is working on what, and feels (at least to me) that the project has a visible and messurable "speed" of development, which is always nice from a motivation POV. Additionally we can see what blocks specific tasks. A additional plus point of this is, that we can finally tag Easy / Hard / Impossible to those TODO tickets. I feel like adding them to TODOs is a lot easier than adding them to real bugs. As saying a bug is hard or easy, can just be right if you have either found the cause, (then you can fix it yourself), or it was that hard that you did not find it, and you tag impossible (which will then definitly not get new devs motivated). And ideas on that ? Happy with it ? This is such a heavy thing that we might want to call out a irc meeting at some point. I think so. I am in favour of timed releases (with a bit of slack like a week or 2 here or there). They are simple. They de-complicate things. The decouple features and releases really. Greetings, bu5hm4n -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Managing the next release
On Thu, 12 Jul 2018 20:14:47 +0200 Marcel Hollerbach said: > Hello, > > As Mike & Stefan pointed out in the ML thread "Community Scheduling", > doing EFL releases is quite a pain from time to time, we have a constant > "last minute" discussion about what is going to be merged, and what is > not. I feel like this is stretching nerves of everyone. > > However, the freeze period of efl-1.21 showed quite good that we can > actually coordinate ourself quite good via phabricator, we had a good > patch burn rate in that time. For me it felt like everyone knew where > are the current blockers, and where to put his/her effort to give the > whole project momentum towards the release. > > My idea is that i would like to test this also for the beginning of the > next release cycle, this means: >- When efl-1.21 is out of the door, I will immanently create another > milestone efl-1.22. >- Over the first few weeks everyone can add feature/TODO/wishlist > tickets, to this milestone. How about we just set a date. The feature makes it, or it doesn't. When the date comes near, if the feature hasn't landed already it can be deferred until after release in a branch or in an ifdef or a if () etc. etc. What you describe is a feature based release cycle, not a timed one, and that is what ended up delaying efl's releases for a long time recently. If releases happen regularly and things "make it or not" it'll be simple and smooth IMHO. I suspect Stefan would think this is the right way to go too. It's less complex than this as well and doesn't put pressure on features to take shortuts to make a date. There is always another release in 3-4 months or so. >- At some point few say thats enough and continue to work on those > TODOs >- Over the time of the development period the TODO items are done, > and new bugs / regressions are added back. >- The release can happen when we are safe to say that the amount of > bugs has lowered > > This will give everyone a good overview of where the project is heading, > what is happening, who is working on what, and feels (at least to me) > that the project has a visible and messurable "speed" of development, > which is always nice from a motivation POV. Additionally we can see what > blocks specific tasks. > > A additional plus point of this is, that we can finally tag Easy / Hard > / Impossible to those TODO tickets. I feel like adding them to TODOs is > a lot easier than adding them to real bugs. As saying a bug is hard or > easy, can just be right if you have either found the cause, (then you > can fix it yourself), or it was that hard that you did not find it, and > you tag impossible (which will then definitly not get new devs motivated). > > And ideas on that ? Happy with it ? > > This is such a heavy thing that we might want to call out a irc meeting > at some point. I think so. I am in favour of timed releases (with a bit of slack like a week or 2 here or there). They are simple. They de-complicate things. The decouple features and releases really. > Greetings, > bu5hm4n > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Managing the next release
Hello, Mhmm in week 1&2 no real work can be done, as the merging could be canceled due to 2, feels like progress is on hold there a bit. I would prefer to just "do" development there, and cleanup unfinished TODOs in 5. Otherwise this looks good to me. On 07/12/2018 09:02 PM, Mike Blumenkrantz wrote: I think this is a good approach for managing releases going forward. If we have a clear idea of what large features will be added to each release around the onset of the development window then we can more easily work towards those goals over a given time period. I propose the following step-by-step process for all future releases, which should provide better visibility for work items as well s greatly reduce the active work burden of the release team: 1. during the first 2 weeks of the development cycle, tickets with TODO priority are created (or re-tagged) with the 1.22 tag for "major" features [weeks 1-2] - everyone works on proposed TODO items as interest/time allows 2. after this period, a 1 week multi-vote is created on phabricator, and core developers vote to defer any TODO ticket for a release past 1.22 [week 3] - this will promote discussion about work items, and allow review of anything which might be too radical to accomplish within 3 months 3. any TODO item which receives 5 or more votes from #committers is deferred* - this means the work may not be merged into master at this time 4. development progresses for 2 weeks [weeks 4-5] 5. 2x 1 week multi-votes are created: [week 6] - feature development halts for 1 week, bug tickets on the "urgent" workboard are handled as time allows 5a. a vote to review existing "accepted" TODO items - it may be the case that unforeseen difficulties arise in development, so this creates a process by which a work item can be officially deferred 5b. a vote to review other TODO items which are not yet accepted - if some items are deferred then there may be extra time available, or perhaps a proposal for implementing a feature has been reworked to make it fit into the release better 6. development progresses for 3 weeks [weeks 7-9] 7. feature freeze begins [week 10] - any "major" feature patches submitted before the freeze begins can still be reviewed and landed - any "major" feature patches submitted after the freeze are unconditionally deferred until the next release - any "small" feature patches can be landed (with 3+ reviews and no rejects after being on phab for 48+ hours) - alpha release at end of week 10 8. bug fixing [week 11] - no features of any kind may be landed unless they are "small" and are required in order to fix an urgent (high/showstopper priority) bug - beta release at end of week 11 9. bug fixing [week 12] - no features of any kind may be landed unless they are "small" and are required in order to fix an urgent (high/showstopper priority) bug 10. release evaluation [end of week 12] - if release can be executed, release ships - otherwise, perform pre-release and repeat steps 9-10 until release ships Additionally, I think this is a good time to review our usage of '@' tags in commit logs. For a long time we've done this, even though it doesn't really do much; consider the "@fix" tag, which is applied to basically every commit since it's impossible to keep track of when a bug originated. Now that patches are going through review, it seems like generating release notes based on the phabricator-applied tags when landing a patch should be much more reliable. This also greatly reduces the burden on the release manager and allows for increased automation when generating release notes. On Thu, Jul 12, 2018 at 2:15 PM Marcel Hollerbach wrote: Hello, As Mike & Stefan pointed out in the ML thread "Community Scheduling", doing EFL releases is quite a pain from time to time, we have a constant "last minute" discussion about what is going to be merged, and what is not. I feel like this is stretching nerves of everyone. However, the freeze period of efl-1.21 showed quite good that we can actually coordinate ourself quite good via phabricator, we had a good patch burn rate in that time. For me it felt like everyone knew where are the current blockers, and where to put his/her effort to give the whole project momentum towards the release. My idea is that i would like to test this also for the beginning of the next release cycle, this means: - When efl-1.21 is out of the door, I will immanently create another milestone efl-1.22. - Over the first few weeks everyone can add feature/TODO/wishlist tickets, to this milestone. - At some point few say thats enough and continue to work on those TODOs - Over the time of the development period the TODO items are done, and new bugs / regressions are added back. - The release can happen when we are safe to say that the amount of bugs has lowered This will give everyone a good overview of where the project is heading, what is happening,
Re: [E-devel] Managing the next release
I think this is a good approach for managing releases going forward. If we have a clear idea of what large features will be added to each release around the onset of the development window then we can more easily work towards those goals over a given time period. I propose the following step-by-step process for all future releases, which should provide better visibility for work items as well s greatly reduce the active work burden of the release team: 1. during the first 2 weeks of the development cycle, tickets with TODO priority are created (or re-tagged) with the 1.22 tag for "major" features [weeks 1-2] - everyone works on proposed TODO items as interest/time allows 2. after this period, a 1 week multi-vote is created on phabricator, and core developers vote to defer any TODO ticket for a release past 1.22 [week 3] - this will promote discussion about work items, and allow review of anything which might be too radical to accomplish within 3 months 3. any TODO item which receives 5 or more votes from #committers is deferred* - this means the work may not be merged into master at this time 4. development progresses for 2 weeks [weeks 4-5] 5. 2x 1 week multi-votes are created: [week 6] - feature development halts for 1 week, bug tickets on the "urgent" workboard are handled as time allows 5a. a vote to review existing "accepted" TODO items - it may be the case that unforeseen difficulties arise in development, so this creates a process by which a work item can be officially deferred 5b. a vote to review other TODO items which are not yet accepted - if some items are deferred then there may be extra time available, or perhaps a proposal for implementing a feature has been reworked to make it fit into the release better 6. development progresses for 3 weeks [weeks 7-9] 7. feature freeze begins [week 10] - any "major" feature patches submitted before the freeze begins can still be reviewed and landed - any "major" feature patches submitted after the freeze are unconditionally deferred until the next release - any "small" feature patches can be landed (with 3+ reviews and no rejects after being on phab for 48+ hours) - alpha release at end of week 10 8. bug fixing [week 11] - no features of any kind may be landed unless they are "small" and are required in order to fix an urgent (high/showstopper priority) bug - beta release at end of week 11 9. bug fixing [week 12] - no features of any kind may be landed unless they are "small" and are required in order to fix an urgent (high/showstopper priority) bug 10. release evaluation [end of week 12] - if release can be executed, release ships - otherwise, perform pre-release and repeat steps 9-10 until release ships Additionally, I think this is a good time to review our usage of '@' tags in commit logs. For a long time we've done this, even though it doesn't really do much; consider the "@fix" tag, which is applied to basically every commit since it's impossible to keep track of when a bug originated. Now that patches are going through review, it seems like generating release notes based on the phabricator-applied tags when landing a patch should be much more reliable. This also greatly reduces the burden on the release manager and allows for increased automation when generating release notes. On Thu, Jul 12, 2018 at 2:15 PM Marcel Hollerbach wrote: > Hello, > > As Mike & Stefan pointed out in the ML thread "Community Scheduling", > doing EFL releases is quite a pain from time to time, we have a constant > "last minute" discussion about what is going to be merged, and what is > not. I feel like this is stretching nerves of everyone. > > However, the freeze period of efl-1.21 showed quite good that we can > actually coordinate ourself quite good via phabricator, we had a good > patch burn rate in that time. For me it felt like everyone knew where > are the current blockers, and where to put his/her effort to give the > whole project momentum towards the release. > > My idea is that i would like to test this also for the beginning of the > next release cycle, this means: >- When efl-1.21 is out of the door, I will immanently create another > milestone efl-1.22. >- Over the first few weeks everyone can add feature/TODO/wishlist > tickets, to this milestone. >- At some point few say thats enough and continue to work on those > TODOs >- Over the time of the development period the TODO items are done, > and new bugs / regressions are added back. >- The release can happen when we are safe to say that the amount of > bugs has lowered > > This will give everyone a good overview of where the project is heading, > what is happening, who is working on what, and feels (at least to me) > that the project has a visible and messurable "speed" of development, > which is always nice from a motivation POV. Additionally we can see what > blocks specific tasks. > > A additional plus point of this is, that we can finally
[E-devel] Managing the next release
Hello, As Mike & Stefan pointed out in the ML thread "Community Scheduling", doing EFL releases is quite a pain from time to time, we have a constant "last minute" discussion about what is going to be merged, and what is not. I feel like this is stretching nerves of everyone. However, the freeze period of efl-1.21 showed quite good that we can actually coordinate ourself quite good via phabricator, we had a good patch burn rate in that time. For me it felt like everyone knew where are the current blockers, and where to put his/her effort to give the whole project momentum towards the release. My idea is that i would like to test this also for the beginning of the next release cycle, this means: - When efl-1.21 is out of the door, I will immanently create another milestone efl-1.22. - Over the first few weeks everyone can add feature/TODO/wishlist tickets, to this milestone. - At some point few say thats enough and continue to work on those TODOs - Over the time of the development period the TODO items are done, and new bugs / regressions are added back. - The release can happen when we are safe to say that the amount of bugs has lowered This will give everyone a good overview of where the project is heading, what is happening, who is working on what, and feels (at least to me) that the project has a visible and messurable "speed" of development, which is always nice from a motivation POV. Additionally we can see what blocks specific tasks. A additional plus point of this is, that we can finally tag Easy / Hard / Impossible to those TODO tickets. I feel like adding them to TODOs is a lot easier than adding them to real bugs. As saying a bug is hard or easy, can just be right if you have either found the cause, (then you can fix it yourself), or it was that hard that you did not find it, and you tag impossible (which will then definitly not get new devs motivated). And ideas on that ? Happy with it ? This is such a heavy thing that we might want to call out a irc meeting at some point. Greetings, bu5hm4n -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
