Re: [ Revised Proposal ] Continuous Builds in GNOME





On Sun, Jun 19, 2016 at 7:34 AM Tristan Van Berkom <tristan vanberkom codethink co uk> wrote:
On Sat, 2016-06-18 at 08:15 +0100, Emmanuele Bassi wrote:
[...]
> Tristan: I understand you don't give a crap about GNOME as a holistic
> project; you've made it *painfully* clear over the years. I'd like to
> point out that without GNOME working as a single unit nothing we do,
> or did up until now, really matters in the grand scheme of things.
> The
> *only* successful thing out of GNOME is the GNOME desktop environment
> and its whole stack of technologies; everything else has been a
> failure, mostly caused by this inane obsession of considering the
> GNOME platform as a bag of loosely coupled projects that somebody has
> to work hard into identifying and keep working together, granting the
> position of gatekeeper to a bunch of middle men. This position is
> ignorant of the history of the project, especially of its failures;
> it's insulting of the work of hundreds of people who want to keep
> this
> thing working and keep it approachable to newcomers; and completely
> invalidated by the reality of what happens every day in the
> commercial
> space. I also don't understand your opposition to keeping the only
> integration branch we have, the 'master' branch, building constantly,
> considering this is a basic engineering practice, but at this point I
> can barely muster the strength to even care. In any case, as I said
> to
> Milan, I'll gladly consider any project you maintain at the same
> level
> as an external dependency, and thus just tag it. Feel free to go
> through the Continuous manifest and Jhbuild moduleset and point out
> which modules you still maintain.


Emmanuele,

Thank you for sharing this. You make the perfect example.

You will note, that my "astronauting" is in fact a sincere attempt to
reconcile both of these views with some plausible technical approach,
so while your goals are clearly not the same as mine; I am being
sensitive to your goals, in fact I want some team within GNOME to be
successful at integrating all of these projects into some coherent user
experience - I only want that team to accept that the components they
intend to integrate have bigger plans than *just* being a part of this
integrated whole.

You on the other hand seem threatened by my views and consequently act
intolerant towards the existing diversity of goals of projects within
GNOME - I don't think this intolerance is an attitude we should have to
deal with, we should be instead looking for creative ways to reconcile
both views.

Yes, the GNOME Desktop Environment as a unified thing has never been a
personal goal for me to work towards, rather the most important to me
is to build a solid and stable platform with good development tools,
and I want it to be the platform of choice in the FOSS world - if the
GNOME Desktop Environment turns out to be the only consumer of the work
I've done over the years, this will be the biggest failure of all in my
eyes.

You may have accepted defeat but as long as I spend any energy in GNOME
at all, I simply can not.

Hi,

Tristan, I wonder if I can present a different perspective that might reconcile these differences.

I'm an active contributor to the gtk-osx module, which is a collection of scripts and jhbuild modulesets for building (some of) the GNOME stack on Mac OSX. While I personally believe very much in the goal of the GNOME desktop as a unified platform, I also put a lot of work into keeping the the GNOME stack libraries buildable on Mac, so that people can provide builds of GNOME apps (such as Gedit) on Mac as well as build their own cross-platform apps using GNOME tools. I think you even reviewed some of my patches to make Glade buildable on Mac not too long ago.

I hope you'll agree that this is a diverse use of GNOME modules, focused on consumers outside of the GNOME desktop. Please believe me then when I say that _nothing_ would make me more happy, in the capacity of gtk-osx contributor, than a CI system, and with it the ability to assume that the entire stack is buildable at any given time.

I realize that having a CI system on the proprietary Mac OSX is quite another controversial step beyond having a CI system in the first place, but I would be happy just to have commits that break the build on Linux reverted automatically so that when I trepidatiously type "jhbuild build" on my Mac and hover over the Enter key thinking "do I really want to commit to another three evenings of build bugs," I can at least be assured that any failures are going to be Mac build bugs (fixing which is the reason I contribute to gtk-osx) and not general build breakage (which I feel I shouldn't have to spend my limited time dealing with as there are automated tools, such as CI, for catching this sort of thing!)

I hope to illustrate with this, that a CI system, and stability policies that we make to go along with it, serve more ends than just the GNOME desktop.

As to whether it's "hostile" to make sure that master is buildable — I myself don't see how a policy that applies equally to everyone, and is partially intended to give newbies an easier landing, can be described as hostile. But that's my opinion and you have yours. Maybe your feeling of hostility would be eased if the CI system built every single branch as it was pushed, or Bugzilla patch as it was uploaded, similar to what Travis CI or WebKit's EWS do; that means that maintainers will in practice rarely, if ever, get into a situation where a commit needs to be automatically reverted.

After using Travis CI on some of my personal projects and making that stability policy for myself that master always needs to be buildable and pass the tests, I never ever want to go back. It seems inflexible at first, but it feels so liberating. If you haven't tried out a policy like this, I highly recommend you do so, maybe on a small project. You might end up feeling the same way.

Regards,
Philip C


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]