Closed Bug 713782 Opened 13 years ago Closed 9 years ago

[Tracking bug] support git in production on parity with hg

Categories

(Developer Services :: General, task)

Product:
Developer Services
Component:
General
Platform:
x86
All
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: joduinn, Assigned: hwine)

References

Details

per meeting w/hwine, filing this tracking bug for this project. The idea here is to see if we can support git in Mozilla's RelEng infrastructure, to at least the same standard (or better) as we already currently support hg. 

Some initial thoughts are here: 
https://intranet.mozilla.org/Release:Git_integration
https://intranet.mozilla.org/Release:Git_integration/Integration_Approaches
(In reply to John O'Duinn [:joduinn] from comment #0)

> Some initial thoughts are here: 
> https://intranet.mozilla.org/Release:Git_integration
> https://intranet.mozilla.org/Release:Git_integration/Integration_Approaches

Can we please migrate these docs to wikimo, so that others outside of the employee bubble can mind-share.
(In reply to Justin Wood (:Callek) from comment #1)
> Can we please migrate these docs to wikimo, so that others outside of the
> employee bubble can mind-share.

Absolutely! The docs will be migrated as soon as they are "docs". What is there now are my scribble notes, which contains a number of dead ends, misconceptions-of-a-newbie, etc.

I hope to have something intelligible out in public no later than Jan 6, and I'll post that link here, as well as get it out in other forums.
For everyone's information - the long promised docs are now showing up on my blog, where all can see and comment. Please see:
 <http://blog.mozilla.com/halfire/2012/01/26/releng_and_git_project/>
Depends on: 730589
Depends on: 730590
Depends on: 730593
Depends on: 730594
No longer blocks: 715314
Depends on: 731329
bug 704551 no longer blocks our support, as we will not be utilizing an internal git server.
Blocks: 677689
Blocks: 528360
Depends on: 739100
Blocks: 743626
Blocks: 743760
No longer blocks: 528360, 743626, 743760
Depends on: 528360, 743626, 743760
Some people have suggested to use github. However, I think it's critically important that we have our own git server, and that none of our services ever pulls from github. This is important for security, because as soon as anybody pulls the tip of a branch from github, he trusts github 100%, and github owns the machine that pulled and built the source. Note that commiting to git is not necessary for this danger, pulling and building is enough to get rooted. The same danger applies to developer machines and build machines.

It's fairly easy to set up a git server, esp. given that the ssh login is already working for hg and svn. I think that must be the first step. Second step would be to get hg -> git sync for mozilla-central (bug 743626). Third step would be to allow commit/push to git (also bug 743626, and described shortly there). Last step and by far most expensive would be to improve the web tools to take advantage of git, e.g. for reviews or similar.
The benefit of Github is in large part the community. We could build a clone, but the network of people is already on Github.

And as you point out, we already have the same security risk (and arguably far moreso) from compromised developer machines.
dietrich: Yes, that's exactly my fear: That we develop a community outside of mozilla.org.

I strongly believe in being "autarkic", i.e. not depending on third-party services and other companies for critical infrastructure. because of security and reliability and independence. Security I have describe above. Independence: You can't improve github. we can fix bugzilla, tinderbox, etc.
These (security and reliability and independence) are the very same reasons why I like open-source.
As for the security risk, Git supports GPG signing of commits and tags (commits only since 1.7.9). The signature encompasses the SHA1 of the parent, which encompasses everything that happened in time before it. See https://github.com/gitster/git/blob/master/commit.c#L1103 for the implementation.

 $ git commit --gpg-sign=DEADBEEF
 $ git log --show-signature

Anyway, if we required that all commits be signed (which could be enforced with repository hooks), then we could verify the authenticity of commits and only allow commits that were signed by white-listed GPG keys.

Git also supports "signing off" on patches for patch-based workflows. Linux uses this model. Someone submits a patch (likely to a mailing list). Then, a reviewer signs off on the patch by GPG signing it. The signed patch is then committed.

This only addresses the expressed security concerns. Fragmentation of the community and reliance on third-party services are separate topics.
Whether Mozilla activity on Github is "fragmentation" or "expansion/inclusion" is a matter of opinion, and is outside the scope of this bug. I should not have brought it up here :( Probably better on one of the newsgroups, but I'm not sure which one.
We had a big fight on #git, with hwine on the one side and 3-5 devs on the other. I'll just document it here.

Summary:
1. I want git.mozilla.org, hwine wants to use github
2. we want all repos (mozilla-central, mozilla-inbound, release branches, ionmonkey etc.pp). in the same git repo as branches. hwine wants to make separate repos, "because that's what we do for hg"
3. we critically need the CVS history in git for development, but hwine doesn't want to provide that. he claims that it's possible to add it later, and I claim that it's impossible (to do properly) afterward, because git specifically tries to protect *against* "changing history"
4. we want to commit to git, but hwine doesn't want to offer that (yet).

And all that although several (!) people independently have already done all of the above in their free time (!), and are saying that it's a no-brainer, and they already have scripts published (!) that we just need to run.

Many of the decisions above are hard to reverse, so it's important that we get them right now. But I and several others have gotten the feeling that hwine has decided what he wants to do and is completely unwilling to change anything despite rational arguments. Sorry, hwine, this isn't personally against you, but it's important to get this right and not repeat the mistakes we made with hg.
(In reply to Ben Bucksch (:BenB) from comment #11)
> We had a big fight on #git, with hwine on the one side and 3-5 devs on the
> other. I'll just document it here.

I suspect that this bug that many may not know about and a random discussion on an IRC channel might not be the best place to have these sorts of discussions and Hal should probably bring up his proposal in a newsgroup thread on dev.planning and then we can have a larger discussion about it.
I feel like this is kind of unfair.  I left perhaps before the discussion was finished, but at least for my part, I opined only on (2).

Moreover, the question I felt strongly about was only whether multiple repos is a user-friendly git workflow.  I think it's not, compared to a single repo, and hwine seemed to disagree.

But I totally agree with hwine that user-friendliness isn't the only important criterion here.  There are back-end considerations which I'm not familiar with (and which perhaps others' implementations don't have to worry about) which may make it hard to have a single git repo.  And there's also the fact that changing things now might delay the introduction of the service.

Anyway, this isn't a democracy, nor is it rule by loudest voice.  It's Hal's project, and I trust him to do what's right.  I'd rather have one git repository, but it's not the end of the world to set up a bunch of remotes.  I feel like I made a bigger deal of this than it is on IRC, in my frustration.  I'm sorry, Hal.
Has this been taken to a public list yet? I think the topics in the previous comments warrant more widespread discussion and community vetting.
I'm going to reclaim this bug for the tracker task it was intended to be, and ask that some of the forward looking discussions happen in another venue (bugs or lists).
The current technical work has been moved to bug 745989 - this work is intended to be foundational, and not preclude any future changes on a larger scale.
As a further guide to commenting and dependency assignments, this bug is focussed on those projects using the services of the automated build & test farm maintained by releng. Bug 528360 is for support of other coding efforts at Mozilla using git.
Depends on: 745989
No longer depends on: 528360, 730589, 730590, 730593, 730594, 743626
(In reply to Gregory Szorc [:gps] from comment #14)
> Has this been taken to a public list yet? I think the topics in the previous
> comments warrant more widespread discussion and community vetting.

Gregory, please go ahead, if you wish.

Hal, as for your project, my main request is to include the CVS history, because that's a decision that cannot be reverted later. It's not possible to prepend history in git without hacks that break in many situations. All the other points in comment 11 can be remedied later - they might provide a social challenge to be changed later, but the CVS history is a technical challenge.
> for the tracker task it was intended to be

hwine, could you please document *what* *exactly* you want to do here? Because there is no concrete description here.
(In reply to Ben Bucksch (:BenB) from comment #16)
> (In reply to Gregory Szorc [:gps] from comment #14)
> > Has this been taken to a public list yet? I think the topics in the previous
> > comments warrant more widespread discussion and community vetting.
> 
> Gregory, please go ahead, if you wish.

I would prefer that Hal or someone else more familiar with things start it to ensure that all the points they wish to convey are communicated. If I do it, I fear I may inadvertently put Hal or others in a defensive position by not fully communicating important facts.
None of this should put anyone in a defensive position - what has become clear is that this bug was completely misinterpreted by anyone who came to it without a verbal introduction first.

The intent of this bug is to track a series of incremental improvements over a prolonged duration in the support of git for projects using the build-and-test on commit machinery operated by releng. At the moment, the first of these is being implemented (as described in comment #15).

As everyone associated with this bug has always realized, the next layer of improvements require consultation with diverse stakeholders. This bug is not the place for those discussions, nor was it ever intended to be.
hwine, it's best to keep bugs specific to a clearly defined goal, and clearly state that goal in the description of the bug, and then later not morph it. If any of this is not given, usually chaos ensues.
Unfortunately, "improvements for git" is still not clear enough. As for consultation and discussion, this is best done on the newsgroup, as Gregory has suggested.
So we had an impromptu meeting and we came up with a list of action items:

* We need a build script that works within single directory. This will be worked on by Catlee and DXR team.
* We will build against both tip DXR code, and a stable DXR release. We need to create a branch and hg repo for the stable code. I'll be doing this.
* Ne need better tests/verification of DXR builds. DXR team needs to address this, but I'll need to help with the test framework, so that tbpl/autolog can process error messages correctly.
(In reply to comment #21)
> So we had an impromptu meeting and we came up with a list of action items:
> 
> * We need a build script that works within single directory. This will be
> worked on by Catlee and DXR team.
> * We will build against both tip DXR code, and a stable DXR release. We need to
> create a branch and hg repo for the stable code. I'll be doing this.
> * Ne need better tests/verification of DXR builds. DXR team needs to address
> this, but I'll need to help with the test framework, so that tbpl/autolog can
> process error messages correctly.

This is added to the wrong bug... right? :-)
Argh, yes. Too many tabs!
Product: mozilla.org → Release Engineering
Seems like we've settled on how much git and hg support we're providing at this point. Time to close this?
Flags: needinfo?(hwine)
QA Contact: mshal
Yeah, let me do a proper cleanup of all the dependencies first -- so I'll move it as well.
Component: Other → General
Product: Release Engineering → Developer Services
QA Contact: mshal
I believe all the work originally intended here is either done or decided against.

Please open new bugs for anything that is still wanted.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(hwine)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.