<jmd>Every commit can be a "release". (and legally speaking it is).
<davexunit>it is not in the user's best interest to be told to run master HEAD
<davexunit>and then there's issues of compatibility between versions
<jmd>Well it might be. It depends on commit policy.
<davexunit>and a release is not just the source code as-is
<jmd>Admittedly, git is not the best tool to use, if you want to run a project like that.
<jmd>I think it is fine, if a project wants to say that "commit X" we consider stable - all others at your own risk. But I also think it good (perhaps better) if a project says that ALL commits to the repository are an improvement and self consistent.
<jmd>Professional tools such as aegis can help with such management.
<ijp>if ALL commits to a repository are an improvement and self consisent
<jmd>ijp: Oh right. That's why I said a tool such as Aegis would be usefull for such projects.
<mark_weaver>jmd: I haven't read the whole backlog, but what variant of ARM are you targetting? I was thinking of doing the same as Debian's armhf port.
<jmd>mark_weaver: Well I have a thing which is an arm7
<jmd>I dunno what armhf is, but I think it is the same.
<mark_weaver>jmd: I haven't done the necessary research yet, but I'm also fairly clueless here, but I can tell you that the performance on ARM depends crucially on which set of features you assume when compiling the code.