<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">2017-02-22 11:54 GMT+01:00 Thomas Goirand <span dir="ltr"><<a href="mailto:zigo@debian.org" target="_blank">zigo@debian.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I hope you don't mind even if you sent me a mail to me only: I'm<br>
forwarding this to the list, so we can discuss it as a team. Hopefully,<br>
we'll have improvements.<br></blockquote><div><br></div><div>np.</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">
> 3. it's always not possible to have one commit per change (i need to<br>
> git commit --amend after merge)<br>
<br>
Could you expand on this? I don't understand why there's a problem, and<br>
why one would need to do a --amend after merge.<br></blockquote><div><br></div><div>ehm, <a href="https://wiki.openstack.org/wiki/DEB-packaging#Releasing_a_new_upstream_release_package">https://wiki.openstack.org/wiki/DEB-packaging#Releasing_a_new_upstream_release_package</a></div><div><br></div><div>You MUST use --amend after git merge.</div><div><br></div><div>Cite: Note that the fix of debian/changelog and debian/control should be done in the same single commit as the merge commit, otherwise the package will fail to build.</div><div><br></div><div>So in 1 commit I need:</div><div><ul><li>merge upstream</li><li>change d/changelog</li><li>change d/control for deps</li><li>add d/patches which fixies build</li></ul><div>This is crazy. I want to do as small commits as possible, at least one commit = one changelog entry.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 4. it's hard to manage deb-auto-backports. It took me a day to fix<br>
> auto-backports just to upload new Swift version<br>
<br>
True. Though it has the huge advantage that it keeps backports<br>
up-to-date, which was never the case with the hack system of doing it by<br>
hand. Also, you never had to take care of it, because *I* was doing it<br>
by hand, sometimes cheating and just ignoring build problems (shame on<br>
me). It was even more painful by hand...<br></blockquote><div><br></div><div>but that's theory. I waited ~ week for fix and then i fixed it myself. We can't depend on single man to do critical job. We need solution which anyone can fix :). Current solution is hackish. Example: If you need to add new package for auto backports, every other package is checked for update and if there is update, it gets updated. We should change this and update packages only if it's needed / desired. Next: We should prefer depedency packages from official jessie backports if they are newer and (auto-)remove old one from our repo.</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">
> 5. it doesn't build packages for unstable - which is important, because<br>
> we are uploading to unstable and instead it builds/checks Jessie<br>
> backports (which is less important)<br>
<br>
We could add that feature. Also, it is my view that one should attempt<br>
an sbuild build on Sid before sending a CR. With the old system, we also<br>
had the issue.<br></blockquote><div><br></div><div>yep i can say anyone should do sbuild on Jessie backports before doing CR too. So why we have gating for Jessie bpo? Because gates are here for checking if people are doing correct thing. And because we are uploading to Sid, we must be sure it builds on sid (with deps package only from sid).</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">
> 6. only cores can update package to new upstream version (merge commit)<br>
<br>
So far, it hasn't been an issue. We can also have a very liberal policy<br>
as to who's core if we do have a problem. Also, there's many ways to<br>
configure ACLs, we could get them to allow everyone to do merge commits.<br></blockquote><div><br></div><div>it hasn't been issue because everytime my colleague needed to do CR I added them to team and then removed them :). So let's change ACL i think.</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">
> 7. we still don't have one simple thing - ocata branches. Something I<br>
> can do myself in Alioth for less than 1 minute<br>
<br>
As I wrote before, the Ocata branches aren't the problem. The reprepro<br>
new Debian repo for Ocata is.<br></blockquote><div><br></div><div>so:</div><div><br></div><div>8. add repo for Ocata</div></div><div><br></div><div>Thanks.</div><div><br></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>