On Fri, Jun 3, 2016 at 1:42 AM Emmanuele Bassi <eba...@gmail.com> wrote:
> 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 > I don't know, right now, probably not. But we could attract some devops talent, and help support the initiatives and Andrea Veri and Patrick Uiterwijk have been doing to attractive them. We only a part time person for the moment and even that has given us a significant benefit. But as you allude to, even with the above we have a social problem, so before we can even do that we need to figure out how to get maintainers to participate into the build system. In this day and age, most developers accept the fact of using a try server and not merging code that doesn't build. > > 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. > Sure. > > > 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. > Yes, but it highlights the value something like GitHub provides. What about GitLab? (BTW I'm not advocating we move, just looking to see alternatives) GitLab while open source, does not seem to open source its CI work that I can tell. Still, maybe a deal can be made.. > > 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. > > Actually, I was going to use this argument to find me talented, but out of work systems administrators who for whatever reason is not able to find a job. I know one such right now, and I've worked with him for 20 years. It is completely within his skill set. If we can find someone who can actually implement it then we have at least some chance. > > Still, people consider Continuous somebody else's problem; if it > "breaks on Continuous" but not on a maintainer machine, then who > cares? > Then we should change where Continuous fits in the scheme of things by asking the release team to have weekly builds from Continuous. We should consider everything on the table. > > 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. > Well, we've done a lot of social changes, bringing in designers working with developers, all firsts in a Free Software project. It is clear we can make social changes when we need to. Since 2011, we've already started to think of ourselves as a product, and so the idea that some people think we are still a loosely coupled set of components is old way thinking and they need to 'git pull' on their thinking. > > 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. > > Well, I think to expand on that, all of us need to think about the big picture. We have an entire foundation set up to drive development. But I think there is a disconnect between development (development, translation, and documentation) and the foundation/money/engagement. People don't realize that everything is connected. Perception management, public relations, fundraising are all part of how we bring money into the foundation so that we can get the kind of resources for Continuous and other initiatives that we need to further development. But everybody needs to pitch in to help support that so that we can have 'nice things'. :-) (I know that you know this, my comments are for the kids watching from home) That said, I think on the foundation angle, we should be working with orgs and find other ways that doesn't involve money to get continuous going, help attract more volunteers etc. For the most part, the engagement has added more members, and we are working towards building a good on-boarding story. But we need someone to tell us what the priorities are for volunteers so we know what to work on. In fact I find it interesting that we also find ourselves resource starved as there are plenty of work and initiatives to work on, but we also need more volunteers. sri > 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. > I rather reach for the brass ring than not try at all. :-) sri > > 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
