[ros-dev] Improving our procedure

[victor martinez]

Hi,
This is incredible. I can understand a delay in a release because fixing Blockers, i can
understand a delay because we are afraid of "2012" movie.But i can not
understand why the Changelog is not made!!. On 3rd of November Aleksey sent an email
saying a Blocker was present to release 0.3.11, this means that on 3rd of November a full
Changelog should have been done and just  2 lines (explaining the Fix,if needed) should
have been added afterwards. But the fact is that the Blocker has been solved more than one
week ago, that we are still waiting for changelog to be done(after more than a month) and
that the binaries are stored in SF waiting indefinitely to link them.
So this strikes again, what is happening with Changelogs?What happens if noone wants to
write his Changelog?Are we going to stay here waiting it indefinitely?Is our actual
procedure correct?Or is it not practical?How can we shorten the time for a release?What
happens if one of the Steps before releasing (like Changelog Step) is not properlly
done?Do we have a PlanB?

Let´s review our Teorical steps before a release and finding Bottlenecks as i do in my
work:
1) Coding Time.During this time Devs creates ReactOS code.Since 0.3.9 also the GoldenApps
and CandidateApps are being tested during this time in regular basis to reduce the
possible Blockers.
2) Choosing Minute. An ISO is chosen as Candidate. Doubts: When the Candidate is
chosen?Following which criterias?Why sometimes we take an ISO after one month and other
times after 2 months?
3) Colin creates a Pre-release ISO. 
4) Colin creates the 0.3.XX wikipage.Tests begins and Changelog begins to be written.
5) Performing Testing on Candidate. It usually takes less than a week, and thanks to
previous testings in Coding Time, there are less Blockers each time.
6A) Blocker found. If a Blocker is found, a regression testing begins(if needed) and a
patch/hack is made.GoTo 7
6B) Blocker not found. prerelease ISO is released as definitive.END.
7)Patch is added to release branch, Colin creates a second RC and testers perform a full
test focusing in the regression. Release.END.

Let´s begin studying the 0.3.11 case.
Step 1 was done correctly.We have devs still working on ROS.great!
Step 2 was a CHAOS. I have been asked to select first an ISO before asking Colin to make a
prerelease ISO of it. Testing that first ISO we found the Vmware regression but it took a
little(more than a month to fix it) so we select a different ISO and we performed a full
testing (again) before asking Colin to create a prerelease.
Changing the ISO is not inside the Teorical steps,but since the patch for Vmware wasnt
made and we had time it didnt suppose really a lose of time.
Step 3.First bottleneck. It took a little to contact with Colin,because he was busy with
RL, so we had to wait him to create a Branch,include the reverts and create the
prerelease.If I recall correctly it took more than a Week. Without the prerelease done is
impossible to test anything.We should have an alternative to Colin in case Colin is busy
with RL.We dont have a PlanB for this situation.
Step4. Colin creates the Wikipage.
Step5.Test begins but Changelog didnt begin to be written, it has been asked twice via ML,
and zillions via IRC. Currently we are waiting for having it complete.

And now second bottleneck:
In 0.3.11 case,Blockers were solved BEFORE prerelease was made, so when Colin uploaded the
prerelease iso it doesnt have any Blocker and it is ready to be released.And then the
bottleneck comes:Changelog. Changelog can be created without hurry if we are in step 6A(a
Blocker found) but in case 6B (as 0.3.11 prerelease is) you dont have real time to create
it. When a Blocker is found,Changelog can be created during the extra time of
regtesting+finding a patch+adding to branch+creating a new iso+performing again all the
Tests, (this extra time is usually 4 weeks). But when non Blocker is found in Step6,
Changelog stops our release.You cant made a proper Changelog of 2 months changes in a
week. So our procedure currently is not optimal at all.

First bottleneck: Relying in just one guy to merge stuff in the branch+create the ISO
should be solved.
Second bottleneck: If we expect that our prereleases doesnt have any blocker,then
Changelog will be stopping our releases. To avoid this i propose a new procedure for
0.3.12, which is more multitasking.

STEP1: Create 0.3.12 Changelog page.Open to include the changes since the Beginning.
STEP2: Coding time. Meanwhile,testers tests goldenapps and candidateapps.
STEP2: Choosing minute.The candidate ISO is selected, Devs are warned in Changelog page
which is the latest revision to include the changes and that just they have one week to
finish their Changelogs. 
STEP3: Release Engineers(not just Colin) creates the branch and the prerelease iso. 
STEP4: Release Engineers creates a Test 0.3.12 wikipage.
STEP5: Tests are performed. This gives one week of extra time to have the Changelog
done(more if a blocker is found).

If Changelog is critical for releasing, then we need a PlanB if a Dev rejects or cant make
a changelog.This is called SCRIPT. I´m really bored of those guys who doesnt want the
Script but doesnt write their changes in Changelog neither.
we should have a Script that by request or by lazyness of the devs can make a Changelog
giving a revision range,a component or|and an author.This will make the life easier and
healthier.Btw, some Devs doesnt want to waste the time writting Changelogs and prefer
coding, so this tool is a must.I dont want to see devs sending less code to avoid writting
a changelog.

Sorry about this long post.My fingers were trained in our Wiki this morning, btw, i hope
someone can review my recent changes on the Changelog 0.3.11 to be sure i put the commits
in their correct place.Thanks.







 		 	   		  
_________________________________________________________________
Date una vuelta por Sietes y conoce el pueblo de los expertos en Windows 7
http://www.sietesunpueblodeexpertos.com/