15 Dec
2009
15 Dec
'09
2:29 p.m.
Fist of all. Thx for adding most missing changes to the log. I think the
ppl really appreciate that.
Then to your comments. Yes, I confirm that we have some problems with
realeases, thats why I more than once asked for just putting out a sorta
useable ISO as release in the past. OK, I now know its a stupid idea in
our improving state. We could have done it my way two years ago. So I
fully agree with your ideas to get rid of bottlenecks and elect
something like a Vice Release Engineer. We cant put all that work on
Colin forever, especially when RL is bitchy again. As next we need a
better way to get the changelog done. We already have a script to do it
semi automatic, but it only works if ppl follow comit message rules and
most dont. So we could of course use it again and let ppl who dislike
the rule make their stuff by hand or we have to find something better /
less work intensive. Like just fireing the commi messages unsorted and
in row into the changelog. Many Projects do it this way. Not nice, but
as Plan B quite useful IMO.
victor martinez schrieb:
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.
------------------------------------------------------------------------
Hasta las ovejas de Sietes son expertas en Windows 7. ¡Conócelas!
<http://www.sietesunpueblodeexpertos.com/>
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev