Release schedule

[Derek Foreman]

On 2018-06-04 07:14 AM, Daniel Stone wrote:
> Hi Pekka,
> 
> On 4 June 2018 at 12:29, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>> On Sun, 3 Jun 2018 10:52:49 +0100
>> Daniel Stone <daniel at fooishbar.org> wrote:
>>> On 1 June 2018 at 17:52, Derek Foreman <derekf at osg.samsung.com> wrote:
>>> Maybe? There's certainly a ton of change in the tree now, and a few
>>> more which look like they could land (IVI/XDG, the last bits of
>>> atomic, etc). It'd be a pretty hefty release whenever we released it.
>>> I don't have a strong opinion on when we get it out the door, to be
>>> honest.
>>
>> for a project I'm working on, it would be very nice to get the current
>> Weston master released ASAP. OTOH, I'm on vacation from July 12 to
>> Aug 1, so I definitely won't be around at that time.
> 
> I know you didn't mean it like this, but I think it's good to be clear
> that this isn't a corporate demand to fix releases at a certain point.
> That user is just another one of our downstreams and another datapoint
> to take into consideration. (But a good one!)
> 
>> We have been in the development cycle for two months now. How would you
>> feel about trying to get, say, rc1 out around July 10?
>>
>> That would mean rc1 at five weeks from now. I could be around during the
>> alpha and beta time, hoping there wouldn't be much regressions to fix
>> after rc1.
>>
>> Is it too soon? How soon could we do it?
> 
> When does it mean alpha/beta?

I'm traveling from July 16-20, and will have very poor internet access.

This would put as at:
Alpha June 12
Beta June 26
RC1 July 10
Final July 24 (normally we're 1 week between RCs but july 17 is
problematic for me.)

So that's coming up fast.

>> Does it clash with the GitLab migration?
> 
> We've already moved the repos and the site. I think it would be good
> to move our issues just before the release, so by 5.0.0rc (or beta?)
> we had all our issues already in GitLab and could have that as a clean
> cut-off point. From my (migration) point of view, we can absolutely
> have Bugzilla migrated - we could pretty much do that now - and I'm
> moderately confident of having Phabricator migrated by then as well.
> But I don't think it's so bad even if the Phab migration does slip a
> little after the Bugzilla migration.
> 
> If we have split release cycles for Wayland and Weston, we can choose
> to migrate Wayland's bugs later if that makes sense.
> 
>> What do we want to have in the 5.0.0 release?
> 
> I'd want to have the rest of the 'atomic series' (now really about
> overlay plane usage & modifiers) in for sure. It's all got positive
> review and I have some very clearly and definitively carved-out time
> coming in the next week or two to spend on just getting that landed. I
> think it's pretty important to land as it does fix some bugs, and full
> modifier support is becoming more important: we need it in order to
> run on Etnaviv/i.MX at all, it helps RPi, and we don't get composition
> bypass / direct scanout for fullscreen windows on Intel anymore, since
> we need modifiers to describe the client buffers it generates from
> Mesa.

That looks like a fair bit of stuff - can we get there with the proposed
timeline or should we push back?

> I also have some work on weston-debug and IVI shell coming up, but I
> don't think those will get finalised in the next couple of weeks, so
> I'm comfortable giving those more time.

grumble grumble xdg shell stable grumble.

>> How long do we need for the alpha and beta stages?
> 
> I don't have a good answer to this one. I think we've traditionally
> done two weeks for each, right?

That's my recollection, at least for the last release.

>>>> I think we also no longer need to rigidly release wayland and weston at
>>>> the same time, as wayland itself is quite mature and may not receive
>>>> many significant patches during a weston cycle.  I'm wondering if
>>>> libwayland releases should break from timed cycles entirely?
>>>
>>> That sounds good to me. libwayland is so quiet that I don't think we
>>> need to force it out the door every so often; I think moving it out of
>>> forced major releases could get us actually doing patch releases as
>>> well, which would be nice.
>>
>> Sounds fine to me!

Nod, I think patch releases for libwayland make sense now.

So, let's sit on this a little bit to give anyone that thinks this
release comes too soon a chance to speak, and if nobody complains by
June 11 we can go with the June 12 to July 24 plan.

This is a bit of a surprise, so anyone with any reason feel free to stop
me - on or off list if you don't want to make a scene here. ;)

Also, there's been some small change in libwayland, so I'll do them both
at the same time for this round, but in the future we'll only force them
together if there's a compelling reason.

>> Even for Weston, not the least because it would be oh so very convenient
>> for me right now, maybe it would be nice to let people request an early
>> release cycle if there are specific things they would like to have in a
>> release. In case nothing such comes up, our release manager could
>> decide to do a time-based release so that we get at least two
>> releases a year. How would that sound?

I'm fine with this - I'm not against some variability in the schedule.

I think we should normally start the discussion a little further in
advance though, announcing a week before the alpha is a bit quick. :)

>> Obviously, when requesting an early release, the community needs to
>> agree on the schedule so that the feature freeze doesn't come at an
>> awkward time.
> 
> Yeah. I think in general we just need a little more proactive
> awareness in both directions: development being geared towards
> releases a little more, and releases more actively steering
> development. Maybe having a better issue tracker (e.g. being able to
> use GItLab milestones or workboards) would help everyone by making
> what we're aiming for more visible.

+1

Thanks,
Derek

> Cheers,
> Daniel
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>