On 01/03/15 12:49, intrigeri wrote: > hi, > > bertagaz wrote (27 Feb 2015 10:07:03 GMT) : >> On Thu, Feb 26, 2015 at 08:46:17PM +0100, bertagaz wrote: >>> On Thu, Feb 26, 2015 at 05:21:23PM +0100, anonym wrote: >>>> On 11/01/15 20:07, Jurre van Bergen wrote: >>>>> Developers should be able to trigger automatic builds for a branch >>>>> whose build was dropped (eg. last commit too old) by pushing a dumb >>>>> commit on a timestamp file in that branch. >>>> >>>> Can't we make builds trigger via signed email too? Polluting the Git >>>> repo like that seems ugly to me. > [...] >> While discussing last night about this interesting point you raised, we >> thought of an easy and obvious fix to that history pollution. > >> In fact, that's even already implemented in the way we often work: after a >> release, people working on a topic branch often merge stable or testing >> back in it. So there *will* be new commits on their branches. > >> Does that sound better to you? > > At least it does sound better to me: the problem at hand is detecting > the transition of a branch between inactive and active state.
It sounds better to me too. However, I think the reason I asked for this feature was to trigger rebuilds when the feature branch's APT suite has been updated. From reading the blueprint it only mentions "Git", so I assume the "watchdog" won't look at the feature branch's APT suite state? I think I mentioned something about this during the sprint. Another thing that *just* struck me (and has a lot of consequences... sorry for coming with this at this late stage) is that updates to the base branch's APT suite will affect all feature branches based on it, so a rebuild for all of them would make sense immediately after such an update. OTOH, they may lack important Git state (since the base branch wasn't merged back) that otherwise will make the builds break. Luckily, if we have #8654 and never modify any base branch's APT suite directly but only add APT suites to the base branche's config file *in* *Git*, we should be fine since a Git merge into the feature branch is needed to make it aware of the APT changes. There's a similar case that also needs some consideration, and changes in how we work: imagine we have a feature branch F based on base branch B. We upload a package to F's APT suite, all looks good at the moment, and we merge F into B. Then a feature branch E has B merged into. All good so far. However, at this point we discover an issue with F and have to rebuild the package, or otherwise change F's APT suite. Then we cannot do anything with F's APT suite, because that would affect E without it merging B again. Hence, the fixup for F has to be made in a new feature branch, say F-fixup. When F-fixup is merged into B, E won't be affected (and need a rebuild) until B is merged into E. To conclude, we should update our merge policy (or whatever) with the following rules: * Never upload packages directly to any base branch, not even during during release time. Never! * Once a feature branch has been merged into a base branch, the feature branch's APT suite should be frozen forever. Any fixups that affect the feature branch's APT suite *must* be done in the APT suite of a *new* feature branch. I also think we have some problems around release time when we merge all APT suites of the feature branches that *have* been Git-merged into the base branch being released (I'm gonna refer to this procedure simply as "squashing" below). Specifically, all feature branches based on the to-be-released base branch that has *not* been merged will be affected by this. Example: 1. Let F1 and F2 be divergent feature branches based on base branch B. 2. F1 is merged into B. 3. B is released, so F1's APT suite is merged into B's APT suite, i.e. the "squashing". 4. Note that at no point was F1 or B merged into F2, but right now it's like the APT suite of F1 is merged into F2. Also note that F1's Git is not merged into F2. Now we have two issues: * F2 has (indirectly, via the base branch's APT suite) been modified without its Git state being changed at all. * However, F2 doesn't have the Git changes made in F1, and it could very well be that the APT stuff introduced by F1's APT suite depend on those Git changes in a way so that builds will break without them. The only way I see to resolve all this reliably is that: after we "squash", then all branches based on B that have *not* been merged yet must immediately have B merged into them, and all branches that *have* been merged are killed (or at least marked in a way so they are not rebuilt). This is a new step in our release process. However, it's quite unfortunate to add this procedure at that stage, which already is a bit stressful, so perhaps the "squashing" can be done in the APT suite T that's created for the release tag, and then we reset the B to T's state and merge B into the remaining feature branches based on B at post-release time, when things are a bit calmer. Thoughts? Cheers! _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.