Hi Sri; On 3 June 2016 at 02:53, Sriram Ramkrishna <s...@ramkrishna.me> wrote: > I found this discussion really fascinating and so I wanted to continue it, > separately from Emmanuele's thread so that issue is resolved without > bifurcating the discussion. > > My thoughts are that we really shouldn't be looking at something and say > 'well, we can't do it we don't have the resources' especially when there is > a clear return on investment. I think this would be an interesting > challenge and we should find a way to figure out how we can attract the > talent, machines and money to do this. After all, we have a foundation > dedicated to supporting the development of GNOME.
Can the Foundation hire a full time "build team" that: * keeps the build machines running * keeps the build running * works on the necessary tooling to integrate our Git repositories activity with our mailing list, our bug tracking system, and possibly our IRC channels The current situation can barely run on volunteers time, and I think it's time to be pretty clear on what our requirements are — instead of architecture astronauting our way out. We don't need machines; those are "easy" to get. We need actual people that would fit the bill of a "devops" team; we need people that can install and maintain a complex build system; that set up a Continuous Integration process on top of our existing Continuous Delivery one; and that can fill in the blank spots on the map between "this branch on this module failed to build" and "this is breaking the whole GNOME please fix it". Right now, the easiest and cheapest option would literally be moving the GNOME development infrastructure wholesale to GitHub, put everything under Travis CI, and keep a separate machine somewhere that cranks out GNOME Continuous images from the GitHub repositories. For reasons that you may guess, this is not going to be a very good move. Any other option involves replicating that set up on gnome.org infrastructure, with all the issues that it entails. Incidentally, if you find somebody like that, good luck not getting them poached by companies that want the exact same thing, and are likely to pay more than the GNOME Foundation for it. > We have an amazing infrastructure that we can attract possible very smart > people of whatever age to come and work on for the betterment of GNOME and > of course their own careers. Colin Walters presented Continuous to the GNOME community in 2012 — and it was already cranking out GNOME builds. Apart from a flurry of activity in the beginning, I have not seen much interest being attracted to the actual tools; for a long while, people didn't even care much about the builds — and to be fair, why would they? It works on *their* machine and maybe they can even release tarballs every once in a while, and if it breaks patches welcome, right? Well, patches started to arrive, and at the end we got a much better experience for newcomers, with jhbuild not constantly breaking. Still, people consider Continuous somebody else's problem; if it "breaks on Continuous" but not on a maintainer machine, then who cares? Even if we magically got the resources (build machines, at least one person working on the infrastructure side, volunteer work to improve the tooling), the attitude of "my module is my fiefdom, if a build breaks *you* fix it" has to change. GNOME has long since become an interconnected, complex system, and it requires a level of oversight that does not map with "a loosely coupled set of components", with each one of them that may or may not build; may or may not pass tests; may or may not break other components; may or may not lead to a bootable, usable system. So, more than a *technical* issue (as usual), this is a *social* issue. People have to care about this stuff — and not just a couple of people getting Continuous running. > I just hate when we say we don't have resources when we can't quantify what > we have and we aren't quantifying what we need. I mean, yes, it is > difficult and hard right now, and so we need to make strategic plans to fix > it especially if it is a man power problem. Our development, our > engagement, the board, everything is connected and so we need to look at it > from all angles. > > I really love the ideas of try servers, and you know they have this some how > in github, and man, we should try to find clever means to do the same thing. Sometimes there are no "clever" options, just the old dumb ones. Ciao, Emmanuele. > ---------- Forwarded message --------- > From: Emmanuele Bassi <eba...@gmail.com> > Date: Tue, May 31, 2016 at 9:51 AM > Subject: Re: Enabling builddir != srcdir by default in jhbuild > To: Michael Catanzaro <mcatanz...@gnome.org> > Cc: Desktop Development List <desktop-devel-list@gnome.org> > > > Hi; > > I already pushed the default change to master, as that will only > affect new clones or updates. I'm also building locally the default > gnome moduleset — but I can safely say that the core platform builds > fine. I'm just worried about gnome-world, but for that I guess we'll > have to wait until stuff breaks. > > Ciao, > Emmanuele. > > On 31 May 2016 at 17:47, Michael Catanzaro <mcatanz...@gnome.org> wrote: >> On Mon, 2016-05-30 at 23:44 +0100, Emmanuele Bassi wrote: >>> So, it seems that the discussion died on these shores. >>> >>> In the meantime, GVfs is but the latest module that broke because >>> people don't test under builddir != srcdir; I really, *really* don't >>> want to deal with this kind of perfectly avoidable build breakages >>> any >>> more. >>> >>> Ciao, >>> Emmanuele. >> >> Emmanuele, I think you can feel free to change the default in jhbuild >> provided that everything in the apps and core suites still builds after >> doing so. i.e. you need to make sure to add exceptions in the jhbuild >> modulesets for all modules that need it. >> >> Just please wait a couple days first to see if there are any >> substantial objections (which I do not expect). >> >> Michael > > > > -- > https://www.bassi.io > [@] ebassi [@gmail.com] > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- https://www.bassi.io [@] ebassi [@gmail.com] _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
