- Needing to push squashed commits and revert them via a publicly visible branch, on the canonical reference repository when using a distributed version control system is quite ugly. It amounts to polluting the project history (which everyone has a copy of) with 3 commits per build, in order to satisfy the arcane requirements/limits of a centralised single-instance service/tool - which, not everyone can really use to create builds.
- The sequence of steps required to generate one of these test builds is convoluted and prone to user error. I've gone back and counted them, and there are seven! Yep, 7 individual steps - and that's provided there are no conflicts/typos which mangle things up at some point and require more drastic interventions.
Now, having double checked the threads on this for why this particular workflow is in place, the arguments against doing this still don't completely make sense to me.
The biggest thing is the rejection of allowing building of any arbitrary branches on the main git.blender.org repo, citing that "it would get out of control" - basically, that it would become a free-for-all where suddenly the buildbots would get flooded with an endless tirade of build requests from every man and his dog requesting updates for every branch multiple times a day. At least that's the impression I get from reading the rejection of this option.
I am at least a bit more cautiously optimistic about the state of things, and believe that it may be possible to limit the amount of damage which may be done:
1) Firstly, it's important to remember that this is for the main git.blender.org repo. Not just any old github clone, or something on someone's local computer. But the repo on the blender.org servers. Now, that's a good distinction to make, since there are quite a few distinct characteristics about this.
2) The branches which do exist on there are those by developers with push rights to that repo. In other words, it's core devs or others provided with access to facilitate working on "officially sanctioned" (or highly likely to end up in master) projects (*3). Now, having had a testbuilds branch for a few months, I think it's reasonable to argue that not that many core devs create new branches (yet, though I have to agree that this is slowly increasing), but more notably, even fewer are doing builds - usually it's once a week, or maybe twice in a single day for some of the Gooseberry-related testing builds. Simply put, it's not actually a problem that we need to worry about yet that there are heaps of branches needing to be built, and that even if there are many branches, not all of them are built that often,
3) There is an exception here, in the form of GSoC branches - Student developers, some of whom are new to the community. It is here that the greatest risks come from, but it is something that care, good people, and a backup, "technical safety net" kill switch can effectively neutralise if/when it becomes a problem on a case-by-case basis.
That is, our first line of defense is the fact that most of our devs are good natured - a bit of onboarding instructions on the general "ground rules" regarding the usage of the service should be enough to keep things under control most of the time (along with the fact that finding the way to activate the tool is part of the challenge - like a bit of a competence/initiation-rites test). Our second line of defense is that each student has a mentor who is supposed to keep and eye out and provide assistance - again, this social measure should neuter any slipups that start building up. Finally, if all else fails, it seems trivial that we can "blacklist" a branch from getting built - such blocks can be set up on a temporary/permanent basis as needed, and "admins" could override manually on a case by case basis when there is a legitimate need for the build. Such blacklisting could even be somewhat automatic - like, if more than 1 or 2 build requests happen within a day or so.
4) It's worth mentioning some of the other technical measures as well for good measure too I think:
- Firstly, we're NOT building ALL branches, all the time, automatically. Unlike the nightly/regular builds of master (post commit hook), building of branches is something that must be manually triggered on an "as needed" basis from the web interface.
- To keep things under control, we could make it so that only people who have committed to, or can somehow be identified as being "actively associated with" the development going on in the branch can even see the button to do such building. Again, this could well be a phabricator extension, which only shows up to relevant people when logged in.
(Heck, just doing that we'd have more control than we do now. Anyone with commit access can practically push any patch to that branch and get it built, an unlimited number of times, perhaps matched only by how fast they can issue the commands).
- There could also be a "stand down" period on the build button for a branch. That is, after being activated, it cannot be activated again for the next hour, unless by someone else (or maybe an admin only)
- developer.blender.org admins would still have ultimate "super powers" here to launch builds on behalf of others, or to "sinbin" offending branches for a while
So, unless I'm missing something here, surely this must be at least as good if not better than what we've got now... Of course, it goes without saying that hacking the web interfaces might take resources we really don't have now. But, with what we've got, at least parts of this proposal could at least be within reach?
(Admittedly, I am still somewhat against the whole notion of git's "squash" tool too. IMO, it's not a good technique that should be getting deployed as much as it is.)
No comments:
Post a Comment