<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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>Sounds good, thanks Dimiter.</div><div><br></div><div>Cheers,</div><div>Andrew</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- --<br>
Dimiter Naydenov <<a href="mailto:dimiter.naydenov@canonical.com">dimiter.naydenov@canonical.com</a>><br>
juju-core team<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1<br>
<br>
iQEcBAEBAgAGBQJUrtbLAAoJENzxV2TbLzHwUJgH/0MSzjf0siNc1G/w8z+HKRVp<br>
O5YujoXW9qGg7CmkZjlrdOFOh8WBnHXJ+AT0UjG2KifiM5i4ikcGtH+1QISOBWZ7<br>
R2sxSxZZxYZz8lCAUI3lU98cuJcVZILs6pIgvJgDQbTKe4jnZUNt+bKonA3kPMtu<br>
IocX/bmmhJOtIeAm21yrmv5F3/Gk96fL0FpMwDOQdp0b/0Z4809cIlbmUWw4isNz<br>
DJVGXtE50hesOdyzqeCI2nSr+4CuhbQzXIur6qJtVLcGpK9c3HMtSPWev6K7TzZO<br>
l9kRkojEZEWWAAagtr4wPVqa1V19m3DXsIQBB274VXIo2OLE3YTXP53QgtgZg5A=<br>
=UXKM<br>
-----END PGP SIGNATURE-----<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</font></span></blockquote></div><br></div></div>