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 <m...@bu5hm4n.de> 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 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 > ------------------------------------------------------------------------------ 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
