<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">2017-02-22 18:37 GMT+01:00 Thomas Goirand <span dir="ltr"><<a href="mailto:zigo@debian.org" target="_blank">zigo@debian.org</a>></span>:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In which way does this differ from what we had on Alioth + Jenkins build<br>
server? (This is retorical, let me answer) Well, before, we could push a<br>
merge, but then there was a chance the package couldn't build. Now, we<br>
make sure than 100% of the time, the package *can* build. So IMO it's a<br>
very good thing that now, the merge commit must contain fixes so the<br>
package continues to build. On top of this, we have a consistent git<br>
history, were we always can build.<br></blockquote><div><br></div><div>this is not retorical, because there is difference. On alioth I can do many commits and push "when it's ready" and when it can be build. This makes git history much cleaner. It needs to be buildable after push, not after commit. Now I need to make all changes in one commit. Git history is completely useless/unreadable now.</div><div><br></div><div>BTW: Same flow are used in github+travis. Merge request (which can be more than one commit) needs to be buildable, not all single commits.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> but that's theory. I waited ~ week for fix and then i fixed it myself.<br>
<br>
I don't remember what that was. Can you refresh my memory?<br></blockquote><div><br></div><div><a href="https://github.com/openstack/deb-auto-backports/commits/debian/newton">https://github.com/openstack/deb-auto-backports/commits/debian/newton</a></div><div>14-18 November. Enable, disable, enable some of them, ...</div><div><br></div><div>If I remember correctly I wanted newer pycodestyle and libgit2.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
There's 2 options for us to use: --download-from-jessie-<wbr>backports (which<br>
I used for a few packages which we couldn't build), and -d<br>
jessie-backports. If you and everyone else believe it's the best option<br>
for us, then I don't have any objection to use extensively the -d<br>
jessie-backports (which I prefer over --download-from-jessie-<wbr>backports<br>
so we check if the package can be built). The reason why I think it's a<br>
good idea, is because this way, we take advantage of the maintenance<br>
work done within Debian directly, which is a very good thing.<br></blockquote><div><br></div><div>I mean something different. I would use jessie-backports official backports (in /etc/apt/sources.list) during our build and only if package is not in official j-bpo repo, add them to auto-backports. And only for short time, because we should upload them to j-bpo.</div><div><br></div><div>So simple flow:</div><div>* build our packages using official j + j-bpo repos</div><div>* when i need newer/completly new b-d which is not in j-bpo, add it to auto-backports</div><div>* upload it to j-bpo</div><div>* remove from auto-backports</div><div><br></div><div>So keep auto-backports as small as possible. Example: Why we should build debhelper for j-bpo ourself if there is working+tested version in j-bpo already? We are uploading final packages to j-bpo repo, so it MUST work with other j-bpo packages. And if we don't want wait for dak/other maintainers, use auto-backports.</div><div><br></div></div>-- <br><div class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Best regards<br> Ondřej Nový<br> <br>Email: <a href="mailto:novy@ondrej.org" target="_blank">novy@ondrej.org</a></div><div>PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B<br><br></div></div></div></div></div></div>
</div></div>