개발?세발?

원문 : https://source.android.com/source/roles.html

Project Roles

프로젝트 역할

The Android Open Source Project (AOSP) includes individuals working in a variety of roles. Google is responsible for Android product management and the engineering process for the core framework and platform; however, the project considers contributions from any source, not just Google. This page describes the kinds of roles that interested parties can take on.

안드로이드 오픈소스 프로젝트에 각양각색의 역활을 개개인이 담당해 왔다. 구글은 안드로이드 제품 관리와 중요 프레임워크와 플랫폼의 프로세스 인지니어링을 책임진다. 그러나 구글 뿐만 아니라 많은 참여가 모든 소스에서 있었다. 이 페이지는 참여 가능한 흥미로운 역활의 종류 부분을 설명 한다.

Contributor

컨트리뷰터

"Contributors" are those making contributions to the AOSP source code, including both employees of Google or other companies, as well as individual developers who are contributing to Android on their own behalf. There is no distinction between contributors who are employed by Google and those who are not; all engineers use the same tools (git, repo, and gerrit), follow the same code review process, and are subject to the same requirements on code style and so on.

"컨트리뷰터"는 구글 또는 다른 기업 직원과 자신의 이익을 위한 개인적인 개발자들로 AOSP 소스 코드에 기여하는 사람들이다. 구글 직원가 그렇지 않은 사람들의 차이는 없다. 모든 인지니어들은 같은 툴(git, repo와 gerrit)을 사용하고, 같은 코드 리뷰 절차와 같은 코드 스타일을 따른다.

Developer

디벨로퍼

"Developers" are engineers writing applications that run on Android devices. There is often little difference in skillset between a developer and a contributor. But AOSP uses "developer" to distinguish between engineers using the platform and those contributing to it. Developers (along with users) are the "customers" of the platform the contributors create. As such, we talk about developers a lot, though this isn't technically a separate role in the AOSP per se.

"디벨로퍼"는 안드로이드 기기에서 실행되는 어플리케이션을 작성하는 엔지니어들이다. 디벨로퍼와 컨트리뷰터 사이에는 스킬셋에서 약간의 다른점이 종종있다. 하지만 AOSP에서는 "디벨로퍼"를 플랫폼을 사용하는 엔지니어 인지 기여하는 엔지니어인지로 구분 짓는다. 디벨로퍼(사용자와 같이)는 컨트리뷰터가 만든 플랫폼의 "커스터머(소비자)"이다.  우리는 개발자를 많이 말하지만, AOSP 자체의 기술적으로 나눈 것은 아니다.

Verfier

버리피어

"Verifiers" are responsible for testing change requests. After individuals have submitted a significant amount of high-quality code to the project, the project leads might invite them to become verifiers.

Note: At this time, verifiers act similarly to approvers.

"버리피어"는 변화된 요청을 테스트한다. 개인이 중요한 고난이도 코드를 제출을 하면, 프로젝트 리더는 그들을 버리피어로 초대 한다.

추신 : 버리피어는 어프로버와 비슷하다.

Approver

어프로버

"Approvers" are experienced members of the project who have demonstrated their design skills and have made significant technical contributions to the project. In the code-review process, an approver decides whether to include or exclude a change. Project leads (who are typically employed by Google) choose the approvers, sometimes promoting to this position verifiers who have demonstrated their expertise within a specific project.

"어프로버"는 프로젝트에서 디자인 스킬을 입증했거나, 중요한 기술적 기여자들이다. 코드 검토 과정에서 어프로버는 변화된 코드를 포함 시킬지 제외시킬지 결정을 한다. 프로젝트 리더(구글 직원)가 어프로버를 선택을 한다. 종종, 프로젝트의 전문지식을 입증받은 버리피어들이 홍보 하기도 한다.

Project Lead

프로젝트 리드

Android consists of a number of sub-projects; you can see these in the git repository as individual .git files. "Project leads" are senior contributors who oversee the engineering for individual Android projects. Typically these project leads are Google employees. A project lead for an individual project is responsible for the following:

안드로이드는 많은 서브 프로젝트들로 구성되어 있다. 깃 저장소에서 개별적으로 확인 할 수 있다. "프로젝트 리더"는 개별적인 안드로이드 엔지니어링을 총괄하는 중요한 콘트리뷰터이다. 특별히 안드로이드 프로젝트에서는 구글 직원들이다. 개별적인 프로젝트의 프로젝트 리더는 아래의 책임이 있다.

• Lead all technical aspects of the project, including the project roadmap, development, release cycles, versioning, and quality assurance (QA).

• Ensure the project is tested by QA in time for scheduled Android platform releases.

• Designate Verifiers and Approvers for submitted patches

• Be fair and unbiased while reviewing changes. Accept or reject patches based on technical merit and alignment with the Android strategy.

• Review changes in a timely manner and make best efforts to communicate when changes are not accepted.

• Optionally maintain a web site for the project for information and documents specific to the project.

• Act as a facilitator in resolving technical conflicts.

• Be a public face for the project and the go-to person for questions related to the project.

• 프로젝트 로드맵, 개발, 릴리즈 사이클, 버전 관리, 품질 관리(QA)을 포함한 프로젝트의 기술적인 측면을 이끌어야한다.
• 정해진 안드로이드 플랫폼 릴리즈를 위해 품질 관리로써 프로젝트 테스트를 확실히 해야한다.
• 제출된 부분들을 위해 버리피어와 어프로버를 지정해야 한다.
• 코드 검토는 공평하고 편견없이 한다. 패치 내용의 인정과  거절은 기술적인 이익과 안드로이드 정책의 일정함을 기준으로 한다.
• 코드 검토는 일정한 방식으로 하고, 거절된 코드는 정중히 전달한다.
• 프로젝트 정보가 있는 웹사이트와 프로젝트에 관한 문서는 선택적으로 유지시킨다.
• 기술적 문제를 풀수 있게 협력한다.
• 프로젝트에 대해 일반적인 입장을 취하고, 프로젝트에 대한 질문은 인간적으로 대한다.

 유명한 호주의 닉 부이치치.

네버네버 깁업.

Codenames, Tags, and Build Numbers

코드네임, 태그, 그리고 빌드 번호.

At a high level, Android development happens around families of releases, which use code names ordered alphabetically after tasty treats.

높은 레벨의 안드로이드 개발은 알파벳 오름차순으로 정렬된 음식이름의 코드네임으로 된 배포단위가 일어 났다.

Platform Codenames, Versions, API Levels, and NDK Releases

플랫폼 코드네임, 버전, API 레벨 그리고 NDK 배포

The code names match the following version numbers, along with API levels and NDK releases provided for convenience:

코드 네임은 버전 넘버와 함께 편의를 위해 제공되는 API 레벨, NDK배포와 매칭이 된다.

Starting with Cupcake, individual builds are identified with a short build code, e.g. FRF85B.

Cipcake부터 개별적인 빌드는 FRF85B와 같은 짧은 빌드 코드를 가지게 되었다.

The first letter is the code name of the release family, e.g. F is Froyo.

첫 글자는 배포 단위의 코드네임이다. 예를 들어 F는 Froyo이다.

The second letter is a branch code that allows Google to identify the exact code branch that the build was made from, and R is by convention the primary release branch.

두 번째 글자는 구글이 확실히 어느 부분에서 시작된 코드인지 확인 할 수 있는 브랜치 코드이다. R은 규칙에 의한 주요 릴리즈 지점이다.

The next letter and two digits are a date code. The letter counts quarters, with A being Q1 2009. Therefore, F is Q2 2010. The two digits count days within the quarter, so F85 is June 24 2010.

다음 글자와 두 숫자는 날짜 코드이다. 글자는 1분기당 1씩 증가하며 A는 2009년 1분기이다. 그러므로 F는 2010년 2분기이다. 두 숫자는 분기내 하루를 나타낸다. 그러니까, F85는 2010년 6월 24일 이다.

Finally, the last letter identifies individual versions related to the same date code, sequentially starting with A; A is actually implicit and usually omitted for brevity.

마지막으로, 마지막 글자는 같은 날에 개별적인 구분자이다. A부터 연속적으로 지정되며 보통 A는 생략된다.

The date code is not guaranteed to be the exact date at which a build was made, and it is common that minor variations added to an existing build re-use the same date code as that existing build.

날짜 코드는 정확히 빌드된 날짜에 맞춰 붙는 것이 아니다. 보통 이미 빌드된 코드의 같은 날짜 코드를 마이너한 변화를 추가하여 재 빌드한다.

SourceCode Tags and Builds

소스코드 태그와 빌드

Starting with Donut, the exact list of tags and builds is in the following table. Factory images and binaries for Nexus devices can be downloaded from:

Donut부터 태그와 빌드 리스트는 아래 테이블에 있다. 공장이미지와 넥서스 바이너리는 아래 링크에서 다운 받을 수 있다.

https://developers.google.com/android/nexus/images

https://developers.google.com/android/nexus/drivers

(테이블은 여기를 참조해주세요. 너무 태이블이 커서.....)

The branches froyo, gingerbread, ics-mr0, ics-mr1, jb-dev, jb-mr1-dev, jb-mr1.1-dev, jb-mr2-dev, kitkat-dev represent development branches that do not exactly match configurations that were tested by Google. They might contain a variety of changes in addition to the official tagged releases, and those haven't been as thoroughly tested.

froyo, gingerbread, ics-mr0, ics-mr1, jb-dev, jb-mr1-dev, jb-mr1.1-dev, jb-mr2-dev, kitkat-dev는 구글이 테스트한 것과 정확히 일치하지 않는 개발 지점의 대표한다. 그들은 아마 공식으로 이름이 붙은 배포판에 다양한 변화를 추가한 것이고, 정밀한 테스트가 되지 않았을 것이다.

To differentiate between releases, you may obtain a list of changes associated with each project by issuing the following command and passing it the two branch tags:

배포된 것들 사이의 프로젝트 별 이슈 사항 및 두 지점의 다른 점은 아래의 명령어를 통해서 확인 할 수 있다.

$ repo forall -pc 'git log --no-merges --oneline branch-1..branch-2'

For example:
예를 들어 :

$ repo forall -pc 'git log --no-merges --oneline android-4.4.2_r2..android-4.4.2_r1'

And to output to a text file:
그리고 text 파일로 출력 할 수 있다.

repo forall -pc 'git log --no-merges --oneline android-4.4.2_r2..android-4.4.2_r1' > /tmp/android-4.4.2_r2-an

Honeycomb GPL Modules

Honeycomb GPL 모듈

For Honeycomb, the entire platform source code isn't available. However, the parts of Honeycomb licensed under the GPL and LGPL are available under the following tags:

Honeycomb의 전체 플렛폼 소스코드는 사용 할 수 없다. 그러나, GPL과 LGPL의 라이센스 Honeycomb중 아래에 나타난 것들은 사용 할 수 있다.

There is no manifest that contains exactly those. However, there are manifests that allow building those components. The following commands work for 3.0_r1.1, and using other versions can be done by switching the git checkout paramater, and if necessary the -m parameter in repo init. The git checkout command outputs an error for the non-GPL projects, where it can't find the tag in question.

그것들은 정확히 그것들을 나타내는 것이 아니다. 그러나 그것들의 컴포넌트를 빌딩 한 것이다. 아래의 명령어는 3.0_r1.1(git 체크아웃 파라미터를 변경 하면 다른 버전도 동작한다.) 버전을 위한 것이고, repo init(repo 초기화)가 필요하다면 -m를 같이 써도 된다. 위의 표에 Tag로 나타나지 않은 GPL 프로젝트가 아닌 git 체크아웃 명령어는 에러가 난다.

$ repo init -b master -m base-for-3.0-gpl.xml
$ repo sync
$ repo forall -c git checkout android-3.0_r1.1