On 08/24/2012 04:42 PM, Steve Salevan wrote: > Hey guys, > I apologize for being a bit out of the loop over the past few weeks, but > I wanted to drop in with a bang with my first func-related RFC. I've > spent a fair bit of time recently thinking about where next to take > Func, as development has stalled, but it has a wide array of users, > almost all of whom have experience in hacking it into submission. > > If there's anything that I've learned about systems management software > in my experience, hacking like this is in its very nature, and the more > of it that happens in the upstream community, the more capable the tool > ends up becoming. As the project's new maintainer, my first goal is to > get these sorts of commits going again, to start a flow of project > improvements that fundamentally round out in a better tool for all of > us. Towards this end, it occurs to me that it's pretty damn hard to > contribute to Func, as e-mail patch submission is a bit awkward and not > very conducive to the sorts of technical discussions we should be having > when new code is presented. > > Thus, for my first move, I'm thinking about moving Func to github, as > that pull request feature of theirs makes upstream interaction a fair > bit simpler and allows us to conduct code reviews, which will help us > keep the code tight going out. My second thought is that it's about > time we brought you guys into the fold as committers if you've spent > serious time improving Func, so if you've submitted several substantial > patches/pull requests, you will gain commit access. > > Finally, to get project development going, I've found that setting a > roadmap with goals helps drive development, so here's a rough draft of > what I'm thinking about feature-wise for Func 0.30, alongside their > respective priorities (0==highest): > > 0 - Improve client-side daemon stability > 0 - Prevent forks from listening on :51234 > 1 - Improve forking system, prevent zombie fork processes > 1 - Make certmaster daemon more stable, and fix bug which causes it to > issue malformed certs > 2 - Improve delegation parallelism > > If you have any ideas for the roadmap, and/or would be interested in > taking ownership in something, let me know, as open discussions like > this will drive Func going forward, and I can promise beer and committer > status :) > > Thanks much for the read, let me know what you think about all this, and > have a great weekend! > -- > Steve Salevan > steve@xxxxxxxxxx <mailto:steve@xxxxxxxxxx> > > > > _______________________________________________ > func mailing list > func@xxxxxxxxxxxxxxxxxxxxxx > https://lists.fedorahosted.org/mailman/listinfo/func > I think it is great, stability of the client side daemon is one of my largest issues. I am really pleased to see some forward momentum on this project, it is an extremely handy tool. I believe moving it to github will make it exceptionally easy to merge in new code. For my personal needs I would like to see ipv6 support. I have been looking into this and it looks like all that is really needed is the pass the inet6 family to the simplexmlrpc server, at least from the client side. I have to look at it more closely, and I would like to understand how other daemons like ssh handle this, but with some work I may have some patches for you to help support this. I would also like to see a monitoring component built in, perhaps a nagios script to check the client status. -Erinn
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ func mailing list func@xxxxxxxxxxxxxxxxxxxxxx https://lists.fedorahosted.org/mailman/listinfo/func
