Am 05.09.2012 um 00:11 schrieb Sebastian Kuzminsky: > On Sep 4, 2012, at 15:46 , Kent A. Reed wrote: > >> On 9/4/2012 5:02 PM, Sebastian Kuzminsky wrote: >>> On Sep 4, 2012, at 13:12 , Michael Haberler wrote: >>> >>>> I've committed the simulator (user-mode) parport driver to master: >>>> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commit;h=31acddb62d957f1059046caa5e7236c2b5eef613 >>>> >>>> it's separate for now from the real hal_parport files until it has shaken >>>> out a bit. See src/hal/simdrivers/README.uparport for the fineprint. >>>> >>>> I'd be interested to hear about experiences >>> >>> It broke many of the buildbot builds: >>> >>> http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/502 >>> >> >> Presumably because it introduces a new dependency on an external project >> https://libcpuid.svn.sourceforge.net >> >> I'm not sure what the right answer is here. Putting this experimental >> driver into master makes it easily accessible to folks like me who >> forget Michael's git hub but at the same time it's what the Saturday >> Night show would call Not Ready For Prime Time. > > I generally dislike forking external projects and including a copy of them > within LinuxCNC. It adds the developer burden of merging from the external > project, and bloats our repo and our packages.
For integrating redis and redis-py: I have declared what the situation is, I have laid out why there is no realistic alternative beforehand, I have said that it is a temporary measure until the packages become available, I have warned that this is coming and I heard no opposition. Therefore, wrt to those packages I dont think your ex-post criticism is fair. The libcpuid was a genuine blunder, since all thats needed is a tiny function to get the cpu clock I think I can excerpt that and add it to remove the dependency. Or I'll make a test in configure for the library, which is another can of worms with likely build fallout. There was interest expressed in the sim-parport thing and to get maximum reach for folks interested I pushed it early, and I have learned that the set of folks interested in a feature is pretty much disjoint from the set of git digerati. > I'd prefer to use external packages that are available as debian packages for > our supported distros (LTSes Hardy, Lucid, and Precise), or (if that's not > possible) packaging the external project as a deb and making it available in > our debian archives (like Jeff did with asciidoc to make it available on > Hardy). I have checked and I found dev package for libcpuid, which is the standard case for relying on anything developed in the last few years. As for preparing packages for separate download as a replacement, I have heard several times serious dislike expressed for that because of maintenance implications. Rules instead of dislike mumblings to deal with it: none that I know of. Result: we're getting into philosophical discussions repeatedly. > It just makes for more modular, debuggable, sharable software over all. Yeah, sure, that is all fine and great in theory, and nobody disagrees with the 'external packages are great' line of thinking. I'm not getting a kick out of integrating the redis base code, and I hope you agree that the archaic build environments forced by a I-dont-know-how-to-qualify-this-without-expletives kernel dependency *without an alternative* are part of the problem - we cant even build a working rt distro for Ubuntu Precise to the day, right? That wasnt me, Seb. -- That said, the buildbot is extremely useful, and I appreciate your work very much. Can I encourage you to make it less of a chore for yourself and less blunder-prone for contributors by: - documenting how a test branch can be run through the buildbot without causing the ritual "contributor X's commit has broken the builds" emails - obviously pushing a branch to the git.linuxcnc.org triggers a build, which I discovered by accident - how can one make use of it properly to reduce my red-face factor? - it would be extra helpful to document the steps how your build environments are set up and run, that would enable us to try this at home before pushing a commit. -Michael > > > -- > Sebastian Kuzminsky > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
