[master][blivet] Add CONTRIBUTING file to blivet.

Samantha N. Bueno sbueno+anaconda at redhat.com
Wed Jul 29 14:52:46 UTC 2015


On Tue, Jul 28, 2015 at 12:03:11PM -0700, Brian C. Lane wrote:
> On Mon, Jul 27, 2015 at 10:56:58AM -0400, Samantha N. Bueno wrote:
> > This contains patch submission guidelines for blivet, which are based
> > on the kernel patch submission guidelines.
> > ---
> >  CONTRIBUTING | 268 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 268 insertions(+)
> >  create mode 100644 CONTRIBUTING
> 
> Should this go in docs/ instead? It would be useful if it showed up in
> the Sphinx docs and used its formatting.

Not a bad idea, but I'll defer to dlehman and let him decide on that.
 
> > 
> > diff --git a/CONTRIBUTING b/CONTRIBUTING
> > new file mode 100644
> > index 0000000..281e301
> > --- /dev/null
> > +++ b/CONTRIBUTING
> > @@ -0,0 +1,268 @@
> > +0. Thanks to the kernel patch submission guidelines, which were used as a
> > +   framework for creating this document.
> > +
> > +   https://www.kernel.org/doc/Documentation/SubmittingPatches
> > +
> > +I. Source
> > +=========
> > +
> > +A) Obtain a current source tree.
> > +If you do not have a repository with the current source handy, use git to obtain
> > +one.  All installer-related projects can be found on the RH Installer project
> > +page:
> > +
> > +  http://github.com/rhinstaller/
> > +
> 
> Probably want to point directly to the blivet repo too.

Yes, good idea, added.
 
> > +III. Submitting Patches
> > +=======================
> > +    - Acceptable formats for patch submission
> > +    - Email guidelines
> > +    - Pull Request guidelines
> > +
> 
> This should also mention bugzilla. I've been adding the pull request in
> a bz comment when moving it to POST for example. Contributors fixing a
> bug should do something similar or attach a git formatted patch to the
> bug.

Good point, I will add something.
 
> > +    It is common convention to prefix path subject lines with [PATCH].  This
> 
> s/path/patch/

Oops....
 
> > +    makes clear that the message is a patch.
> > +
> > +    ii. No MIME, no links, no compression, no attachments.  Just plain text.
> > +    The developers need to be able to read and comment on the changes you are
> > +    submitting.  It is important for a developer to be able to "quote" your
> > +    changes, using standard e-mail tools, so that they may comment on specific
> > +    portions of your code.
> > +
> > +    For this reason, all patches should be submitting e-mail "inline".  WARNING:
> > +    Be wary of your editor's word-wrap corrupting your patch, if you choose to
> > +    cut-n-paste your patch.
> > +
> > +    Do not attach the patch as a MIME attachment, compressed or not.
> 
> Mention git send-email here. That's the cleanest way to get it onto the
> list.

Yes, I can't believe I forgot that, thank you.
 
> Looks good other than those small things, thanks!

Thanks!
 
> -- 
> Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
> _______________________________________________
> anaconda-patches mailing list
> anaconda-patches at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches


More information about the anaconda-patches mailing list