[ANNOUNCE] wayland 1.13.0

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.