One other refinement would spare us the need for recommit: if we required a clone per issue, we could take all changesets that were different, make sure they were tagged with the same issue ID/comment, and do the recommit in putting the change to the repo feeding the CI environment.<br>
<br>The other thing we'd need to check is change ordering: the same dependency expansion that checks which other packages/components need to be tested would be able to check for overlap between the packages and force ordering on the basis that committers always go first (because those changes don't have to block on review) and that changes are otherwise first-come, first-serve. Any change that fails CI goes to the back of the queue.<br>
<br>We'd also want to check changes that don't get directly committed against all changes that happened between submission and approval, re-running CI as appropriate, in case they happen to collide with another change that sailed through.<br>
<br><div class="gmail_quote">On Sun, Feb 12, 2012 at 6:44 PM, Andrew Stormont <span dir="ltr"><<a href="mailto:andyjstormont@gmail.com">andyjstormont@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><div>Well I guess if we were to slightly modify the new integration process we discussed at Brussels we could achieve this quite easily:</div>
<div><br></div><div>Developer pushes to Bit Bucket or Git Hub -> Changeset is intercepted and passed to Jenkins for testing -> Build completes successfully and changeset is pushed to master repo (<a href="http://illumos.org" target="_blank">illumos.org</a>) -> Sync of Bit Bucket and Git Hub repos is triggered.</div>
<div><br></div><div>Andrew</div><div><br></div><span><div style="padding:3pt 0in 0in;text-align:left;font-size:11pt;border-width:1pt medium medium;border-style:solid none none;border-color:rgb(181,196,223) -moz-use-text-color -moz-use-text-color;font-family:Calibri">
<div class="im"><span style="font-weight:bold">From: </span> Bayard Bell <<a href="mailto:buffer.g.overflow@gmail.com" target="_blank">buffer.g.overflow@gmail.com</a>><br><span style="font-weight:bold">Reply-To: </span> OpenIndiana Developer mailing list <<a href="mailto:oi-dev@openindiana.org" target="_blank">oi-dev@openindiana.org</a>><br>
</div><span style="font-weight:bold">Date: </span> Sun, 12 Feb 2012 17:40:32 +0000<div class="im"><br><span style="font-weight:bold">To: </span> OpenIndiana Developer mailing list <<a href="mailto:oi-dev@openindiana.org" target="_blank">oi-dev@openindiana.org</a>><br>
<span style="font-weight:bold">Subject: </span> Re: [oi-dev] Lets talk about Git<br></div></div><div><div class="h5"><div><br></div>On Sun, Feb 12, 2012 at 5:25 PM, Andrew Stormont <span dir="ltr"><<a href="mailto:andyjstormont@gmail.com" target="_blank">andyjstormont@gmail.com</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
I just want to say straightaway that I apologise. My intention is not to start a flamewar or bike shedding but to merely show that there are benefits to offering git as an alternative to mercurial. I'm sure if the URL was '<a href="http://whygitisagoodalternativetox.com" target="_blank">whygitisagoodalternativetox.com</a>' I wouldn't need to have to clarify this ;)<span></span></div>
</blockquote><div><br>No need to apologize, my response was meant to be tongue-in-cheek, not trying to escalate this, just to warn that it becomes a bikeshed if we have to choose between the two, which is preferable to avoid. I'm pretty comfortable that we have a reasonable grasp on how to put together a technical solution to co-existence with complete parity. I'd pretty excited about the prospect of working with you to make sure that happens.<br>
<br>I don't think we should keep hg around because it's the best in some absolute sense, I think we should keep it around because it's adequate to our needs and conversion requires cat-herding of existing developers that's best avoided. We should maintain perspective: git has momentum and a very large user base because plenty of people do agree that git is better than the alternatives, and we need to respect that by letting people who like it continue to use it.<br>
<br>Cheers,<br>Bayard<br></div></div></div></div><div class="im">
_______________________________________________
oi-dev mailing list
<a href="mailto:oi-dev@openindiana.org" target="_blank">oi-dev@openindiana.org</a>
<a href="http://openindiana.org/mailman/listinfo/oi-dev" target="_blank">http://openindiana.org/mailman/listinfo/oi-dev</a>
</div></span></div>
<br>_______________________________________________<br>
oi-dev mailing list<br>
<a href="mailto:oi-dev@openindiana.org">oi-dev@openindiana.org</a><br>
<a href="http://openindiana.org/mailman/listinfo/oi-dev" target="_blank">http://openindiana.org/mailman/listinfo/oi-dev</a><br>
<br></blockquote></div><br>