On Fri, 2016-01-22 at 10:55 +0100, Milan Crha wrote: > 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.
Why does it matter what the change was meant for? If people cannot build GNOME, that is a much more serious problem than whatever your commit is fixing. > 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. Let's take e-d-s as a specific example. If we were building tarball releases of e-d-s in jhbuild and Continuous, this would make perfect sense. We're not doing that. We build e-d-s from git master because it is a core component of GNOME, and we want jhbuild to build the latest version of everything, and we want contributors to be able to contribute to e-d-s after all!, hence the need for a git repo. master needs to be buildable at all times. This isn't for you, it's for *everyone else* trying to build GNOME. Now, you could choose to work around this if you want, by tagging e-d-s in Continuous and branching it in jhbuild, then updating that branch with every release. Or, you could work in a "next" branch that gets merged into master each release. Personally, I would continue to work in master, and accept that once in a while a change of mine will get reverted until I have figured out what is wrong with it.... > 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). Milan, you have full commit access to every repo on git.gnome.org. Any breakage that could register on Continuous is fully within your ability to fix. > 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). Yeah, we don't expect incremental builds to always work. There's just no way to make that possible. We do expect clean builds to work. > 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. The value of Continuous is that it is a neutral environment. I'd like to set up additional jhbuild builders to do CI in Ubuntu, Fedora, Arch, etc. so that we can catch build breakage in more environments. > 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. Milan, I honestly feel that you might be better off using a "next" branch if you really don't want any commits to be reverted. (That might be the compromise solution here.) Or change jhbuild and gnome- continuous to build your stable branch instead. Michael _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
