Skip to content

rules_of_daily_work

Jump to bottom
chyyuu edited this page Jul 9, 2019 · 45 revisions

OPENTHOS日常办公/研发基本原则

上班后

  • 查看：使用openthos查看到上班前各种渠道（openthos-dev maillist，openthos-dev微信群）的重要email和微信信息：重点需解决问题，已修复问题，升级信息等。
  • 升级：如在开发阶段，且昨日没有警告说昨日更新的系统不能升级，则在线升级昨日的系统。如果升级失败，可以回滚到之前的稳定版本。
  • 专一：对手机做完基本配置或处理（如扫描二维码登录等）后，工程师到办公室并开始工作前，自行把手机放到托管处（9:00am到12:00am ， 13:00pm到18:00pm）。确保办公期间基本上只使用openthos设备

办公期

  • 使用：只使用openthos作为办公开发环境。熟悉各种配置。
  • 反馈：在使用中发现了问题，及时查找用户使用手册并尝试解决。如解决不了，与测试人员联系，请测试人员帮忙解决。如果是bug，则在email头加上[bug][proj name]，并发出email，让测试人员和对应开发人员很容易注意到。
  • 更新：测试人员根据自己和他人的反馈以及openthos的改进升级，及时更新openthos用户使用手册
  • 提交：在提交代码前，至少由其他人进行了review，并请专人再次review并提交。
  • 编译镜像：请在编译前删除out目录以保证生成镜像的一致性，并为生成的img附带repo.prop文件(repo forall -c 'echo $REPO_PATH $REPO_LREV')
  • 开发问题：开发过程中遇到不好解决或耗时较久问题可以先记录到瓶颈问题及解决方法，开会的时候会讨论这个问题，记录方法也方便之后的人参考。

下班前

  • 日报告：当天完成日报告。具体内容如下"个人日报告内容要求"
  • 周报告：每周的规定时间（如周五）完成周报告。具体内容如下"个人/小组周报告内容要求"
  • 总结：工作人员（包括开发，测试，办公等）对今日的工作进行总结，写在github上，说明开发的成果/问题，使用的问题和解决方法。测试人员对工作人员提出的问题进行进一步的总结和归纳，形成重点问题列表，便于开发人员注意并及时改进。
  • 迭代：测试人员基于当日的开发和测试情况，生成当日的openthos新版本，并保留早期稳定版本便于回滚。如升级，当日发出email，通知大家第二天上午升级。

个人日报告内容要求

  • 当天的工作进展简述，在本周中计划中的进度（百分比）估计
  • 到当天为止，属于个人的优先级最高的前2个bug/feature(禅道id，发现时间，存在时间，预计修复/完成时间，bug简述)
  • 如果有任务变动，任务变动说明
  • 如果修复/完成了属于个人的优先级最高的两个bug/feature，需明确指出。

个人周报告内容要求

  • 本周工作进展简述
  • 分析相对于上周计划，本周的变化情况，本周的完成情况说明。如果没完成，对没完成原因的分析
  • 对优先级最高的前5个bug/feature(禅道id，发现时间，存在时间，预计修复/完成时间，bug简述)的修复/完成情况说明和计划分析
  • 与小组长讨论后的下周计划简述

小组周报告内容要求

  • 基于本组组员的周报告内容，给出本周本组的工作进展简述
  • 分析相对于小组上周计划，本周的变化情况，本周的完成情况说明。如果没完成，对没完成原因的分析
  • 对优先级最高的前10个bug/feature(禅道id，发现时间，存在时间，预计修复/完成时间，bug简述)的修复/完成情况说明和计划分析
  • 与评测组讨论，形成本组下周计划简述，通知到个人更新个人下周计划

测试&使用组日/周评测要求

  • 每日/周分析评价个人和小组的日/周报告，对照上周计划，分析日/周进度和潜在问题。
  • 每日/周分析评价个人和各组对最新交互手册的完成情况，可用性完成情况，形成文档。
  • 每日/周分析个人和各组对优先级“重”的bug/feature(禅道id，发现时间，存在时间，预计修复/完成时间，bug简述)的完成情况
  • 每日/周分析并调整优先级“重”的bug/feature列表和完成人，与小组长讨论，更新小组周报告的计划
  • 每日分析每人对openthos使用手册的更新情况（随着软件的更新，文档需及时对应更新），每周形成总结报告
  • 每周五测试组在网上发布本周的一个稳定版本（包括ISO下载地址，ChangeLog），如有特殊原因（比如测试中发现big bug），可暂停发布。
  • 每周release最新版本的时候,把当时的代码运行repo manifest -r -o .repo/manifest/openthos_20180725.xml命令把源码快照留下，方便对比快照查找问题

用户/测试/开发需确保的一致性要求

每组/每人一周要解决的最重要的bug/feature是需要用户，测试-开发三方达成共识的。

人员界定

  • 用户：刘锋，大楼物业，苟腾嶕，张婕为主，以及所有开发测试工程师
  • 测试：测试工程师和相关开发工程师
  • 开发：参与开发的工程师

bug/feature的接收和测试处理过程

  • bug/feature的提出由用户主导提出（微信/电子邮件/口头/其他方式），由刘明明安排张琳萍，江沁轮流进行统一收集，提交给测试组重现和分析；
  • 测试组进行初步分析，并进一步与开发组评价，按照迫切/常用/严重影响使用等指标进行排序，指定预计完成时间和完成人，并把反馈给用户。
  • 对于需要解决的feature，需把需求明确反映到用户交互手册和用户使用手册中。
  • 对于需要解决的bug/feature，需把现象说明明确/量化地反映到禅道或bugzilla类似系统中。
  • 测试根据之前的交互手册等量化指标进行审核，确保来源与用户的bug/feature不与量化指标冲突
  • 用户+测试关注每天的进展，测试方需列出优先级高的bug/feature的产生时间，存在时间，完成人等信息。
  • 开发方根据用户+测试提出的bug/feature为目标，制订本周计划，并尽快保质保量完成。

日常考勤、请假和年假规定

  • 每个工作日上下班打卡

  • 每个工作日工作时间不少于9小时（含午休1小时），早上不晚于10点到岗

  • 事假需提前说明，可用请假前的加班累计工时或年假抵消

  • 病假需提供病假条或诊断证明，每个月2天内病假可不计入考勤

  • 入职<5年内的工程师，年假5天

  • 入职<10年内的工程师，年假10天

  • 入职>10年的工程师，年假15天

  • 年假在当年用完，不能攒到下一年

入职

  • 根据工作性质，会有2～3个月的试用期。

离职

  • 个人对单位提出离职申请需要提前一个月，并完成交接工作，需领导签字确认。
  • 单位对个人提出离职要求需要提前一个月，并完成交接工作，需领导签字确认。

日常使用openthos的奖励规则（试行方案）

  • 找出测试组未发现的bug
  • 提出一个大家认可的feature
  • 在不影响工作进度的情况下，解决个人感兴趣的bug
  • 比赛日（周三、周五）
    • 周三进行游戏比赛，提前公布游戏内容和规则，前三名奖励，后两名惩罚
    • 周五进行办公比赛，编写规定文档，前三名奖励，后两名惩罚

对OpenThos系统中已有代码打补丁流程

本流程目的

目前我们的repo系统中，尚不支持pull requests这样的团队协作功能，对已有代码的任意修改提交， 有可能造成仓库中代码污染，导致某些系统功能能的失效，严重者导致无法编译整个系统。

特此，针对dm-verity相关的代码提交制定本流程。

补丁流程

  1. 相关开发人员创建本地的测试分支，在本地分支上进行相关测试
  2. 本人测试通过后使用 git send-email --smtp-debug --no-validate --To [email protected] 000* 发送邮件供其他人review
  3. dm-verity相关代码请发送邮件到系统组[email protected]，并抄送[email protected].
  4. 测试组收到邮件后，在本地仓库是创建一个临时分支，打上patch后进行复验。 系统组收邮件后，根据patch所在模块将邮件转发到相关组进行代码人工审核。(实验室内部可以通过镜像的形式给测试组，patch放在服务器上给相关人员review)
  5. 审核通过后，审核人员回复邮件，开发人员进行代码的push推送。 如审核未通过，亦回复邮件说明原因。
  6. 补丁成功提交后，请回复审核通过的邮件，说明代码已提交。

补丁规范

编码风格 ： 沿用各个补丁所在模块的编码风格，对于同当前环境下的编码风格不抵触的地方，可沿用自己的偏好和习惯。
补丁说明 ： 沿用英文的格式风格，例如:标题部分要有补丁所在位置的说明，用": "进行间隔，开始字母大写，标题尽量没有标点， 两个段落间有单独的空行，每段起始部分从第一列开始，每个标点后面有一个空格等。
邮件告知 ： 提交成功的补丁需要发送邮件给[email protected]，需要用git来从命令行发送， 由此保证其格式为纯文本。对于如何发送请参见下文。

提交补丁说明

相关分支 ： 必须有multiwindow分支，是远程对应的x86/multiwindow，可通过git branch -a查看， git checkout -b multiwindow x86/multiwindow来创建此分支到本地。
创建devorg（仅第一次repo sync代码后需要需要）： 先用git remote -v查看，默认有x86，在其路径后面加".git"作为新路径创建， 例如frameworks/base是git://192.168.0.185/lollipop-x86/platform/frameworks/base
创建命令： git remote add devorg git://192.168.0.185/lollipop-x86/platform/frameworks/base.git $@
提交命令： git push devorg multiwindow:refs/heads/multiwindow，有时候可能需要先同步远程，然后再打补丁提交。 相关的同步命令是git pull devorg multiwindow:refs/heads/multiwindow

发送邮件

  • Ubuntu系统
    环境配置 ： 在OPENTHOS中安装Ubuntu，在chroot Ubuntu中，apt-get install git git-mail.
    邮箱配置 ： 编辑/root/.gitconfig，增加[sendmail]根栏目，不同的邮件服务器配置稍有不同， 例如，from = [email protected], envelopesender = [email protected], smtpencryption = None, smtpserver = smtp.emindsoft.com.cn, smtpuser =[email protected] = 587 ， 每项占一行，并用一个tab进行缩进。
    发送邮件 ： 下载补丁到当前目录，假设补丁文件名是000开头，发送命令是:git send-email --smtp-debug --no-validate --To [email protected] 000*，然后按照提示进行相关的输入即可，例如期间需要确认，需要输入密码等。
    也可以客户端来发送邮件，但需要注意，以纯文本的形式发出。
  • Openthos系统（使用终端登录服务器，进入个人docker）
    环境配置 ： 使用apt-get安装git-email
    邮箱配置 ： 在邮箱配置好smtp服务为开启状态
    发送邮件 ： (以163邮箱为例)执行命令生成补丁git format -1 -o xxx.patch，使用发送命令 git send-email xxx.patch —from [email protected] —to [email protected] —smtp-server smtp.163.com —smtp-user [email protected] 然后输入邮箱密码即可发送
Clone this wiki locally