On Thursday 25 October 2012 at 17:59, Luke Kanies wrote: > On Oct 23, 2012, at 8:57 AM, Erik Dalén <[email protected] > (mailto:[email protected])> wrote: > > > > > > > On Thursday 18 October 2012 at 13:33, Luke Kanies wrote: > > > > > On Oct 18, 2012, at 6:58 AM, Ashley Penney <[email protected] > > > (mailto:[email protected])> wrote: > > > > > > > On Wed, Oct 17, 2012 at 10:14 PM, Miguel Di Ciurcio Filho > > > > <[email protected] (mailto:[email protected])> wrote: > > > > > > > > > b) Make Puppet a real community project, where the "Puppet Community > > > > > Project" (maybe a different name) is the upstream of Puppet Enterprise > > > > > or other PuppetLabs projects. Like Citrix did to Xen and CloudStack, > > > > > Red Hat does with many other projects KVM, Linux, oVirt, OpenStack is > > > > > the upstream for many companies, Samba, Apache HTTP server is part of > > > > > many proprietary solutions. The list could go on and on. > > > > > > > > > > > > > > > > > > > > > > > > I think this is probably the only way to stop things from collapsing > > > > under the weight of the community expectations at this point. I think > > > > opening up commit access to outside developers would be an enormously > > > > dangerous, but potentially extremely rewarding, way to go. I know > > > > that I've gotten discouraged from my attempts to fix things in facter > > > > from the difficulty of getting them merged in and reviewed for large > > > > scale changes. > > > > > > > > Obviously I think if this is the route things go then the addition of > > > > developers would have to be carefully controlled at the beginning in > > > > order to not have chaos and a blob of code that Puppetlabs themselves > > > > can no longer use productively, but it's clear that Puppetlabs simply > > > > cannot hire enough developers internally to improve things at the rate > > > > that the community wishes for. > > > > > > > > > > > > > > > > > > I agree with all of this. We've done a great job of building a > > > self-sustaining user community, but we clearly have not delivered that on > > > the development side. > > > > > > There are outside contributors with commit access, but not many, and > > > AFAIK they aren't able to spend much time on the project. > > > > > > I would *love* to have more work on Puppet coming from outside of our > > > organization. I've always wanted that, and it's always pained me that we > > > never really figured it out. > > > > > > How do we do this? It's not as simple as just giving a bunch of people > > > commit access, is it? > > I think trying to be extra speedy with reviewing and giving feedback on > > external pull requests would be a great start for this. It might be more > > time consuming and slow down development in the short run, but I think it > > would give more external contributions and speed up development in the long > > run. Basically regarding them as a VIP lane compared to internal ones or > > something. > > > > It turns out that it's fantastically difficult to be extra speedy on all > external pull requests. > > I agree with you that if we could do it, it would eventually result in more > contributors, and we're trying to get enough resources right now that we can > do so. Some of the pull requests are fundamentally hard, like those for > platforms like FreeBSD that we don't have good test infrastructure for or > skills in, and external pull requests tend to need a lot more modification > and mentoring (e.g., they often have little to no tests), so a given pull > request takes a lot longer to get in.
I fully understand that external pull requests might need more mentoring and stuff than internal ones, but that's just another argument to be speedy on them IMO. If they need 3-4 iterations it is really annoying if each of them takes more than a week. Might also introduce extra work due to merge conflicts etc. > > Beyond that, we also have business goals of our own, and that requires we > actually spend time on our own pull requests. We have someone dedicated each > week to external pull requests, and we're looking for more people to work on > it, but the needs of the community have clearly outstripped our staffing to > meet them (and probably did a long time ago). > > The awesome part of being a software company is that we can afford to hire > developers to work on software that our users want, but the sometimes less > than awesome part is that we have to make sure quite a bit of our effort is > aligned with being able to actually pay our developers. That is fully understandable, but getting lots of contributions and community development is probably also good for your business :) -- Erik Dalén -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
