goamz status / going forward

[Andrew Wilkins]

On Fri, Jan 9, 2015 at 3:13 AM, Dimiter Naydenov <
dimiter.naydenov at 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.

Cheers,
Andrew


> - --
> Dimiter Naydenov <dimiter.naydenov at canonical.com>
> juju-core team
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJUrtbLAAoJENzxV2TbLzHwUJgH/0MSzjf0siNc1G/w8z+HKRVp
> O5YujoXW9qGg7CmkZjlrdOFOh8WBnHXJ+AT0UjG2KifiM5i4ikcGtH+1QISOBWZ7
> R2sxSxZZxYZz8lCAUI3lU98cuJcVZILs6pIgvJgDQbTKe4jnZUNt+bKonA3kPMtu
> IocX/bmmhJOtIeAm21yrmv5F3/Gk96fL0FpMwDOQdp0b/0Z4809cIlbmUWw4isNz
> DJVGXtE50hesOdyzqeCI2nSr+4CuhbQzXIur6qJtVLcGpK9c3HMtSPWev6K7TzZO
> l9kRkojEZEWWAAagtr4wPVqa1V19m3DXsIQBB274VXIo2OLE3YTXP53QgtgZg5A=
> =UXKM
> -----END PGP SIGNATURE-----
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20150109/7e4914e1/attachment.html>