Project

General

Profile

V30 - Sprint #5 » History » Version 6

Johannes Bornhold, 29.01.2015 07:26

1 6 Johannes Bornhold
h1. Draft - Release support
2 1 Johannes Bornhold
3 5 Johannes Bornhold
Main objectives to support the release:
4 1 Johannes Bornhold
* Bugfixing of high priority issues
5 5 Johannes Bornhold
  Since we did our first release, there will be a few unplanned things popping up with high priority. Expected sources are our regression tests and feedback from the first Customers trying out our new release.
6
* Technical reviews of further overhauled sections in our tech docs for v3.0.0
7
8
User interface improvments
9 6 Johannes Bornhold
** Forms overhaul - Canonical HTML structure in our Style section / Start of bigger epic
10 1 Johannes Bornhold
** Changeset
11
** Comments
12
13
Process improvements
14
* Parallel test runs in Jenkins
15
  Avoids overhead and frees time lost due to stuck builds. First steps for further improvements to free even more time.
16
17 5 Johannes Bornhold
18 6 Johannes Bornhold
Refinements:
19
"Support the next deal": JIRA integration, Jenkins integration "two way", Smart Commits
20
21
22
23 1 Johannes Bornhold
h2. Statistics
24
25
We'll take the last three sprints to get a good indication of how many things we should put into this Sprint.
26
27
28
h2. Issue handling
29
30 6 Johannes Bornhold
We classify new issues according to the question of how much it would prevent our users from using our product. Everything which would be a serious impediment from that perspective will be in priority "High" and will be sneaked in into our running Sprint. This is an attempt to find a good trade off between staying focused and keeping productivity high and on the other side reacting to severe issues in a timely manner.
31 1 Johannes Bornhold
32
Please notify Johannes in case you think that you found an issue which would qualify as priority "High".
33
34
35
h2. Review changes
36
37
* We are involving Martina and Greg more into our workflow, starting with our daily standup meeting and planning. This way they know what we are up to and have a chance to prepare their own schedule better.
38
* We (mainly Johannes) is making the check_screens script available so that this can be used by every team member to quickly verify if frontend changes have unintended collateral damage in other places. This is expected to pay off within a few days already, since it avoids extra loops when checking PRs.
39
* We (mainly Greg) kick off test automation. This is a prevention of letting Greg become more and more a bottleneck.
40
41
42
h2. Links
43
44 2 Johannes Bornhold
"Issues overview":https://bugs.rhodecode.com/projects/rhodecode-3-0/issues?utf8=%E2%9C%93&set_filter=1&f[]=fixed_version_id&op[fixed_version_id]=%3D&v[fixed_version_id][]=31&f[]=&c[]=tracker&c[]=status&c[]=priority&c[]=subject&c[]=assigned_to&c[]=updated_on&group_by=priority