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