Subject: Re: [RFC] automated make check - msg#00077

Previous Message by Date: click to view message preview

Re: [RFC] automated make check

due to the proposal to run make check in gmp (which as it I find rather uninteresting, glibc and gcc are way more important as base for me) glibc and gcc are tested intensivly during the whole building process, gmp is frequently misscompiled and not even the runtime execution can tell you if it's working properly. Nope, only a small subset is actually run - also when some stuff e.g. segfaults randomly, usually some hours of buliding crap objects already passed by ... ok, but just for curiosity how long the glibc and gcc checks take? the topic about make check got a bit hotter than it was at the times years ago when I introduced the possibility to run make check automatically, globally. uhm... interesting authorship statement. but ok, you polish it and commit. Excuse me, what do you want to say here? uhm? with that i just say that i find interesting that you take full authorship for a feature which are the result of an RFC sent (by me) on september of 2003 to the ROCKLinux community which was discussed there, polished and finally commited by one of the two persons with write access. A 'we' instead of an 'i' or a 'me' is usually more correct and respectful for the people which make rock and/or t2 what they are now. that's what i was saying there. Since the abbility to control make check on a per package choice is sort of requested I propose to extend the make check functionality by a simillar mechanism as done for dietlibc where it is possible to selec which package to build against dietlibc on a per-package basis as well. For that a new Flag (CHECK) would be useful to only display those packages that have a known good make check (currently the code greps for a check target in the makefile and runs that if told to). And of course the current code needs a atstage native conditional (an indication how many people wanted to use that so far,-) something like this ? if atstage native; then if hasflag CHECK || [ "$SDECFG_DO_CHECK" == "1" ]; then hook_add inmake 6 'run_check' fi fi sound very good to me, +1 :-) Nope, hasflag CHECK _&&_ ... also you missed the part where the per-package config is looked up, like: .. "$SDECFG_CHECK_$xpkg " = "1" i think the dietlibc 'model' it's an overkill in this case. you want to run_check for a list of packages selected at Config time if $SDECFG_DO_CHECK is enabled. and i proposed to run_check always (atstage native) for certain known-to-misscompile packages and using $SDECFG_DO_CHECK to make the massive tests. what about taking the join of both and making $SDECFG_DO_CHECK a three options variable. 0: no make check 1: make check only for fragile packages 2: make check massivly and avoiding another 2000+ SDECFG_ variables or hardcoding a CHECK flag for every package supporting that target. regards, Alejandro Mery

Next Message by Date: click to view message preview

trunk is trunk but must not be messed up

Hi all, since our goal is to introduce T2 to an wider audience and expand the user-base to more than the handful of people we could attract at ROCK times it is highly important that we do not screw up the trunk every now and then. Especially since this, aside annoying developers, leads to overly long stabilization perions before the major releases - and those we want to have regularly at least twice a year. Now when one looks at more viable, competting projects such as the BSDs you will notice that they do not have such kind of problems, mostly because their developers to not commit experimental, untested or "just for the fun rewrites" into their CVS world. This results not only in satisfied users even of the next generation branch but also in short release cycles. Simillarly the other worst case scenary was ROCK Linux where the trunk (or rsync snapshots in the dark times) where far from reliable and thus scared a whole lof ot people away. And ROCK scared a lot of them - even hard core, long contributing developers! So what does this mean for us, since T2 is not about corrupting trunk once a week or stagnating at the same 50++ people using it (number out of the air - no exact no. actually) we should ask ourself, is it necessary that we change the way the packager works once a year or do incompatible changes in Config, the build scripts, ... just because someone wants or someon thinks it is cleaner when one year later it has to be changed against for a new feature and the new code did proof not to be that clean? Instead, especially for the next time, we should rather focus on reliability, stability and the user, developer visible changes. Not only are graphical installers and configuration long standard (even along Linux distributions or BSDs) but also some not regularly used featured such as RAID or encrypted root file-systems or some init scripts could definetly need some work. I think everyone has his own TODO for such kind of points. E.g. stuff that only is halfly integrated: - jails (though I use this feature from time to time - so it is not completely rotten) - selinux - rsbac - xen - some init scripts are rather basic - some alternative init systems - ... yours personal favourites here T2/trunk is really useful right now, I highly recomment to continue to focus on cleaning and stabelizing although it is named "trunk" instead of rewrites, reworks and refactoring that _will_ break collateral things. Thanks in advance and hopeing for a more stable and feature rich future development - yours, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://exactcode.de | http://t2-project.org | http://rebe.name +49 (0)30 / 255 897 45 ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to lists@xxxxxxxxxxxxxx with a subject of: unsubscribe t2

Previous Message by Thread: click to view message preview

Re: [RFC] automated make check

due to the proposal to run make check in gmp (which as it I find rather uninteresting, glibc and gcc are way more important as base for me) glibc and gcc are tested intensivly during the whole building process, gmp is frequently misscompiled and not even the runtime execution can tell you if it's working properly. Nope, only a small subset is actually run - also when some stuff e.g. segfaults randomly, usually some hours of buliding crap objects already passed by ... ok, but just for curiosity how long the glibc and gcc checks take? the topic about make check got a bit hotter than it was at the times years ago when I introduced the possibility to run make check automatically, globally. uhm... interesting authorship statement. but ok, you polish it and commit. Excuse me, what do you want to say here? uhm? with that i just say that i find interesting that you take full authorship for a feature which are the result of an RFC sent (by me) on september of 2003 to the ROCKLinux community which was discussed there, polished and finally commited by one of the two persons with write access. A 'we' instead of an 'i' or a 'me' is usually more correct and respectful for the people which make rock and/or t2 what they are now. that's what i was saying there. Since the abbility to control make check on a per package choice is sort of requested I propose to extend the make check functionality by a simillar mechanism as done for dietlibc where it is possible to selec which package to build against dietlibc on a per-package basis as well. For that a new Flag (CHECK) would be useful to only display those packages that have a known good make check (currently the code greps for a check target in the makefile and runs that if told to). And of course the current code needs a atstage native conditional (an indication how many people wanted to use that so far,-) something like this ? if atstage native; then if hasflag CHECK || [ "$SDECFG_DO_CHECK" == "1" ]; then hook_add inmake 6 'run_check' fi fi sound very good to me, +1 :-) Nope, hasflag CHECK _&&_ ... also you missed the part where the per-package config is looked up, like: .. "$SDECFG_CHECK_$xpkg " = "1" i think the dietlibc 'model' it's an overkill in this case. you want to run_check for a list of packages selected at Config time if $SDECFG_DO_CHECK is enabled. and i proposed to run_check always (atstage native) for certain known-to-misscompile packages and using $SDECFG_DO_CHECK to make the massive tests. what about taking the join of both and making $SDECFG_DO_CHECK a three options variable. 0: no make check 1: make check only for fragile packages 2: make check massivly and avoiding another 2000+ SDECFG_ variables or hardcoding a CHECK flag for every package supporting that target. regards, Alejandro Mery

Next Message by Thread: click to view message preview

trunk is trunk but must not be messed up

Hi all, since our goal is to introduce T2 to an wider audience and expand the user-base to more than the handful of people we could attract at ROCK times it is highly important that we do not screw up the trunk every now and then. Especially since this, aside annoying developers, leads to overly long stabilization perions before the major releases - and those we want to have regularly at least twice a year. Now when one looks at more viable, competting projects such as the BSDs you will notice that they do not have such kind of problems, mostly because their developers to not commit experimental, untested or "just for the fun rewrites" into their CVS world. This results not only in satisfied users even of the next generation branch but also in short release cycles. Simillarly the other worst case scenary was ROCK Linux where the trunk (or rsync snapshots in the dark times) where far from reliable and thus scared a whole lof ot people away. And ROCK scared a lot of them - even hard core, long contributing developers! So what does this mean for us, since T2 is not about corrupting trunk once a week or stagnating at the same 50++ people using it (number out of the air - no exact no. actually) we should ask ourself, is it necessary that we change the way the packager works once a year or do incompatible changes in Config, the build scripts, ... just because someone wants or someon thinks it is cleaner when one year later it has to be changed against for a new feature and the new code did proof not to be that clean? Instead, especially for the next time, we should rather focus on reliability, stability and the user, developer visible changes. Not only are graphical installers and configuration long standard (even along Linux distributions or BSDs) but also some not regularly used featured such as RAID or encrypted root file-systems or some init scripts could definetly need some work. I think everyone has his own TODO for such kind of points. E.g. stuff that only is halfly integrated: - jails (though I use this feature from time to time - so it is not completely rotten) - selinux - rsbac - xen - some init scripts are rather basic - some alternative init systems - ... yours personal favourites here T2/trunk is really useful right now, I highly recomment to continue to focus on cleaning and stabelizing although it is named "trunk" instead of rewrites, reworks and refactoring that _will_ break collateral things. Thanks in advance and hopeing for a more stable and feature rich future development - yours, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://exactcode.de | http://t2-project.org | http://rebe.name +49 (0)30 / 255 897 45 ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to lists@xxxxxxxxxxxxxx with a subject of: unsubscribe t2