[ANNOUNCE] wayland 1.13.0

[Daniel Stone]

Hi,

On 27 April 2017 at 08:57, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > I'd like to discuss this. As it stands, we're around a week away from
> > shipping an alpha, and feature freezing. At this point, we have
> > already committed libweston breakage such that the SOVERSION has hit
> > 3. So far, we have nothing to offer for this breakage, just a bunch of
> > bugfixes and a pile of cleanups and groundwork that will only become
> > useful with future features.
>
> That is ok by me, we have explained that weston major bumps are
> meaningless featurewise. Haven't we?

Sure, I don't think anyone will be at our door with pitchforks, but I
don't think it's helpful in trying to get people to use libweston.
Every time we break the API/ABI, we throw a roadblock in the way for
developers and packagers: it makes it harder to use libweston and
harder to ship it. This isn't to say that we should never change the
ABI, but be a bit more careful about how we do it. Currently we've
broken everything (causing work as well as pain for anyone trying to
actually use it), and we're offering nothing at all to mitigate that.
I guess we probably expected to land more in the release series, but
the end result is not a great tradeoff.

On 5 May 2017 at 22:06, Derek Foreman <derekf at osg.samsung.com> wrote:
> On 26/04/17 11:47 AM, Daniel Stone wrote:
>> On 21 February 2017 at 22:59, Bryce Harrington <bryce at osg.samsung.com> wrote:
>>> Our next major release will be version 1.14, which will be scheduled
>>> tentatively as follows:
>>>
>>>   √ Development opens immediately
>>>
>>>   - 1.14-alpha in early May
>
> And here we are.
>
>>>   - 1.14-beta around mid May
>>>
>>>   - 1.14-rc1 late May, with rc2 only if necessary

By now, here.

>> Also I think we should start having these discussions for future
>> releases. To be clear, this is _not_ about feature-based releases, but
>> looking at the time we have, and trying to concentrate all our efforts
>> towards things we would like to have for the release. If we had some
>> clear goals of what we thought we could get into the release, and what
>> would be valuable, we could put our efforts towards that, and
>> hopefully have some more focused releases.
>>
>> Thoughts?
>
> I think we have a backlog of stuff that hasn't landed because it hasn't been
> reviewed (and revised...), I see no harm in holding the release
> and no benefit to rushing it.
>
> Personally, I wouldn't be opposed to feature based releases - though I'd
> probably have dragged things out far too long waiting for atomic to land by
> now, so maybe that's an unpopular point of view.
>
> Better triage for the upcoming release and more focus for following ones
> would be nice - does anyone want to take a pass through patchwork and give a
> go/no-go for the upcoming release?

Unfortunately, nothing has really happened or been reviewed at all
since this thread, so I think holding it any longer is pointless. If
you ask me, we might as well just ship an alpha now and be done with
it.

I'm trying to think of what we can do to encourage people (other than
the three of us who've collectively reviewed about 3/4 of the patches
to have landed since 1.11) to actually review things. I think
Quentin's Patchwork is a really good start there, but perhaps actually
tracking these kinds of things would be better. I'd done a fairly
limited trial with Phabricator for this, but am coming around to the
view that it's not actually a good fit for how we work, and that
GitLab would be better[0]. Doing that and tracking open reviews/issues
with something less lossy than a mailing list or IRC I think would be
nice, as well as make it far easier to attract contributors in.

That being said, if we don't get GitLab in place in time for the next
release series, it looks like our options are:
  * have a similar release series, or
  * hope patch review actually starts occurring, or
  * move to six-month release cycles

I don't really have a good opinion on this, partly because I don't
know what we could do in order to help people review what's there. The
only idea I have right now is to much more actively/aggressively set
targets for releases, and have those tracked so it's far more apparent
where people should be directing their limited resources. Beyond that,
any ideas?

Cheers,
Daniel

[0]: I participated quite a bit in the discussions GNOME had when they
were switching, and came out convinced that GitLab >= 9.x is a better
fit for us than Phabricator, given that they've beefed up their issue
tracking quite a lot.