Hi Andres, On 12 March 2018 at 15:57, Andres Gomez <ago...@igalia.com> wrote: > On Mon, 2018-03-12 at 16:45 +0100, Juan A. Suarez Romero wrote: >> > >> On Mon, 2018-03-12 at 17:17 +0200, Andres Gomez wrote: > > [...] > I'm fully on board with your initial suggestion.
>> > My proposal would be, similarly to what Intel does to track [1] the >> > stabilization for a release, 1 week (?) prior to the branching time to >> > create a metabug in bugzilla (or GitLab in the future ?), to announce >> > this metabug in mesa-dev and to let any developer who wants to see >> > their feature into the coming release to open a blocking bug for this >> > metabug explaining such feature and its progress. This way we can track >> > the progress and the process will be more transparent. We can still be >> > flexible to include the blocking features but the coordination will >> > happen over these bugs. >> > >> >> So, when the branch point is created? After the metabug is closed? or 1 week >> after the metabug is created? >> >> >> Not sure if this provide any difference on what we are doing now: create the >> branchpoint, open a metabug with the desire features, and cherry-pick all the >> patches that solves the metabug. >> > > 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. 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? Thanks Emil * 3+days/a week before the branch point _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
