Re: [Tails-dev] Automated builds specification

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!