Am 25.06.2015 um 19:41 schrieb Trevor Hess thess@10thmagnitude.com:
What about an upvote/downvote system? It can be abused too, but what if a downvote required a linked issue on the repository?
Then badges could be related to the way a maintainer responds to issues?
The problem is time and changes.
Cookbooks that were great in 2011 wont necessarily be usable today.
Cookbooks that look great today may explode or just abandoned some time in the future.
You would need a reddit/HN-like system to expire ratings.
But still this implies ultimate trust in the voters to “know” if a cookbook is good or not.
If people don’t know it or don’t want to (re-)vote it’s IMHO useless.
It’s like real world democracy: Proper education + “auto-expiration” of trust.
Roland
–
TFrom: David Joos [mailto:david.joos@gmail.com]
Sent: Thursday, June 25, 2015 12:32 PM
To: chef@lists.opscode.com
Subject: [chef] Re: Re: Re: Re: Community cookbook maintenance (was: Re: Reprepro cookbook)this’d probably be easier to implement, but it’s also very subjective.
ratings systems are great for popularity, but they often miss the mark
for quality.Yeah, I think that is also the reason why when the transition was made from the old “Chef community cookbooks”-catalog to the current “Chef Supermarket”, the option to rate cookbooks was ditched.
+1 for the idea of badges though
2015-06-25 18:25 GMT+01:00 Nathan Williams nath.e.will@gmail.com:
On Thu, 2015-06-25 at 09:11 -0700, Yoshi Spendiff wrote:An official certification is probably too much to handle but there
could be value in stating guidelines that demonstrate how a reliable
cookbook is designed and tested. I know Chef doesn’t like to
prescribe but for the sake of quality a recommended path for some
things might be a good idea.that seems to be changing, though; between the tooling packaged with
chefdk, and the bundled generators, they’re effectively prescribing
(which is great, please keep it going!) if not overtly doing so.The reason to maintain a community cookbook is usually because it’s
relevant to your business/job, which is obviously why cookbooks fall
out of repair and only have certain coverage.If business 1 makes a cookbook for platform X only and business 2
wants to do the same for platform Y then their options are:
- Make a new cookbook for platform X
- Fork
- Work on a pull request
Having good methods for business 2 to contact business 1 and state
their intention could lead to productive collaboration and
implementing better ways to find contributors and reviewers of
cookbooks could be a good way to help out with this, whether it’s
business to business or just individual contributors.It would also be useful for there to be a mechanism where ownership
of stale cookbooks can be transferred, especially now there are
groups that are willing to maintain them.have you seen the “adopt me” stuff on supermarket? i think that
addresses this situation pretty well.Finally, better sorting and maybe a rating system on the supermarket
for cookbooks would be good. If a cookbook starts out excellent but
isn’t maintained then many lower reviews will start to drag down the
rating.this’d probably be easier to implement, but it’s also very subjective.
ratings systems are great for popularity, but they often miss the mark
for quality.On Thu, Jun 25, 2015 at 3:57 AM, Roland Moriz rmoriz@gmail.com
wrote:Am 24.06.2015 um 17:33 schrieb Nathan Williams <
nath.e.will@gmail.com>:
i’d really like to see some official (maybe a BCP Chef RFC?)
guidelines for quality based around the BCP guidelines… For
example: evaluated with foodcritic and rubocop, integration tested
with test-kitchen suites that cover the majority of recipe code
-paths (e.g. source vs package install, etc.), unit tested with
chefspec, and support for the relevant Chef-supported platforms (ht
tps://github.com/chef/chef-rfc/blob/master/rfc021-platform-support
-policy.md).if we then had some application process for Chef Inc to certify a
cookbook as complying with the BCP, and we surfaced BCP-compliant
cookbooks through Supermarket (with periodic
review/recertification), I think we’d be most of the way to
victory. This kind of surfacing would help deal with the naming
conflict and abandoned cookbook issues we currently have to deal
with (the systemd cookbook is a particularly egregious example of
name-squatting), and would hopefully encourage community cookbook
developers to put in extra effort, knowing that BCP compliance
meant better visibility and more adoption.Let’s assume there would be a strong quality regime in place for
community cookbooks. Chef, Inc. would actively need to code review
and monitor everything except “write the code”. I’m not sure if
this can work and even make sense. It’s like taking over the
responsibility (“certified cookbook”) without beeing able/willing
to intervene when things get bad (“not certified anymore, but out
of our scope to fix”).It’s also not useful to just increase the pressure for open source
developers if you want to keep and even increase the level of
community contribution.This, again, brings up my other concern: Why, at all, maintain a
community cookbook?The vast majority - as far as I can see - is maintained by single
developers and/or a single company. The GH issues to PR ration is
like 10:1, e.g. it’s very time consuming to support, if you take
issue reports seriously and also less useful because PR aren’t
happening frequently and are probably not that useful (If your shop
uses Debian X, you just don’t care about some PR for CentOS Y that
much - and vice versa).I can fully understand that most OSS cookbook developers don’t have
time for this, become inactive or just give up. They are getting
paid for keeping their employer’s (or their own) business up and
scaling or don’t get paid at all and do this entirely in their
spare time.Nobody can blame them!
Most business are too critical to entirely rely on voluntary time
allocation by open source maintainers. If your business is serious,
you’ll compulsorily have to start in-house maintaining most of the
cookbooks over time. Usually this also implies no further
contribution back to the ecosystem/upstream/supermarket.
https://github.com/aws/opsworks-cookbooks (and OpsWorks in general)
is a very good/bad example.Best case is, that those “hidden” deployments will just stick with
the chef patterns of 2010+, worst case they build things that
should never ever be done in Chef and Ruby +that+ way… In almost
every case, Chef (product) will then be blamed for the eventual
desaster, not the team that was not able to adopt the best
practices provided by the community and/or Chef, Inc…best regards
Rolandanyways, that’s my two cents.
regards,
nathan w
On Wed, Jun 24, 2015 at 4:36 AM Roland Moriz rmoriz@gmail.com
wrote:
Hi,Am 23.06.2015 um 00:23 schrieb Ranjib Dey dey.ranjib@gmail.com
:yes there is a lot of value with Chef inc, providing a public
supermarket instance, it seeds community effort. You dont need it
if you consume cookbooks from github or other sources (can be
public, can be private/org specific).I don’t think that it seeds community effort, because it’s often
a „trap“. A cookbook, e.g. namedsystemd
, looks legit but it may
be broken, outdated or just be a no-op cookbook that reserves the
name:https://supermarket.chef.io/cookbooks?utf8=✓&q=systemd&pl
atforms%5B%5D=
- number of downloads is irrelevant, as we all know
- follower number is also not a good indication, because even
after a year, supermarket did not get the traction of e.g. github- last release date is probably the best indicator. In my
experience most cookbooks that are not updated within the last 12
months are outdated, e.g. won’t work with the recent distros like
Debian 8 or CentOS/RHEL 7. How should starters „know“ this?Imagine a rather new chef user that needs to deal with systemd
unit files. Just with that single „trap" he/she will probably lose
a couple of hours or days or give up and pick something else with
batteries included.I’m sure this is not intentional and everyone had the best
intentions doing it the current way - but IMHO it’s broken :-/
IMHO it’s all about hitting the right spot in between of „too
much“ and „too little“ and the original opscode-cookbooks concept
was probably a „too much“-problem and today it looks like we’re in
a „too little“ situation.why should community maintainers maintain a cookbook? - many.
and i dont see the different of this with ruby gem, or any
userspace tool (pyhton egg, or a debian in ppa). But the common
reasons are: 1) you dont want to reinvent wheel,. if theres no
opensource cookbook on ossec, every time i join a place it allows
me rapidly roll out ossec cookboook. 2) my job depends on my
skills/knowledge, to get a better job, i need to improve my skill.
but that not possible if theres no one to mentor inside my own org.
opensource brings that possibility. again this is not specific to
chef, its very opensource thing, if you dont understand it, or dont
know what value you get, dont do it. but for those of us, who are
outside chef, uses it, and loves it. exposure is a huge thing, i
cant become oracle reporting expert, but i can become chef expert
even if dont have much money.Sorry, but that doesn’t answer my question. Many open source
projects start, when something (technology, framework) becomes
„hot“. Everyone is trying to learn and get a spot in the eco
system. Popularity usually also means a rising number of jobs, e.g.
people can get their OSS contribution funded and/or get an
interesting job. However this strategy starts to collapse when the
crowd moves on to „even hotter“ things (typical hype lifecycle).Example 1: now outdated Ruby gems -> maintainer moved to node ->
now outdated npm modules -> maintainer moved to Go.
Example 2: cfengine -> puppet -> chef -> ansible -> dockerThis brain-drain affects not only the quantity but also the
quality of projects. Less „eyes“ to find bugs, less „hands“ to fix
them, less users to use it. Experience for new users will suffer.
Why should people contribute to $not_hot_anymore projects? I
don’t see that many unique chef-jobs, so having something in the
GitHub repo/CV doesn’t bring you new opportunities by itself.
Even a popular (>200 stars on GH) knife plugin for some trending
and cheap cloud hosting provider brings you exactly 0 job/project
offers (btdt).possible options:
- provide minimal services that work out of the box by yourself
(Chef, Inc)- subsidize community to maintain it (you pay, you decide how)
- offer opportunities so people can benefit from supporting the
community (e.g. job site, contract projects, sales-partnerships
with indies)
otoh: As far as I can see, most „Chef certified partners“
listed on https://www.chef.io/partners/#find-a-partner are not
part of the community and some companies that provide value to the
community are not listed there at all…the last statement you made regarding namespace, is a technical
problem. again its no different here than any other place. for
example redhat has libvirt-lxc which everyone confuses with
standard LXC but the project itself has little code/feature
compatibility with main LXC. The point is like namespace is
perceived, if you want you can publish a cookbook with samename and
if its really good (and assuming theres enough people who wants it)
you can definitely outweigh the other cookbook. if thats not
happening, lets address that.Your libvirt-example is great, as it shows why nearly nobody used
it and why Docker has such a huge impact by just providing a fancy
way to distribute tar archives and wrap some syscalls
(oversimplification intentional)
Redhat isn’t very good in community/relationship outside of
their own Fedora/RHEL area. Just see how they „sell“ systemd to
users, developers and admins. I think better tutorials and
community-relations would have prevented that hatery/shitstorm
against it.
When I talk to systemd-“haters”, I ask them to write me a sysv
-init script for a service, then I show them the systemd unit
representation.
When ansible users talk to me (chef user), they ask me to write a
solution that… whops. damn. You understand what I mean?the definition of critical is very diverse, theres no common
critical component/cookbook. nothing. 0. as far as the whole
community is concerned. if you freeze platform (since chef run
from windows machine to raspberry pi to AIX to solaris) you might
get a list of critical cookbooks (like sudo will be for linux), you
might get another layer on family (like sysdtemd on ubuntu 15.04)
… we are in process of establishing the family specific
maintainers, a similar effort can be made for cookbooks as well…
but will be mostly community and few core contributors … similar
to kernel and userspace… linus and linux foundation or redhat
does not maintain ruby specific rpm etc…Why do people need DevOps? To have a reliable infrastructure to
provide services that make money and to stay competitive. Usually
that involves more or less custom applications based on common
frameworks/stacks that need to be deployed. So at least a couple of
application deployment stacks are critical to show the benefits of
a DevOps solution. Even the learn.chef.io tutorial falls apart,
when you’re using the latest releases of cookbooks used in the
tutorial, so this is also a good definition of critical.i am very interested in addressing this… please keep your
thoughts pouring, but understand we cant solve it in a click,
its gonna take some time, we have to keep talking, and out
collaborative efforts on the next blockers toward this direction.fwiw i am the LT of chef on ubuntu, and i am working on a CD
system that will test actual community cookbooks on every master
merge of chef. Which will greatly reduce the maintenance burden,
cause now core devs can also see what affect the changeset has.
Next step will be do a survey and get a list of cookbooks and
interested folks (brigade as we calling it) for ubuntu. What i
wonder is a common pool might not make sense, though Chef is cross
platform, majority of cookbook is not.You don’t need a fancy distro/edge-case. Just make sure Debian 8,
RHEL 7, Ubuntu 14.04 and 15.04 start to work. And by work i don’t
mean something like „it installs runit triggered by sysv-init — and
it still works…“ on a systemd distroregards
RolandPS: Despite all my examples I’m not a systemd zealot. I was okay
with upstart… But a common base of various distros is a good thing
for everyone in the long run. And it’s also a good example for a
game-changer and about the agility/adoption capabilities of such
things.hth
ranjibOn Mon, Jun 22, 2015 at 2:27 PM, Roland Moriz rmoriz@gmail.com
wrote:Am 22.06.2015 um 22:52 schrieb Julian C. Dunn <
jdunn@aquezada.com>:On Mon, Jun 22, 2015 at 12:33 PM, Adam Jacob adam@chef.io
wrote:To speak for Chef Software directly, we have always had
people on staffwhose role was assisting the creation and maintenance of
cookbooks. Thatnumber has fluctuated up and down over time, with the skill
sets of peoplewe hire, and the normal day-to-day ebb and flow of trying to
figure out howto build a business that is successful. We have people on
staff today who dothe same. What is clear is that the energy around cookbooks
in the communityis far greater than the energy we can muster as an
organization (regardlessof how much capital we do or do not have - y’all outnumber
us) - and so ourfocus today is on trying to build and support the best
community we can,through development of the supermarket, better tooling, and
providing a fewkey examples of how best to build a community cookbook (see
Sean’s work onthe httpd cookbook.)
Perhaps we need to organize a PR/merge festival brigade?
Hey Adam,
Would we consider transferring some of those cookbooks our of
{opscode,chef}-cookbooks to a community-organized org like
chef-brigade (https://github.com/chef-brigade) or redguide
(https://github.com/redguide) for better maintenance? What
would bethe preconditions to doing that?
Personally I would like the chef-brigade and redguide to be
merged,but I do not remember all the players involved – if they are
on thislist perhaps they can speak up.
How would this prevent the problems that happend with the last
migration of former opscode-cookbooks to community maintainers?Why should community maintainers care about the cookbooks in the
future?It can be a time consuming burden and people need to pay their
rent and do their regular jobs…I know, this will be very provoking, but:
If Chef, inc. doesn’t want to maintain even critical cookbooks
anymore, is there still a valid reason for running a public
Supermarket site?If you go the “libertarian way” there is no reason for a
supermarket site to protect/block names of cookbooks anymore that
prevents users to pick other, maybe better community resources over
legacy-cookbooks that are mentioned in guides and examples.Either you (Chef, Inc.) control the market (e.g. maintain
critical things yourself) or you should allow the free market
(=community) to compete against each other based on equal
opportunity (= namespaces or no supermarket). Everything else/in
between will just end in chaos and anarchy.regards
Roland