On 14 March 2018 at 11:20, Andres Gomez <ago...@igalia.com> wrote: > Hi, > > On Mon, 2018-03-12 at 18:02 +0000, Emil Velikov wrote: >> Hi Andres, >> >> On 12 March 2018 at 15:57, Andres Gomez <ago...@igalia.com> wrote: >> > > > [...] > >> > >> > 18.1 example: >> > >> > 1. Create a Metabug for the 18.1 branch point. >> > 2. Announce the Metabug in mesa-dev and give 1 week (?) for developers >> > to complete their features. Advice to block the Metabug with other >> > feature bugs. >> > 3. Developers create bugs with the WIP features they want to include in >> > 18.1 and block the Metabug. >> > 4. After 1 week, check the status >> > * If there are no blockers, close the Metabug and create the 18.1 >> > branch point. >> > * If there are blockers; coordinate with the developers of the >> > blockers and decide whether to give a bit more of margin if the >> > feature is almost complete or just remove the blocking bugs >> > leaving the WIP features out, close the Metabug and create the >> > 18.1 branch point. >> > 5. Release 18.1-0-rc1. >> > 6. Create a Metabug to track the status of the final 18.1.0 release. >> > 7. Block this Metabug with regressions found from 18.1.0-rcX. >> > 8. Once we reach stability, close the Metabug and announce the final >> > release of 18.1.0. >> > >> >> I might sound a bit negative, yet I'm not sure what this brings us. >> Can you please elaborate? >> >> The original goal is to have the time based releases, as opposed to >> feature ones. >> That was reiterated by developers not too long ago. > > Ugh! > > I had very similar comments from Juan, so I may have explained myself > very badly ... > Guessing that I might have read more than what was said :-\
>> So far, there has been an announcement email 2-4 weeks before the >> branch point, aiming to: >> - remind, and >> - seek feedback about required features >> >> The email was also followed by weekly ping/reminder. >> >> IIRC suggestions and requests that are made in timely fashion* have >> always been accepted. >> If we're adopt the above approach, this will: >> - lead to noticeable delays in the branch point, which combined with >> - the current delays getting the blocking bugs fixed. equals >> - even greater delays and less time based releases >> >> Furthermore I'm a bit worried that this might have negative impact on >> developers: >> I don't know any instances, yet some developers may put extra pressure >> on themselves trying to get 'too many' features merged. Leading to >> stress, burn out and others. >> >> >> Perhaps we can somehow utilise your suggestion while ensuring that my >> grim 'predictions' do not come true? > > My suggestion is not to change the paradigm (time based vs feature > based releases) but rather to have better visibility of how the time > based feature releases are done. > > In other words, I'm not expecting to delay the time of the branchpoint. > I still believe we can have tiny flexibility for features that are just > about to land. I also believe this is the current way we are working, > isn't it? > > The proposal only intends to have a central point (a Metabug) in which > to track the status of the branch point rather than just in several > mails and in multiple pings which may happen by different ways (mail, > IRC, ... ?). > > And the same for tracking the final release. > > WDYT? Is this too complicated or time consuming for the release manager > at the given time? Do you think it would be useful? > Just double-checking: I would suspect you're not suggesting removing the existing email/poke scheme? Providing another means to devs to track/handle things is good IMHO. Whether developers will like it is up-to them. Everyone, your input is appreciated! I'm slightly worried that it might cause extra confusion. Some crude examples follow: - I don't use bugzilla/etc to track my feature work - most teams - Do I open another bug, or list my feature in the metabug - seeming an ongoing theme with metabugs - Do I add the bug, reply to the email or both -Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
