Release schedule

[Daniel Stone]

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?

> 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.

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.

> 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?

>> > 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!
>
> 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?
>
> 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.

Cheers,
Daniel