> > I don’t run kFreeBSD anywhere and I also don’t intend to change that in > the near- to medium-term future. Therefore, adding support for this > without someone who will take
care of the kFreeBSD problems would not be a good idea at all :). I definitely understand your concerns and agree completely with where you're coming from. I hadn't even thought about that, which was very short-sighted of me. I apologize; I'm still learning proper etiquette. :) ... a written statement about support in maintaining this from at least an > individual person I've given this a _lot_ of thought over the course of the day while mulling over whether I want to commit to this, including reaching out to a few folks to make sure I know where I can turn for help if I get myself into a bind I can't figure out (because I'll freely admit that I'm not a kFreeBSD expert). I realize you don't know me very well and that it would be preferable to have the kFreeBSD porters on this directly, but I can commit to being on the line for FTBFS and all the bug reports related to the kFreeBSD arches. What that means to me is that I will either figure out the solutions to issues that arise myself or I will reach out to the right lists/people for help so that we make sure kFreeBSD stays working longer-term. So what that means to me right this second is that I need a second testing machine for kfreebsd-i386, so I can verify that this works there too, and that I need to run more tests on both architectures. Does this sound like an acceptable path forward, at least for now? (Assuming "for now" on the idea that perhaps we can eventually get the package popular enough to garner the attention and added support of the kFreeBSD porters officially.) ♥, - Tianon
