If you missed the Charmers Meeting today, it was our first Hangouts on Air driven Charmers meeting for public archival. You can catch up here: https://www.youtube.com/watch?v=99iiQCypEGI
I've attached the charmer meeting minutes for those of you that prefer to read than watch. All the best Charles Butler <[email protected]> - Juju Charmer Come see the future of datacenter orchestration: http://jujucharms.com
# Charmer Quorem - 4/1/2015 ## Topics ### Topic 1 #### Review Queue proposed: Marco Ceppi Changing what we are reviewing in the rev.q - today we are reviewing the charm code itself. Instead of reviewing the charm code, we review people instead. Reason being: As people join the charming community we rev the work they do, and eventually - they build trust within the circle by making good contributions and illustrating good contributions. With these qualities embodied, we can give more trust and allow them to expedite changes in the ecosystem. They are basically 'unblocked'. The RevQ will be for new charms. This converts the ~charmers group from a gate keeper role and more into a shepherd role. The application process is now applied to anyone contributing. (paraphrased) -- convo snippet -- Tribaal - If someone is an expert on HAPROXY - and we unblock on them contributing to HAPROXy do we still have to x-ray examine their contributions to say MySQL? Marco - Juju Publish is changing, and this will change how we view the incoming commits and reviews. This puts the burden of ownership of those reviews on the community maintaining the charm (if present). They will handle the publish vs us doing the review to publish as well. dpb - Would we require long term contributors like Stub, to still undergo the peer review? (given example) - WHy eliminate that process? Marco - we have scaling issues in our current model. me: We need comprehensive test suites to enable this at a bare minimum, especially on existing charms. Marco: +1'd vote subject: Review people, vs reviewing charms Vote: - tribaal +1 - dpb +1 - niedbalski +1 - marcoceppi +1 - mbruzek +1 - tvansteenburgh +1 with reservations - lazypower +1 Action Items: Mail list: draft how this will look + timeline for store changes ### Topic 2 #### Immutable config modelling with dist.yaml proposed: Charles Butler dist.yaml immutable config - this allows vendors to set tuneable options at deploy time, but do not allow users to change it post deployment. vote subject: include dist.yaml in the charm add template generator. Vote: - tribaal +1 - dpb - abstain - niedbalski +1 - marcoceppi +1 - mbruzek +1 - tvansteenburgh +1 - lazypower +1 action items: mail list, document pattern for official docs, draft spec for core on how immutable config should look and behave. ### Topic 3 #### Change the way juju charm test command works proposed: Marco Ceppi Charmbox now isolates charm testing. we want to make charm test run a mirror of what CI is doing. Pull the docker container, execute the same steps the ci infra does inside that container. This provides a 1:1 comparison during your testing. Vote: - tribaal +1 - dpb +1 - niedbalski abstain - marcoceppi +1 - mbruzek +1 - tvansteenburgh +1 - lazypower +1
charmer-meeting-4-1-2015.pdf
Description: Adobe PDF document
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
