On Fri, 2016-01-22 at 16:03 +0900, Tristan Van Berkom wrote: > In summary, I am not opposed to applying your proposal as is to the > stable builds, there is no justification *ever* for breakage in stable > branches. > > For master, I only think this needs to be detailed properly, perhaps it > would be enough to ensure we had policy ensuring that intentional > breakage is announced (on this list ?) and that "sheriffs" are > responsible for following this list and not reverting commits which > break things intentionally in a transitional period.
Hi, I agree with Tristan. I was just about to write something along his lines. Seeing semi-automated reverts in the projects would be quite depressing, especially when the semi-automat has no idea about the project and what the change was meant for. It makes sense to make sure the build works *before the release*, but when we are in the middle of two releases, then the build break might be just a red flag, not an excuse to break someone's work by the revert. I sometimes find it hard to plan some larger work due to too often releases (it's for a really large work, which can take several weeks to accomplish, then some more to fine tune in the real world usage). If you add this precedence, to always let someone ask: "oh, well, can I commit it? It's large, would anyone revert it? My change touches API and influences like 5+ projects, where I have only 3 under my direct control, thus the main commit is almost immediately followed by corresponding fixes in those projects I've under control, but some still can be broken", then I'm afraid the "hostile environment" would be a very nice word about GNOME and its infrastructure (people would use much much worse in the case you'd really make your proposal alive). This is also about different environments, you partly mentioned it. I believe most of the maintainers build before commit. I do, but I'm a human and mistakes happen. Some mistakes are independent of the build environment (I'm sorry for the before-Christmas breakage of the eds), some are not. I recall broken builds even in jhbuild when API changes happened (clean build was required to make it work, there was nothing wrong about the sources). Even for example Ubuntu environment is different from that I use, causing undefined symbols on places which work just fine for me. What would you revert then in my project? I know, Continuous, it built an hour earlier, it should build now too. Anyway, doing any reverts might not be implicit, not without a previous discussion with the respective maintainers (unless they are not reachable), and only a day before the release - or on the Friday when the notification mail is sent, though for Weekend Contributors it would make more sense for Monday morning of the release day? I do not know, people can fix things just before the release too. It's because the GNOME should build from the release, not necessarily from the git snapshot. The Continuous idea is great to discover build breaks early, but it's not an excuse to damage anyone's work. Bye, Milan _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list