On 9 January 2015 at 02:52, Andrew Wilkins <andrew.wilk...@canonical.com> wrote:
> On Fri, Jan 9, 2015 at 3:13 AM, Dimiter Naydenov < > dimiter.nayde...@canonical.com> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi all, >> >> FYI, I had a chat with Gustavo yesterday about goamz - workflow on >> github, reviews, maintenance, collaboration with the community, >> merging existing forks, etc. Here's a summary of the most important >> points and decisions: >> >> 0. The v2-dev branch will land tomorrow or on Monday at the latest, so >> both networking and storage work can be unblocked. >> 1. Most of the existing goamz contributors (rogpeppe, mgz, katco, >> wallyworld, axw) asked if they are willing to give a hand with reviews >> / maintenance initially. We aim to attract and involve more external >> users and community members which know EC2/AWS and care enough about >> goamz to become maintainers. >> 2. I'm preparing a CONTRIBUTING.md file with guidelines, and there >> will also be an AUTHORS.md listing all contributors. External >> contributors will need to sign the Canonical CLA. >> 3. Ensure all of the code is LGPLv3 licensed and make copyright >> headers consistent (Gustavo suggested removing his name from "Written >> by .."). >> 4. Bug tracking will happen on Github only - existing relevant bugs >> from LP will be migrated as GH issues and the wiki page / docs updated >> to reflect this. >> 5. We'll use semantic versioning for branches (v1, v2, etc.) and >> releases (tags like v2.1.0) and following Go and gopkg.in guidelines >> to decide when to bump the version. >> 6. In general the workflow for contributing will be the same as >> juju-core (one "+1" and no "-1" from an official maintainer to merge), >> but reviews will happen on Github's Pull Requests, not reviewboard. >> 7. When integrating code from other forks, we need to ensure (as >> reviewers/maintainers) that what goes in is reasonable, consistent >> with the rest of the code, has tests and proper comments/docs. The >> suggestion to "fast-forward" the integration by pulling in code in >> "exp/" or "contrib/" initially (with the intent to clean it up / >> polish it later and "promote" it to a "production-grade" package) is >> not going to work and should be avoided (as for example the exiting >> exp/ package - it never got any serious attention or maintenance). >> > > Sounds good, thanks Dimiter. > +1
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
