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
