On Fri, 2016-06-03 at 01:53 +0000, Sriram Ramkrishna 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.
Hi Sri, I am not happy with how the previous discussion evolved. I think I raised some technically valid points and historical insight, e.g. [0] and [1] and I get the impression that those who are pushing this agenda are not willing to digest the facts and converse constructively, but lets re-examine this. I am certainly not against continuous integration, but I think we need to recognize first that we are in an extremely different position from companies, organizations and projects which perform CI successfully - this is not a solved problem that we can simply apply to GNOME as a wider umbrella of various interconnected projects. CI works very well where development is done in silo, all developers are instantly reachable or replaceable, and all components are designed to work in harmony for a very singular purpose. None of these ingredients are present in the wider GNOME project. So how can we improve things ? What technical approach can we take to better leverage CI for the purpose of furthering the collective goals of projects in GNOME ? Before we can even answer that question, we have to ask also, what are the goals we want to achieve with CI, what do we want to improve ? I think this falls under 2 distinct categories: A.) Finding actual bugs and integration breakages early enough in the cycle to have a stable build come release time. B.) Making it easier for new comers to build and contribute to projects in GNOME. I think first, we need to dispel the belief that the bleeding edge of every module is going to build at all times - especially to new comers who have the idea that they can build all of GNOME and it just doesn't pan out, they get a bad experience because we advertise jhbuild of master as something that should just work. We need to be more honest here. What we have currently with gnome-continous is already helpful for (A), but can be improved. For (B) we don't have a solution right now, but there may be some technical approaches to help solve (B). One approach might be a setup where we have an RC branch opened for integration of changes from master at the beginning of each cycle - this could be a sort of "soft master" that builds but might not be bleeding edge in every way, it could benefit new comers as they could still submit patches against the RC branch and it should at least successfully build all projects from scratch. Also it could benefit the release team inasmuch as we could have constant awareness of exactly how much of the bleeding edge currently integrates at a given time. I strongly disagree with holding project maintainers responsible for creating feature branches and burdening them with the duty of updating other modules not under their control, especially for reasons already outlined in [0], however perhaps a uniform 'integration' CI branch could be automated to a certain extent, as gnome-continuous currently blacklists not-building modules, it could instead be made to guess what changes break a build and recreate the integration branch without the said failing patch, performing tries with merges from master until something builds and integration can again include the new changes. This of course, requires real thought and engineering, but I wanted to at least offer some technical input, some starting point that could be explored - this wont be solved without real engineering, trial and error. One line of thinking I think we really need to distance ourselves from, is the idea that the "social problem" of projects in GNOME is one that needs itself to be fixed. Yes it is a problem, but rather a riddle or puzzle to be solved. Lets embrace the community as it is and find a technical solution that works *for* the community, not try to teach the community that their goals should be more in line with what some particular participants think. I say this, because I sense there is some impatience coming from participants who seem to hold the belief that a uniform and beautiful desktop experience is the singular goal of all projects participating in GNOME, while on the other hand, projects who have been solving real problems and are targeting a much wider audience than just this suffer. The result is that we begin to alienate smart and diligent developers who have been long standing dedicated contributors, and we attract young blood to write a (example) new clock applet that merely, looks the way we want it to. We need to achieve the latter without sacrificing the former and this is a social problem we have to address as well. Cheers, -Tristan [0]:https://mail.gnome.org/archives/desktop-devel-list/2016-January/msg 00046.html [1]:https://mail.gnome.org/archives/desktop-devel-list/2016-January/msg 00051.html _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
