Planning for another Wayland release

[Arnaud Vrac]

On Wed, Jan 17, 2018 at 4:57 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 16 January 2018 at 22:10, Daniel Stone <daniel at fooishbar.org> wrote:
>> Hey Bryce,
>>
>> On 12 January 2018 at 22:51, Derek Foreman <derekf at osg.samsung.com> wrote:
>>> On 2018-01-12 04:00 AM, Daniel Stone wrote:
>>>> I did a clearout of the review queue last month, but that's not yet
>>>> complete, and I'd like someone to have a more structured look at the
>>>> queue (or just to look at all ...) to find stuff that should make it
>>>> into the next release. Currently, we have at least Derek's zombie
>>>> series, my atomic series and Pekka's clone-mode series, which are all
>>>> unlikely to land before Tuesday, but are seemingly very close to
>>>> having at least their foundations land.
>>>>
>>>> I think it would be best to announce a date before FOSDEM, but make
>>>> sure we have a good handle on the state of the tree before we do and
>>>> make sure we don't unnecessarily drop things. That would include
>>>> keeping a close eye on how it develops, rather than just running
>>>> release.sh on a strict timer. I was pretty unhappy last time when we
>>>> put out a release in the middle of discussing a possibly-critical
>>>> patchset; reading the list would've pointed to a few hours' or one
>>>> day's delay as being helpful, but in the end the release just abruptly
>>>> went out and made the whole thing moot.
>>>>
>>>> Given how much we could potentially be landing, I think we would need
>>>> someone more actively involved (patch-herding, review, testing,
>>>> list/IRC discussion) to handle the release process; I'm happy to do
>>>> that for this release.
>>>
>>> I'm able to dedicate time to these tasks for the foreseeable future.
>>>
>>> If there's interest, I can take on a few release cycles.
>>
>> That would be great, thanks! I'm going to land the most invasive
>> chunks of the atomic work (up to patch 8, using a drm_plane for the
>> scanout/primary plane) tomorrow, and if we can go through rapidly
>> enough to land the most dangerous part ('move repaint state
>> application to flush'), then landing actual core atomic support should
>> be a slam-dunk. It might make sense to try to land some of Pekka's
>> output rework as well, depending on the magnitude of API change.
>>
>> I think everything Emil nominated seems good, and I've been wondering
>> about a few others to have a closer look at:
>
>> https://patchwork.freedesktop.org/series/34624/ (needs rework I think,
>> oh wait that happened in
>> https://patchwork.freedesktop.org/series/35175/)
> The latter is the updated version. Feel free to ignore my nitpicks or
> tweak to your (committer's) liking ;-)
>
> I've skimmed through one of the other patches. Can help with the rest
> - do let me know.
>

Hi all,

I've pushed v3 of the GLES3 patches, fixing one of Emil's nitpick and
splitting patch 3 for clarity. Thanks everyone for the release effort
!

-Arnaud