-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've slightly rearranged the order of your text somewhat, for my own convenience in responding.
I apologize for taking so long to respond to your steady sets of patches and notices on this. And particularly, for promising to set up a hosted repository for you, and then failing to do so. :( William Pursell wrote: > I've been working on updating the configury for screen, and have > gotten to a state that could reasonably be merged. (Also, I don't > know that I'll have much time to look at this over the next few > months.) Primary benefits: > > Uses gnulib's getloadavg, so the configury for that function is > up-to-date and actively maintained. > > Uses config.guess to determine host and arch. Again, the primary > benefit being active maintenance of the checks. > > Everything can be specified at configure time. For example, > to set USRLIMIT, the user can either do it the old way > and edit config.h after running configure, or run configure > with the argument "usrlimit=20". I pick usrlimit as an > example because both my fork and the current master > do not compile with usrlimit set, so that leads to... ... > This fork provides no new functionality, but is a good > step towards bringing screen up to date. > > Micah, Juergen, et al., please let me know if there > is anything objectionable that causes you to refrain > from merging. Thank you very much for working on this. I think this will be extremely useful. We did something pretty much like this for Wget when I took on maintenance for that project. We split off a separate repo to do this, which was the mainline development branch; in the meantime, we kept on working on a separate repo which lacked automake/gnulib in anticipation of the 1.11 release. I guess it's probably high time we forked a branch for Wget, for post-4.1.x releases; this would be a great place to put your contributions. I would like to get some feedback from the other maintainers about the move to gnulib (I remember that jw approved the move to automake a while back). We did this as well for Wget. I think it was a good move, but I have some mixed feelings about it, too. I think mainly because gnulib modules tend to have a lot of dependencies on other modules, so you invevitably end up pulling in a large amount of extra code. Sometimes the gnulib modules don't offer quite the flexibility that you need, but you can't really modify it freely since it's just overwritten with the next update; you can of course submit patches upstream, but in the meantime you've got to copy it out to your own source tree and make your modifications there (and use a different name). OTOH, you lose the hassle of maintaining that code, and gain the advantage of a significantly larger test base, automatically receiving fixes for whatever bugs are inevitably found in the implementation of these core functions. As I said, I'm still glad we did it with Wget, but it is a mixed blessing, and I'd like to hear jw's input. > The git repository is at: > g...@github.com:wrp/wscreen.git in branch wrp. That failed to work for me (pub key auth failed). But git pull git://github.com/wrp/wscreen.git wrp worked. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. GNU Maintainer: wget, screen, teseq http://micah.cowan.name/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl+p/AACgkQ7M8hyUobTrGtWQCeJw/YQP/NWiAQKan3yW+BMtZw h3QAn1g9RHidrsBQo8Mz8hE+uTni5y/d =FUYE -----END PGP SIGNATURE----- _______________________________________________ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
