Re: RFC: Func's new direction

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

 



On Fri, Aug 24, 2012 at 7:42 PM, Steve Salevan <steve@xxxxxxxxxx> 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!

I think its great seeing this, and I'm definitely excited to see some
life soming back to func.  Its a great project.  I wish I could offer
to help, but I'm rarely on a PC outside of work since we had our kid
and I'm a bout to start a new job where I have no idea if I'll even be
able to look at func much.

Along with the parallelism on delegation there are some issues that we
have in our environment related to multiple layers deep delegation
that I can talk to you about.  I narrowed down the general idea, but
could never figure out the fix.

One thing I that I've been bouncing around in my head for a while was
a "pretty print" method that modules could have that would allow their
data to be displayed a certain way, if the use wanted it to.  No
method? standard output.

I'm excited to see func move forward again, and i hope that at
somepoint i get the time and reason to come back to it :)
_______________________________________________
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