On Mon, 2016-06-06 at 09:49 -0500, Michael Catanzaro wrote: > A revert is not supposed to be "punishment" in any way... rather, > consider it as assistance to make sure GNOME stays buildable. :)
Hi, maybe it's not supposed to be, but it is in my eyes. I try my best to not break builds, I'm grateful when other folks let me know when the builds are broken for them. Neither jhbuild catches everything [1], which you seem to suggest. I broke build in general, not only in the jhbuild, in the not so distant past, which was a shame and it was all my fault. I'm sorry for that, though in that particular case the change on the evolution-data-server side was correct, only the evolution build broke, because it wasn't updated appropriately. The revert on the eds side would not make any sense. It was correct, as I said. (API changed in some way and I didn't realize that the evolution uses the API in a way which breaks it. Just my fault.) I do not fully understand why reverting in some random project (and making sort of hostile environment) is easier than the current state, when the same person "tags" what commit is supposed to be used in Continuous in the jhbuild. You still need the person, the person cannot be a monkey, it will think before doing anything (I mean, it's not a mechanical job where one rule fits each case). I appreciate how Emmanuele and others (are there any others?) handle the situation right now. I do not want to add them more work, really not. > we can create a list of maintainers who don't want this Nah, that's one more place to look at and to forget about. That adds work to those nice folk(s) whom take care of the Continuous. > In this case, when the API change breaks something in core or gnome- > apps, then the module and its dependencies really need to be updated > in jhbuild at (approximately) the same time, so there's at most a > small window of time where jhbuild is broken. > ... Right, it's unrealistic in some cases to land all of that at one time. Side branches is a nice idea, but it won't work, because you do not have any influence on the other project maintainers usually, thus even a bugzilla requests can lurk there for a long time. Having a side branch only means that the maintainers whom do not follow particular mailing list will notice only later, rather than sooner. There is a bug to make more structures in Camel GObject based [2], to be able to introspect it in a much easier way and so on. That change will not be only a simple API change, it'll break core Camel things, everything what uses it. If you open the [2], then I listed affected projects at the end of the comment #5. It counts 18 projects. Maybe there are more. I do not think I'd be able to coordinate the change in a side branch for all of them, I (we) will surely provide patches in the bugzilla around the time of the change landing, then it'll be up to the respective maintainers to pick or reject them. What will the Continuous do during this "broken period" is something I do not know. I only know that the change will be for good. Introspection support for the Mail part is good, I believe. Trying to revert such change in the eds would hurt very much, no doubt. > Yeah, of course runtime bugs are problems, but not the problem we are > trying to solve here. :) Heh, true, though the runtime bugs are more important. I believe. I know, that's one reason why you want to have the jhbuild working, to make it easier for the contributors to test and develop. Which is a good thing for everyone. Bye, Milan [1] https://bugzilla.gnome.org/show_bug.cgi?id=766540 [2] https://bugzilla.gnome.org/show_bug.cgi?id=764065 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list