(Dropping Leo, since it doesn't affect him. He's already subscribed to the list.)
On 6 April 2018 at 19:20, Mark Janes <mark.a.ja...@intel.com> wrote: > I agree with you, however our release process still has a gap. We > (Intel) test commits on master, and file bugs when we find them in i965 > or other components. > > If those commits already have a stable tag in the commit message, they > will be shipped at a later date directly to customers, with no testing. > There is no way to blacklist broken patches in our Mesa's release > automation. > That's why I mentioned that the process cannot be fully automated ;-) Let me try to explain slightly differently. Amongst others you want: a) 24h (ish) buffer (getting closer to 0, as we reach the pre-release announcement) before landing fix in the stable branch. We had broken _badly_ a few multiple times, a balance between the two is essential. Looking at it from Jenkins POV: You don't want to test/bisect that master is broken, only to apply same patch and run Jenkins on the same broken patch. - when issues to happen for example: fdo#103626 currently there's two ways to handle it 1) add the commit to bin/.cherry-ignore. latter of which means that you miss the patch when it's actually fixed up. See a094314340387ef2463ed8b4ddc9317bc539832b for context. 2) carefully/manually git cherry-pick Doing this allowed me to add the regression to the tracker, as otherwise we would have missed it for 18.0.0 ;-) Yet we could introduce on-hold list to cherry-ignore. It's fairly trivial. Hope that makes things a bit clearer. -Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
