No subject

Fri Oct 23 11:22:42 CEST 2009

important for the project.

It=92s very unfair that Victor spent the first half of his day filling =
out the
changelog because other people didn=92t do it. It=92s also very =
considerate of
him to do so and he deserves a big thank you for doing that!

=20

Considering our last release was July (Yes, f**king July), when I first =
read
through the changelog to compile the release notes one of the sentences =
I
found myself writing was =93This version is anticipated as a =
compatibility and
stability release rather than the usual large architectural changes the
releases bring=94.=20

After thinking something was wrong considering  5 months of work, I =
looked
back through the SVN log and realised we only had about 10% of the =
changes
filled out.....

=20

Filling out the changelog is part of being a reactos developer and if
generating this at release time isn=92t convenient then steps to fix =
this need
to be taken.

=20

Personally, I=92ve never been a fan of using a commit log script. In my
opinion such a thing will be too unreliable, produce unmeaningful =
=91commit
log messages=92 instead of meaningful =91change log messages=92 and it =
takes the
fun out of writing comical/banter oriented commit messages.

=20

Back in the day .... we didn=92t used to have any problems in writing =
commit
logs. Devs were proud to get their changes into the log and did so in a
timely fashion with easily decipherable output.

What=92s changed? Why has it become so difficult to do this in the =
recent
years??=20

=20

The lack of a complete changelog has held the release back for around a =
week
now.

It=92s a shame that it came to this, but I propose that we continue to =
hold up
releases until commit logs are complete. They really are that important =
both
for having a =91wow factor=92 log to show to the public and to have some
substance with which to write appealing release notes. The release notes
especially are read by a huge number of people and is our chance to sell
ourselves.

=20

Ged.

=20

P.S. We are still missing changelog entries........

=20

=20

=20

From: ros-dev-bounces at reactos.org [mailto:ros-dev-bounces at reactos.org] =
On
Behalf Of victor martinez
Sent: 15 December 2009 13:39
To: ros-dev at reactos.org
Subject: [ros-dev] Improving our procedure

=20

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=B4s 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.=20
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=B4s 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.=20
STEP3: Release Engineers(not just Colin) creates the branch and the
prerelease iso.=20
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=B4m 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.

  _____ =20

Hasta las ovejas de Sietes son expertas en Windows 7. =A1Con=F3celas!
<http://www.sietesunpueblodeexpertos.com/>=20

------=_NextPart_000_0040_01CA7DA0.2C2B6040
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-GB link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>From a publicity perspective the changelog and release =
notes are
very important for the project.<o:p></o:p></span></p>

It&#8217;s very unfair that Victor spent the first half =
of his
day filling out the changelog because other people didn&#8217;t do it. =
It&#8217;s
also very considerate of him to do so and he deserves a big thank you =
for doing
that!<o:p></o:p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

Considering our last release was July (Yes, f**king =
July), when
I first read through the changelog to compile the release notes one of =
the
sentences I found myself writing was &#8220;This version is anticipated as a =
compatibility
and stability release rather than the usual large architectural changes =
the
releases bring&#8221;. =
<o:p></o:p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>After thinking something was wrong considering =A05 =
months of work,
I looked back through the SVN log and realised we only had about 10% of =
the
changes filled out.....<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Filling out the changelog is part of being a reactos =
developer
and if generating this at release time isn&#8217;t convenient then steps =
to fix
this need to be taken.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

Personally, I&#8217;ve never been a fan of using a commit =
log
script. In my opinion such a thing will be too unreliable, produce =
unmeaningful
&#8216;commit log messages&#8217; instead of meaningful &#8216;change =
log messages&#8217;
and it takes the fun out of writing comical/banter oriented commit =
messages.<o:p></o:p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

Back in the day .... we didn&#8217;t used to have any =
problems
in writing commit logs. Devs were proud to get their changes into the =
log and
did so in a timely fashion with easily decipherable =
output.<o:p></o:p>

What&#8217;s changed? Why has it become so difficult to =
do this
in the recent years?? <o:p></o:p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The lack of a complete changelog has held the release =
back for around
a week now.<o:p></o:p></span></p>

It&#8217;s a shame that it came to this, but I propose =
that we
continue to hold up releases until commit logs are complete. They really =
are
that important both for having a &#8216;wow factor&#8217; log to show to =
the
public and to have some substance with which to write appealing release =
notes. The
release notes especially are read by a huge number of people and is our =
chance
to sell ourselves.<o:p></o:p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Ged.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>P.S. We are still missing changelog =
entries........<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0cm 0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> ros-dev-bounces at reactos.org
[mailto:ros-dev-bounces at reactos.org] <b>On Behalf Of </b>victor =
martinez<br>
<b>Sent:</b> 15 December 2009 13:39<br>
<b>To:</b> ros-dev at reactos.org<br>
<b>Subject:</b> [ros-dev] Improving our procedure<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

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 =
&quot;2012&quot;
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&nbsp; 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=B4s 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=B4s 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=B4m 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. 
 
 
 
 
<o:p></o:p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><span
style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif"'>

<hr size=3D2 width=3D"100%" align=3Dcenter>

</span></div>

Hasta
las ovejas de Sietes son expertas en Windows 7. <a
href=3D"http://www.sietesunpueblodeexpertos.com/" =
target=3D"_new">=A1Con=F3celas!</a><o:p></o:p>

</div>

</body>

</html>

------=_NextPart_000_0040_01CA7DA0.2C2B6040--