Re: RFC: Func's new direction

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Fedora Users]     [Linux Networking]     [Fedora Legacy List]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux