Release schedule

Fri Jun 8 08:21:13 UTC 2018

On Thu, 7 Jun 2018 15:45:00 -0500
Derek Foreman <derekf at osg.samsung.com> wrote:

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

Hi Derek,

very fast. Even too fast.

I suppose I could be happy with just alpha coming in a month, or at
most in two months. I don't personally mind being on vacation during
the freezes, but I though it would be nice for others to be around. I
would also be ok if your travels were during some freeze period, we
could extend it respectively.

Please, suggest a schedule you would be comfortable with.

> >> 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 think we should push the alpha back some, I'd like to see that stuff
in too.

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

Alright, sounds good to me.

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

I do feel a bit bad suggesting that fast major feature freeze. :-)

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

Definitely.

> >> 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,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180608/00949059/attachment.sig>