make github the primary repository
[gitmo/Moose.git] / lib / Moose / Manual / Contributing.pod
index d7f62c9..2309ff5 100644 (file)
@@ -1,8 +1,10 @@
-=pod
+package Moose::Manual::Contributing;
+
+# ABSTRACT: How to get involved in Moose
 
-=head1 NAME
+__END__
 
-Moose::Manual::Contributing - How to get involved in Moose
+=pod
 
 =head1 GETTING INVOLVED
 
@@ -12,8 +14,6 @@ the L</STANDARD WORKFLOW> is very simple. The general gist is: clone the Git
 repository, create a new topic branch, hack away, then find a committer to
 review your changes.
 
-Note that this document applies to both Moose and L<Class::MOP> development.
-
 =head1 NEW FEATURES
 
 Moose already has a fairly large feature set, and we are currently
@@ -40,28 +40,6 @@ As Moose has matured, some structure has emerged in the process.
 
 =over
 
-=item Contributors - people creating a topic or branch
-
-You.
-
-If you have commit access, you can create a topic on the main Moose.git
-repository.  If you don't have a commit bit, give us your SSH key or create your
-own clone of the L<git://git.moose.perl.org/Moose.git> repository.
-
-The relevant repository URIs are:
-
-=over
-
-=item Read-Only
-
-L<git://git.moose.perl.org/Moose.git>
-
-=item Read+Write
-
-L<gitmo@git.moose.perl.org:Moose.git>
-
-=back
-
 =item Cabal - people who can release moose
 
 These people are the ones who have co-maint on Moose itself and can create a
@@ -72,6 +50,15 @@ to push to stable branches.
 Cabal members are listed in L<Moose> and can often be found on irc in the
 L<irc://irc.perl.org/#moose-dev> channel.
 
+=item Contributors - people creating a topic or branch
+
+You.
+
+The easiest way to submit a patch is to submit a pull request through Github.
+You can fork the Moose repository at C<git@github.com:moose/moose.git>. If you
+would prefer not to use Github, come talk to us at C<#moose> on C<irc.perl.org>
+and we can work something out.
+
 =back
 
 =head1 BRANCH LAYOUT
@@ -237,39 +224,38 @@ defend your change.
     # minor releases
     git checkout stable/X.YY
 
-    # edit for final version bumping, changelogging, etc
-    # prepare release (test suite etc)
-    perl-reversion -bump
-    make manifest
+    # do final changelogging, etc
+    vim dist.ini # increment version number
     git commit
+    dzil release # or dzil release --trial for trial releases
+    git commit # to add the actual release date
     git branch stable/X.YY # only for non-trial major releases
-    shipit # does not ship the tarball, but does everything else
-
-    # non-trial releases
-    cpan-upload ~/shipit-dist/Moose-X.YYZZ.tar.gz
-
-    # trial releases
-    cd ~/shipit-dist
-    mv Moose-X.YYZZ.tar.gz Moose-X.YYZZ-TRIAL.tar.gz
-    cpan-upload Moose-X.YYZZ-TRIAL.tar.gz
 
 =head2 Release How-To
 
-Moose (and L<Class::MOP>) releases fall into two categories, each with their
-own level of release preparation. A minor release is one which does not
-include any API changes, deprecations, and so on. In that case, it is
-sufficient to simply test the release candidate against a few different
-different Perls. Testing should be done against at least two recent major
-version of Perl (5.8.8 and 5.10.1, for example). If you have more versions
-available, you are encouraged to test them all. However, we do not put a lot
-of effort into supporting older 5.8.x releases.
+Moose uses L<Dist::Zilla> to manage releases. Although the git repository comes
+with a C<Makefile.PL>, it is a very basic one just to allow the basic
+C<perl Makefile.PL && make && make test> cycle to work. In particular, it
+doesn't include any release metadata, such as dependencies. In order to get
+started with Dist::Zilla, first install it: C<cpanm Dist::Zilla>, and then
+install the plugins necessary for reading the C<dist.ini>:
+C<dzil authordeps | cpanm>.
+
+Moose releases fall into two categories, each with their own level of release
+preparation. A minor release is one which does not include any API changes,
+deprecations, and so on. In that case, it is sufficient to simply test the
+release candidate against a few different different Perls. Testing should be
+done against at least two recent major version of Perl (5.8.8 and 5.10.1, for
+example). If you have more versions available, you are encouraged to test them
+all. However, we do not put a lot of effort into supporting older 5.8.x
+releases.
 
 For major releases which include an API change or deprecation, you should run
 the F<xt/author/test-my-dependents.t> test. This tests a long list of MooseX
 and other Moose-using modules from CPAN. In order to run this script, you must
-arrange to have the new version of Moose and/or Class::MOP in Perl's include
-path. You can use C<prove -b> and C<prove -I>, install the module, or fiddle
-with the C<PERL5LIB> environment variable, whatever makes you happy.
+arrange to have the new version of Moose in Perl's include path. You can use
+C<prove -b> and C<prove -I>, install the module, or fiddle with the C<PERL5LIB>
+environment variable, whatever makes you happy.
 
 This test downloads each module from CPAN, runs its tests, and logs failures
 and warnings to a set of files named F<test-mydeps-$$-*.log>. If there are
@@ -278,11 +264,7 @@ to fix them. If the module author simply isn't available or does not want to
 fix the bug, it is okay to make a release.
 
 Regardless of whether or not a new module is available, any breakages should
-be noted in the conflicts list in the distribution's F<Makefile.PL>.
-
-Both Class::MOP and Moose have a F<.shipit> file you can use to make sure the
-release goes smoothly. You are strongly encouraged to use this instead of
-doing the final release steps by hand.
+be noted in the conflicts list in the distribution's F<dist.ini>.
 
 =head1 EMERGENCY BUG WORKFLOW (for immediate release)
 
@@ -342,15 +324,14 @@ if you want to start working on it again.
 
 =head1 TESTS, TESTS, TESTS
 
-If you write I<any> code for Moose or Class::MOP, you B<must> add
-tests for that code. If you do not write tests then we cannot
-guarantee your change will not be removed or altered at a later date,
-as there is nothing to confirm this is desired behavior.
+If you write I<any> code for Moose, you B<must> add tests for that code. If you
+do not write tests then we cannot guarantee your change will not be removed or
+altered at a later date, as there is nothing to confirm this is desired
+behavior.
 
-If your code change/addition is deep within the bowels of
-Moose/Class::MOP and your test exercises this feature in a non-obvious
-way, please add some comments either near the code in question or in
-the test so that others know.
+If your code change/addition is deep within the bowels of Moose and your test
+exercises this feature in a non-obvious way, please add some comments either
+near the code in question or in the test so that others know.
 
 We also greatly appreciate documentation to go with your changes, and an entry
 in the Changes file. Make sure to give yourself credit! Major changes or new
@@ -382,23 +363,4 @@ All backwards incompatible changes B<must> be documented in
 L<Moose::Manual::Delta>. Make sure to document any useful tips or workarounds
 for the change in that document.
 
-=head1 AUTHOR
-
-Stevan Little E<lt>stevan@iinteractive.comE<gt>
-
-Chris (perigrin) Prather
-
-Yuval (nothingmuch) Kogman
-
-Jesse Luehrs E<lt>doy at tozt dot netE<gt>
-
-=head1 COPYRIGHT AND LICENSE
-
-Copyright 2009-2010 by Infinity Interactive, Inc.
-
-L<http://www.iinteractive.com>
-
-This library is free software; you can redistribute it and/or modify
-it under the same terms as Perl itself.
-
 =cut