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