[oi-dev] Lets talk about Git

[Bayard Bell]

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.

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.

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.

On Sun, Feb 12, 2012 at 6:44 PM, Andrew Stormont <andyjstormont at gmail.com>wrote:

> Well I guess if we were to slightly modify the new integration process we
> discussed at Brussels we could achieve this quite easily:
>
> 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 (illumos.org) -> Sync of Bit Bucket and Git Hub
> repos is triggered.
>
> Andrew
>
> From: Bayard Bell <buffer.g.overflow at gmail.com>
> Reply-To: OpenIndiana Developer mailing list <oi-dev at openindiana.org>
> Date: Sun, 12 Feb 2012 17:40:32 +0000
>
> To: OpenIndiana Developer mailing list <oi-dev at openindiana.org>
> Subject: Re: [oi-dev] Lets talk about Git
>
> On Sun, Feb 12, 2012 at 5:25 PM, Andrew Stormont <andyjstormont at gmail.com>wrote:
>
>> 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 'whygitisagoodalternativetox.com' I wouldn't need to have to
>> clarify this ;)
>>
>
> 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.
>
> 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.
>
> Cheers,
> Bayard
> _______________________________________________ oi-dev mailing list
> oi-dev at openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
>
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20120212/5faa36da/attachment-0005.html>