A note from Maintainer

Welcome to ltp community.

We are in process of changing our sf.net host repository to GIT from CVS.[ Any input/discussion on this is highly appreciable ]. If possible this month end release may get delayed based on responses from list or next month end (i.e: March ) release will be based on git tree.

I usually try to read all patches posted to ltp mailing list, and follow almost all discussions on list, unless the topic is about an obscure corner that i do not personally use. But i am obviously not perfect.If you sent a patch that you did not hear from anybody for three days, that is a very good indication that it was dropped on the floor --- please do not hesitate to remind me.

The list archive is available at:

http://marc.info/?l=ltp-list&r=1&w=2

Please use this public site to point out messages in mailing list if you want to remind someone or again start same thread without altering subject line.

Now coming to git transformation this month, you can find gitweb interface at :

http://ltp.git.sourceforge.net/git/gitweb.cgi?p=ltp/ltp-dev.git;a=summary

There are four branches in ltp-dev.git repository that track the source tree of ltp: "master", "maint", "next", "pu". I may add more maintanance branch if we have huge backward of incompatible feature updates in the future to keep an older release alive.

The master branch is meant to contain what are very well tested and ready to be used in production environment. There could occassionaly be minor breakage but they are not expected to be anything major, and more importantly those will be quickly and trivially fixable.

So if some hotfixes has gone with this branch, you can find one more digit has been added to version release (e.g: YYYYMMDD.1 ), So it means it is more stable than YYYYMMDD release. I may be changing this format if i can see a better format or if you have some suggestion then it is most welcome.

The "maint" branch is called one step before master branch, which will contain all features or patches that are going to following month end release.
(e.g: If this month end ltp-full-YYYYMMDD is going be to released then all the stable patches you can find in this branch through out the month, and one important point for this branch is all the patches which has gone to this branch will be well tested and make sure that there is no regression or breakage and Acked/Reviewed by Someone from mailing list.)

"next" branch will contain all the patches which has been sent on ltp-mailing list after getting "Acked-By" and/or "Reviewed-By" anyone from list. This branch is quite unstable but user can find their immediate patches over here to see the stability.You can find most unstable about this branch w.r.t feature wise or may be sometime build wise.

NOTE:
=====
So i always encourage testcase developer/ltp-list member to send me the patches against this branch. And it will be closely reviewed and acknowledged by any member from ltp-list community members. Once it gets Acked/Reveiwed-By then it will promoted to maint branch for maintainer testing and checking for stability, otherwise it will go to "pu" branch for further discussion and decision. These pending patch can be worked on following month and once it is mature enough to meet the stability then it can be directly jump to maint branch, here i may ask the submitter to submit the patch once again against maint branch.

"pu" branch is basically "proposed update" branch which will contain all the remainder of above branches. By the above definition of how "next" works, you can tell that this branch will contain quite experimental and obviosuly broken stuff.

I would like to thanks everybody who helped me to release ltp-dev git into current shape. Especially i would like to thank following:
   - git.git from where actually i picked up this branch identification.
   - Garret, who has worked with me step by step to release this git tree implementation to ltp-list@.
   - All my team member from IBM who basically gave encourageable input and specially Aneesh, Subrata, Iranna & kamalesh.
   - And finally to Linux kernel, who motivated me to maintain such a testsuits with git.

This Maintainer Note will be available under doc/MaintNotes of month end release.

Usage:

#git clone git://ltp.git.sourceforge.net/gitroot/ltp/ltp-dev.git ltp-dev (Make sure you have the latest autoconf/automake before running make autotools )
#make autotools
#./configure
#make
#make install
#cd /opt/ltp
#./runltp

Please do not hesitate to reply this mail if you have any query in your mind, it may help me to generate a good FAQ :) .

Quoted 105 lines · Rishikesh K Rajak

Welcome to ltp community.

We are in process of changing our sf.net host repository to GIT from CVS.[ Any input/discussion on this is highly appreciable ]. If possible this month end release may get delayed based on responses from list or next month end (i.e: March ) release will be based on git tree.

I usually try to read all patches posted to ltp mailing list, and follow almost all discussions on list, unless the topic is about an obscure corner that i do not personally use. But i am obviously not perfect.If you sent a patch that you did not hear from anybody for three days, that is a very good indication that it was dropped on the floor --- please do not hesitate to remind me.

The list archive is available at:

http://marc.info/?l=ltp-list&r=1&w=2

Please use this public site to point out messages in mailing list if you want to remind someone or again start same thread without altering subject line.

Now coming to git transformation this month, you can find gitweb interface at :

http://ltp.git.sourceforge.net/git/gitweb.cgi?p=ltp/ltp-dev.git;a=summary

There are four branches in ltp-dev.git repository that track the source tree of ltp: "master", "maint", "next", "pu". I may add more maintanance branch if we have huge backward of incompatible feature updates in the future to keep an older release alive.

The master branch is meant to contain what are very well tested and ready to be used in production environment. There could occassionaly be minor breakage but they are not expected to be anything major, and more importantly those will be quickly and trivially fixable.

So if some hotfixes has gone with this branch, you can find one more digit has been added to version release (e.g: YYYYMMDD.1 ), So it means it is more stable than YYYYMMDD release. I may be changing this format if i can see a better format or if you have some suggestion then it is most welcome.

The "maint" branch is called one step before master branch, which will contain all features or patches that are going to following month end release.
(e.g: If this month end ltp-full-YYYYMMDD is going be to released then all the stable patches you can find in this branch through out the month, and one important point for this branch is all the patches which has gone to this branch will be well tested and make sure that there is no regression or breakage and Acked/Reviewed by Someone from mailing list.)

"next" branch will contain all the patches which has been sent on ltp-mailing list after getting "Acked-By" and/or "Reviewed-By" anyone from list. This branch is quite unstable but user can find their immediate patches over here to see the stability.You can find most unstable about this branch w.r.t feature wise or may be sometime build wise.

NOTE:
=====
So i always encourage testcase developer/ltp-list member to send me the patches against this branch. And it will be closely reviewed and acknowledged by any member from ltp-list community members. Once it gets Acked/Reveiwed-By then it will promoted to maint branch for maintainer testing and checking for stability, otherwise it will go to "pu" branch for further discussion and decision. These pending patch can be worked on following month and once it is mature enough to meet the stability then it can be directly jump to maint branch, here i may ask the submitter to submit the patch once again against maint branch.

"pu" branch is basically "proposed update" branch which will contain all the remainder of above branches. By the above definition of how "next" works, you can tell that this branch will contain quite experimental and obviosuly broken stuff.

I would like to thanks everybody who helped me to release ltp-dev git into current shape. Especially i would like to thank following:
   - git.git from where actually i picked up this branch identification.
   - Garret, who has worked with me step by step to release this git tree implementation to ltp-list@.
   - All my team member from IBM who basically gave encourageable input and specially Aneesh, Subrata, Iranna & kamalesh.
   - And finally to Linux kernel, who motivated me to maintain such a testsuits with git.

This Maintainer Note will be available under doc/MaintNotes of month end release.

Usage:

#git clone git://ltp.git.sourceforge.net/gitroot/ltp/ltp-dev.git ltp-dev (Make sure you have the latest autoconf/automake before running make autotools )
#make autotools
#./configure
#make
#make install
#cd /opt/ltp
#./runltp

Quoted 2 lines

Please do not hesitate to reply this mail if you have any query in your mind, it may help me to generate a good FAQ :) .

Hello all,
I highly encourage folks to also use the testscripts/build scripts
as well [as I have in the past] before submitting patches back to us, so that you can test out the three identified build and test scenarios:

1. install-in-build-tree
2. install-out-of-build-tree
3. [build and install] out-of-build-tree

Please read the README before executing the scripts though (in the
same directory).
I request that folks run these scripts periodically (say once a
month, or bi-monthly) using different distros so that we can establish a gauge for how stable things are across the board, as opposed to having an unrealistic view of how Fedora 12~ish, Gentoo Linux, RHEL [, SuSe?, and Ubuntu?] are faring, especially because the project in and of itself is complex, as-is the amount of code and flux that occurs due to package versioning of the underlying software between releases (a new API gets added, and there's a certain degree of lag between when the system headers get updated and the glibc headers get updated to accommodate the new API, etc, etc).
Much appreciated as always, and I have a good feeling that the
project is starting to reach a good equilibrium state again, like it was pre-October '09 when I committed the Makefile infrastructure changes.

Happy testing as always :),
-Garrett

Welcome to ltp community.

We are in process of changing our sf.net host repository to GIT from CVS.[ Any input/discussion on this is highly appreciable ]. If possible this month end release may get delayed based on responses from list or next month end (i.e: March ) release will be based on git tree.

I usually try to read all patches posted to ltp mailing list, and follow almost all discussions on list, unless the topic is about an obscure corner that i do not personally use. But i am obviously not perfect.If you sent a patch that you did not hear from anybody for three days, that is a very good indication that it was dropped on the floor --- please do not hesitate to remind me.

The list archive is available at:

http://marc.info/?l=ltp-list&r=1&w=2

Please use this public site to point out messages in mailing list if you want to remind someone or again start same thread without altering subject line.

Now coming to git transformation this month, you can find gitweb interface at :

http://ltp.git.sourceforge.net/git/gitweb.cgi?p=ltp/ltp-dev.git;a=summary

There are four branches in ltp-dev.git repository that track the source tree of ltp: "master", "maint", "next", "pu". I may add more maintanance branch if we have huge backward of incompatible feature updates in the future to keep an older release alive.

The master branch is meant to contain what are very well tested and ready to be used in production environment. There could occassionaly be minor breakage but they are not expected to be anything major, and more importantly those will be quickly and trivially fixable.

So if some hotfixes has gone with this branch, you can find one more digit has been added to version release (e.g: YYYYMMDD.1 ), So it means it is more stable than YYYYMMDD release. I may be changing this format if i can see a better format or if you have some suggestion then it is most welcome.

The "maint" branch is called one step before master branch, which will contain all features or patches that are going to following month end release.
(e.g: If this month end ltp-full-YYYYMMDD is going be to released then all the stable patches you can find in this branch through out the month, and one important point for this branch is all the patches which has gone to this branch will be well tested and make sure that there is no regression or breakage and Acked/Reviewed by Someone from mailing list.)

"next" branch will contain all the patches which has been sent on ltp-mailing list after getting "Acked-By" and/or "Reviewed-By" anyone from list. This branch is quite unstable but user can find their immediate patches over here to see the stability.You can find most unstable about this branch w.r.t feature wise or may be sometime build wise.

NOTE:
=====
So i always encourage testcase developer/ltp-list member to send me the patches against this branch. And it will be closely reviewed and acknowledged by any member from ltp-list community members. Once it gets Acked/Reveiwed-By then it will promoted to maint branch for maintainer testing and checking for stability, otherwise it will go to "pu" branch for further discussion and decision. These pending patch can be worked on following month and once it is mature enough to meet the stability then it can be directly jump to maint branch, here i may ask the submitter to submit the patch once again against maint branch.

"pu" branch is basically "proposed update" branch which will contain all the remainder of above branches. By the above definition of how "next" works, you can tell that this branch will contain quite experimental and obviosuly broken stuff.

I would like to thanks everybody who helped me to release ltp-dev git into current shape. Especially i would like to thank following:
- git.git from where actually i picked up this branch identification.
- Garret, who has worked with me step by step to release this git tree implementation to ltp-list@.
- All my team member from IBM who basically gave encourageable input and specially Aneesh, Subrata, Iranna & kamalesh.
- And finally to Linux kernel, who motivated me to maintain such a testsuits with git.

This Maintainer Note will be available under doc/MaintNotes of month end release.

Usage:

#git clone git://ltp.git.sourceforge.net/gitroot/ltp/ltp-dev.git ltp-dev (Make sure you have the latest autoconf/automake before running make autotools )
#make autotools
#./configure
#make
#make install
#cd /opt/ltp
#./runltp

Please do not hesitate to reply this mail if you have any query in your mind, it may help me to generate a good FAQ :) .

Happy Testing!!!

Quoted 105 lines · Rishikesh K Rajak

Welcome to ltp community.

We are in process of changing our sf.net host repository to GIT from CVS.[ Any input/discussion on this is highly appreciable ]. If possible this month end release may get delayed based on responses from list or next month end (i.e: March ) release will be based on git tree.

I usually try to read all patches posted to ltp mailing list, and follow almost all discussions on list, unless the topic is about an obscure corner that i do not personally use. But i am obviously not perfect.If you sent a patch that you did not hear from anybody for three days, that is a very good indication that it was dropped on the floor --- please do not hesitate to remind me.

The list archive is available at:

http://marc.info/?l=ltp-list&r=1&w=2

Please use this public site to point out messages in mailing list if you want to remind someone or again start same thread without altering subject line.

Now coming to git transformation this month, you can find gitweb interface at :

http://ltp.git.sourceforge.net/git/gitweb.cgi?p=ltp/ltp-dev.git;a=summary

There are four branches in ltp-dev.git repository that track the source tree of ltp: "master", "maint", "next", "pu". I may add more maintanance branch if we have huge backward of incompatible feature updates in the future to keep an older release alive.

The master branch is meant to contain what are very well tested and ready to be used in production environment. There could occassionaly be minor breakage but they are not expected to be anything major, and more importantly those will be quickly and trivially fixable.

So if some hotfixes has gone with this branch, you can find one more digit has been added to version release (e.g: YYYYMMDD.1 ), So it means it is more stable than YYYYMMDD release. I may be changing this format if i can see a better format or if you have some suggestion then it is most welcome.

The "maint" branch is called one step before master branch, which will contain all features or patches that are going to following month end release.
(e.g: If this month end ltp-full-YYYYMMDD is going be to released then all the stable patches you can find in this branch through out the month, and one important point for this branch is all the patches which has gone to this branch will be well tested and make sure that there is no regression or breakage and Acked/Reviewed by Someone from mailing list.)

"next" branch will contain all the patches which has been sent on ltp-mailing list after getting "Acked-By" and/or "Reviewed-By" anyone from list. This branch is quite unstable but user can find their immediate patches over here to see the stability.You can find most unstable about this branch w.r.t feature wise or may be sometime build wise.

NOTE:
=====
So i always encourage testcase developer/ltp-list member to send me the patches against this branch. And it will be closely reviewed and acknowledged by any member from ltp-list community members. Once it gets Acked/Reveiwed-By then it will promoted to maint branch for maintainer testing and checking for stability, otherwise it will go to "pu" branch for further discussion and decision. These pending patch can be worked on following month and once it is mature enough to meet the stability then it can be directly jump to maint branch, here i may ask the submitter to submit the patch once again against maint branch.

"pu" branch is basically "proposed update" branch which will contain all the remainder of above branches. By the above definition of how "next" works, you can tell that this branch will contain quite experimental and obviosuly broken stuff.

I would like to thanks everybody who helped me to release ltp-dev git into current shape. Especially i would like to thank following:
- git.git from where actually i picked up this branch identification.
- Garret, who has worked with me step by step to release this git tree implementation to ltp-list@.
- All my team member from IBM who basically gave encourageable input and specially Aneesh, Subrata, Iranna & kamalesh.
- And finally to Linux kernel, who motivated me to maintain such a testsuits with git.

This Maintainer Note will be available under doc/MaintNotes of month end release.

Usage:

#git clone git://ltp.git.sourceforge.net/gitroot/ltp/ltp-dev.git ltp-dev (Make sure you have the latest autoconf/automake before running make autotools )
#make autotools
#./configure
#make
#make install
#cd /opt/ltp
#./runltp

Quoted 4 lines

Please do not hesitate to reply this mail if you have any query in your mind, it may help me to generate a good FAQ :) .

Happy Testing!!!

Nice. I briefly looked at git via gitweb and will be good to add some more tags. I prefer to add different tag than you used. For example for this comming will be good to use tag "LTP-20100228"

http://ltp.git.sourceforge.net/git/gitweb.cgi?p=ltp/ltp-dev.git;a=commitdiff;h=c288167e111d34d5146dbbe5ebb19c84153ee67b

And also will be good to call that commit in better way - not "Fixed the typo in changelog".

There are several funny commits too ( for example:
2279bf46ad12b3e75c512e9f146bc60a49220444, dfac29ccbb03db3e4ee3fa5674cbbbf0104b08aa and others).

I hope that there will be the correct description in commit message. For example this commit message should be better.
http://ltp.git.sourceforge.net/git/gitweb.cgi?p=ltp/ltp-dev.git;a=commitdiff;h=c0e37ca6731cada152573522d48d08513029e44a

Anyway. I like that ltp was moved to git.

We are in process of changing our sf.net host repository to GIT from CVS.[ Any input/discussion on this is highly appreciable ].

Quoted 2 lines · On Saturday 27 February 2010 02:53:48 Rishikesh K Rajak wrote:

We are in process of changing our sf.net host repository to GIT from CVS.[ Any input/discussion on this is highly appreciable ].

the authorship info really should be fixed before anything is finalized. and a git hook added to reject people pushing patches that lack proper author/committer fields. these commits by "root" are a good example of things that should not be happening.

-mike

------------------------------------------------------------------------

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

------------------------------------------------------------------------

_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Quoted 8 lines · Mike Frysinger

Quoted 2 lines · On Saturday 27 February 2010 02:53:48 Rishikesh K Rajak wrote:

We are in process of changing our sf.net host repository to GIT from CVS.[ Any input/discussion on this is highly appreciable ].

the authorship info really should be fixed before anything is finalized. and a git hook added to reject people pushing patches that lack proper author/committer fields. these commits by "root" are a good example of things that should not be happening.

Agree. Do you know about any manual how to fix it by any script or setup that conversion? I mean to have any convert table where for example will be written conversion:
vampier -> Mike Frysinger.
root -> Subrata Modak

Quoted 8 lines · Mike Frysinger

Quoted 2 lines · On Saturday 27 February 2010 02:53:48 Rishikesh K Rajak wrote:

We are in process of changing our sf.net host repository to GIT from CVS.[ Any input/discussion on this is highly appreciable ].

the authorship info really should be fixed before anything is finalized.  and a git hook added to reject people pushing patches that lack proper author/committer fields.  these commits by "root" are a good example of things that should not be happening.

Agree. Do you know about any manual how to fix it by any script or setup that conversion? I mean to have any convert table where for example will be written conversion:
vapier -> Mike Frysinger.
root -> Subrata Modak

Welcome to ltp community.

There are four branches in ltp-dev.git repository that track the source tree of ltp: "master", "maint", "next", "pu". I may add more maintanance branch if we have huge backward of incompatible feature updates in the future to keep an older release alive.

The master branch is meant to contain what are very well tested and ready to be used in production environment. There could occassionaly be minor breakage but they are not expected to be anything major, and more importantly those will be quickly and trivially fixable.

So if some hotfixes has gone with this branch, you can find one more digit has been added to version release (e.g: YYYYMMDD.1 ), So it means it is more stable than YYYYMMDD release. I may be changing this format if i can see a better format or if you have some suggestion then it is most welcome.

The "maint" branch is called one step before master branch, which will contain all features or patches that are going to following month end release.
(e.g: If this month end ltp-full-YYYYMMDD is going be to released then all the stable patches you can find in this branch through out the month, and one important point for this branch is all the patches which has gone to this branch will be well tested and make sure that there is no regression or breakage and Acked/Reviewed by Someone from mailing list.)

"next" branch will contain all the patches which has been sent on ltp-mailing list after getting "Acked-By" and/or "Reviewed-By" anyone from list. This branch is quite unstable but user can find their immediate patches over here to see the stability.You can find most unstable about this branch w.r.t feature wise or may be sometime build wise.

NOTE:
=====
So i always encourage testcase developer/ltp-list member to send me the patches against this branch. And it will be closely reviewed and acknowledged by any member from ltp-list community members. Once it gets Acked/Reveiwed-By then it will promoted to maint branch for maintainer testing and checking for stability, otherwise it will go to "pu" branch for further discussion and decision. These pending patch can be worked on following month and once it is mature enough to meet the stability then it can be directly jump to maint branch, here i may ask the submitter to submit the patch once again against maint branch.

"pu" branch is basically "proposed update" branch which will contain all the remainder of above branches. By the above definition of how "next" works, you can tell that this branch will contain quite experimental and obviosuly broken stuff.

If git-config isn't setup properly it will complain about usernames, email, etc; is it possible for a hook to be added, s.t. this becomes a hard requirement and any proposed commits will be rejected?

Quoted 8 lines · On Saturday 06 March 2010 05:25:10 Michal Simek wrote:

Quoted 7 lines · Mike Frysinger

Quoted 2 lines · On Saturday 27 February 2010 02:53:48 Rishikesh K Rajak wrote:

We are in process of changing our sf.net host repository to GIT from CVS.[ Any input/discussion on this is highly appreciable ].

the authorship info really should be fixed before anything is finalized. and a git hook added to reject people pushing patches that lack proper author/committer fields. these commits by "root" are a good example of things that should not be happening.

Quoted 5 lines

Agree. Do you know about any manual how to fix it by any script or setup that conversion? I mean to have any convert table where for example will be written conversion:
vampier -> Mike Frysinger.
root -> Subrata Modak

i use this script:
#!/bin/bash

tmp=$(mktemp)
cat << \EOF > ${tmp}

decode() {
	awk -vid="$1" -vtype="$2" '$1 == id {
		print "export GIT_"type"_NAME='\''" $3 " " $4 "'\'';"
		print "export GIT_"type"_EMAIL='\''" $5 "'\'';"
	}' ${author_file}
}

EOF

for x in cvs-authors authors ; do

	export author_file=${PWD}/.git/$x
	[ -e ${author_file} ] && break
done
git filter-branch \
	--env-filter ". ${tmp};"' \
		eval `decode "${GIT_AUTHOR_NAME}" AUTHOR`; \
		eval `decode "${GIT_COMMITTER_NAME}" COMMITTER`; \

' "$@"

rm -f $tmp

use a normal authors file in like .git/authors and run it. the authors format looks something like:
vapier = Mike Frysinger <[email protected]>

...
-mike

Anyway don't you have another script which will check commit message and if is there Signed-off-by line then change author name?
There are a lot of commits with that line and will be good to fix this too. Adding some new lines to commit messages (At least before Sign-off-by line) make sense too.

Quoted 8 lines · On Saturday 06 March 2010 05:25:10 Michal Simek wrote:

Quoted 7 lines · Mike Frysinger

Quoted 2 lines · On Saturday 27 February 2010 02:53:48 Rishikesh K Rajak wrote:

We are in process of changing our sf.net host repository to GIT from CVS.[ Any input/discussion on this is highly appreciable ].

the authorship info really should be fixed before anything is finalized. and a git hook added to reject people pushing patches that lack proper author/committer fields. these commits by "root" are a good example of things that should not be happening.

Quoted 5 lines

Agree. Do you know about any manual how to fix it by any script or setup that conversion? I mean to have any convert table where for example will be written conversion:
vampier -> Mike Frysinger.
root -> Subrata Modak

i use this script:
#!/bin/bash

tmp=$(mktemp)
cat << \EOF > ${tmp}

decode() {
	awk -vid="$1" -vtype="$2" '$1 == id {
		print "export GIT_"type"_NAME='\''" $3 " " $4 "'\'';"
		print "export GIT_"type"_EMAIL='\''" $5 "'\'';"
	}' ${author_file}
}

EOF

for x in cvs-authors authors ; do

	export author_file=${PWD}/.git/$x
	[ -e ${author_file} ] && break
done
git filter-branch \
	--env-filter ". ${tmp};"' \
		eval `decode "${GIT_AUTHOR_NAME}" AUTHOR`; \
		eval `decode "${GIT_COMMITTER_NAME}" COMMITTER`; \

' "$@"

rm -f $tmp

use a normal authors file in like .git/authors and run it. the authors format looks something like:
vapier = Mike Frysinger <[email protected]>

...
-mike

Quoted 5 lines · On Sunday 07 March 2010 13:09:00 Michal Simek wrote:

Anyway don't you have another script which will check commit message and if is there Signed-off-by line then change author name?
There are a lot of commits with that line and will be good to fix this too. Adding some new lines to commit messages (At least before Sign-off-by line) make sense too.

i dont have any such script, and i'm not sure it's a good idea ...