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/
Some thoughts on this from my side:
Creating the changelog is boring and time consuming. We should enforce some kind of commit message regulation that allows to automate changelog creation as discussed earlier. Opening changlogs early sounds good, but we should be sure which kind of release we're aiming for (0.3.12 or 0.4?). Or just name it "next changelog" and rename it later. Why do we have two release engineers if only Colin does Releases?
Certain changelog entries are still missing entries as it seems (hi Jim!). I'll have look this evening concerning your entries Victor.
Why would anyone object using a script for creating a changelogs and on the other hand not create his entries manually? I don't see any reasons against using a script (except for missing commit message guidelines - but that can change).
Gregor
2009/12/15 victor martinez vicmarcal@hotmail.com
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:
- 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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:
- 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
From a publicity perspective the changelog and release notes are very
important for the project.
Its very unfair that Victor spent the first half of his day filling out the changelog because other people didnt do it. Its also very considerate of him to do so and he deserves a big thank you for doing that!
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 This version is anticipated as a compatibility and stability release rather than the usual large architectural changes the releases bring.
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.....
Filling out the changelog is part of being a reactos developer and if generating this at release time isnt convenient then steps to fix this need to be taken.
Personally, Ive never been a fan of using a commit log script. In my opinion such a thing will be too unreliable, produce unmeaningful commit log messages instead of meaningful change log messages and it takes the fun out of writing comical/banter oriented commit messages.
Back in the day .... we didnt 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.
Whats changed? Why has it become so difficult to do this in the recent years??
The lack of a complete changelog has held the release back for around a week now.
Its 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 wow factor 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.
Ged.
P.S. We are still missing changelog entries........
From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of victor martinez Sent: 15 December 2009 13:39 To: ros-dev@reactos.org Subject: [ros-dev] Improving our procedure
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/
Hi! Timo pointed out the use of TSVN to look at the "svn log" output. Wow, I did my change log in a snap! So TSVN is GPL right? I like the way it produced the logs, just set the dates then the name and you are off! Copy paste there you go~! Even had a column for the bug number too! So is there a way to set the SVN revision numbers between point 1 to point 2 and generate a report to be built into the change log format? I'm sure our webies can figure out something to help us out with this important requirement! 8^D
Thanks, James
Yeah, this is how I've always done it in the past. If you filter the results for author and date and select the items in the list view, you can do a copy/paste into a text file and all the data for each revision is pasted. Easy peasy :)
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of James Tabor Sent: 16 December 2009 10:07 To: ReactOS Development List Subject: Re: [ros-dev] Improving our procedure
Hi! Timo pointed out the use of TSVN to look at the "svn log" output. Wow, I did my change log in a snap! So TSVN is GPL right? I like the way it produced the logs, just set the dates then the name and you are off! Copy paste there you go~! Even had a column for the bug number too! So is there a way to set the SVN revision numbers between point 1 to point 2 and generate a report to be built into the change log format? I'm sure our webies can figure out something to help us out with this important requirement! 8^D
Thanks, James
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-
Daniel Reimer -
Ged Murphy -
Gregor Schneider -
James Tabor -
victor martinez