You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Ignasi <ig...@gmail.com> on 2013/06/18 10:37:40 UTC
Initial draft for the How to contribute guide
Hi!
I've created a page in the wiki [1] explaining the new procedure to
contribute code to jclouds. Its purpose it to provide a standard way
to proceed, although steps like opening a JIRA, etc, can be ignored
when it applies, as we already discussed it in the ML.
Please, hava a look at it and feel free to comment/add/change anything
(fixing my English would be highly appreciated :)). Once we are happy
with it, we should update the "how to contribute guide" in the main
site [2] with the contents in the wiki, since it is out of date (at
least regarding the ICLAs).
[1] https://wiki.apache.org/jclouds/How%20to%20contribute
[2] http://jclouds.incubator.apache.org/documentation/devguides/contributing-to-jclouds/
Re: Initial draft for the How to contribute guide
Posted by Andrew Phillips <ap...@qrmedia.com>.
> Just make the changes.
Done!
ap
Re: Initial draft for the How to contribute guide
Posted by Matt Stephenson <ma...@mattstep.net>.
Just make the changes.
On Jun 27, 2013 10:11 AM, "Andrew Phillips" <ap...@qrmedia.com> wrote:
> Suggestions here:
>
> http://postimg.org/image/**y00zy8v1x/<http://postimg.org/image/y00zy8v1x/>
>
> I couldn't find a "save as draft" or "save as preview" editing mode for
> MoinMoin - if anyone has any tips about how to "stage" suggested changes
> for review/discussion, it'd be grateful to hear about them!
>
> Regards
>
> ap
>
Re: Initial draft for the How to contribute guide
Posted by Andrew Phillips <ap...@qrmedia.com>.
Suggestions here:
http://postimg.org/image/y00zy8v1x/
I couldn't find a "save as draft" or "save as preview" editing mode
for MoinMoin - if anyone has any tips about how to "stage" suggested
changes for review/discussion, it'd be grateful to hear about them!
Regards
ap
Re: Initial draft for the How to contribute guide
Posted by Andrew Bayer <an...@gmail.com>.
The pull request email from GitHub going to the dev list is sufficient, so
far as I know.
A.
On Mon, Jun 24, 2013 at 2:35 PM, Matt Stephenson <ma...@mattstep.net>wrote:
> Does the record of the patch need to exist somewhere in the ASF
> infrastructure? I'm assuming that pointing back to github as a reference
> is insufficient.
>
>
> On Mon, Jun 24, 2013 at 2:31 PM, David Nalley <da...@gnsa.us> wrote:
>
> > On Mon, Jun 24, 2013 at 5:22 PM, Andrew Phillips <ap...@qrmedia.com>
> > wrote:
> > >>> really well for me. Is there a particular reason to use patches? Is
> > this
> > >>> just a matter of personal preference?
> > >>
> > >>
> > >> Just because it is what I used :) I see it a bit easier and also
> > generates
> > >> the patch for the Jira issue, so I think it could be a good way to
> > >> proceed.
> > >> Does anyone have any preference?
> > >
> > >
> > > I thought there was a requirement that the code change be attached to
> the
> > > relevant JIRA issue as a patch. Unless that requirement is not
> applicable
> > > (@mentors: ?), we will still at least need to *generate* the patch and
> > > attach it to the JIRA issue if one exists. Thankfully GitHub's
> > > <pr-href>.patch URL makes that easy.
> > >
> >
> > There is no such requirement. It must be clear that the patch is
> > submitted to the project, and there must be a record of that to deal
> > with long term provenance questions.
> > This means that it could be:
> > * submitted to the mailing list
> > * submitted as a PR (provided the mailing list received the PR
> > notification)
> > * submitted as a patch in Jira
> >
>
Re: Initial draft for the How to contribute guide
Posted by Matt Stephenson <ma...@mattstep.net>.
Does the record of the patch need to exist somewhere in the ASF
infrastructure? I'm assuming that pointing back to github as a reference
is insufficient.
On Mon, Jun 24, 2013 at 2:31 PM, David Nalley <da...@gnsa.us> wrote:
> On Mon, Jun 24, 2013 at 5:22 PM, Andrew Phillips <ap...@qrmedia.com>
> wrote:
> >>> really well for me. Is there a particular reason to use patches? Is
> this
> >>> just a matter of personal preference?
> >>
> >>
> >> Just because it is what I used :) I see it a bit easier and also
> generates
> >> the patch for the Jira issue, so I think it could be a good way to
> >> proceed.
> >> Does anyone have any preference?
> >
> >
> > I thought there was a requirement that the code change be attached to the
> > relevant JIRA issue as a patch. Unless that requirement is not applicable
> > (@mentors: ?), we will still at least need to *generate* the patch and
> > attach it to the JIRA issue if one exists. Thankfully GitHub's
> > <pr-href>.patch URL makes that easy.
> >
>
> There is no such requirement. It must be clear that the patch is
> submitted to the project, and there must be a record of that to deal
> with long term provenance questions.
> This means that it could be:
> * submitted to the mailing list
> * submitted as a PR (provided the mailing list received the PR
> notification)
> * submitted as a patch in Jira
>
Re: Initial draft for the How to contribute guide
Posted by David Nalley <da...@gnsa.us>.
On Mon, Jun 24, 2013 at 5:22 PM, Andrew Phillips <ap...@qrmedia.com> wrote:
>>> really well for me. Is there a particular reason to use patches? Is this
>>> just a matter of personal preference?
>>
>>
>> Just because it is what I used :) I see it a bit easier and also generates
>> the patch for the Jira issue, so I think it could be a good way to
>> proceed.
>> Does anyone have any preference?
>
>
> I thought there was a requirement that the code change be attached to the
> relevant JIRA issue as a patch. Unless that requirement is not applicable
> (@mentors: ?), we will still at least need to *generate* the patch and
> attach it to the JIRA issue if one exists. Thankfully GitHub's
> <pr-href>.patch URL makes that easy.
>
There is no such requirement. It must be clear that the patch is
submitted to the project, and there must be a record of that to deal
with long term provenance questions.
This means that it could be:
* submitted to the mailing list
* submitted as a PR (provided the mailing list received the PR notification)
* submitted as a patch in Jira
Re: Initial draft for the How to contribute guide
Posted by Andrew Phillips <ap...@qrmedia.com>.
>> really well for me. Is there a particular reason to use patches? Is this
>> just a matter of personal preference?
>
> Just because it is what I used :) I see it a bit easier and also generates
> the patch for the Jira issue, so I think it could be a good way to proceed.
> Does anyone have any preference?
I thought there was a requirement that the code change be attached to
the relevant JIRA issue as a patch. Unless that requirement is not
applicable (@mentors: ?), we will still at least need to *generate*
the patch and attach it to the JIRA issue if one exists. Thankfully
GitHub's <pr-href>.patch URL makes that easy.
How the code change is then *actually* applied is, I hope, a matter of
preference. Personally I'm currently tending towards "git am" simply
to be sure that the patch attached to the issue matches the code
change, but that's certainly towards the paranoid end of the spectrum,
I happily admit ;-)
ap
Re: Initial draft for the How to contribute guide
Posted by Ignasi <ig...@gmail.com>.
Thanks for checking!
> 1. I think we can safely remove the legacy-jclouds row from the Git
repositories table. It doesn't have any impact at all on contributing.
It was there just to show which repos exist right now.
Existing forks previous to the move to the ASF will point to the legacy* in
github, so I just added it to the table to help people know what those
repos are.
I agree to remove it, btw :)
>
> 2. Under the review process, I was still under the impression that we
required an explicit +1 for non-committers at the end of the review to make
it clear that the PR is completely finished review and ready to be merged.
Will add this step too.
>
> 3. For Commiting the changes to the ASF repo, I have been using the
process that Adrian outlined in this gist [1] early on. It's been working
really well for me. Is there a particular reason to use patches? Is this
just a matter of personal preference?
Just because it is what I used :) I see it a bit easier and also generates
the patch for the Jira issue, so I think it could be a good way to proceed.
Does anyone have any preference?
>
> 4. Below you mention, "Once we are happy with it, we should update the
"how to contribute guide" in the main site [2] with the contents in the
wiki".
>
> Please no!!! This was my biggest concern when we decided to start using a
wiki. Documentation needs to be DRY too. We must not duplicate our docs.
Totally agree!
Re: Initial draft for the How to contribute guide
Posted by Everett Toews <ev...@RACKSPACE.COM>.
Hi Ignasi,
Thanks a lot for getting a start on this. Here are some comments.
1. I think we can safely remove the legacy-jclouds row from the Git repositories table. It doesn't have any impact at all on contributing.
2. Under the review process, I was still under the impression that we required an explicit +1 for non-committers at the end of the review to make it clear that the PR is completely finished review and ready to be merged.
3. For Commiting the changes to the ASF repo, I have been using the process that Adrian outlined in this gist [1] early on. It's been working really well for me. Is there a particular reason to use patches? Is this just a matter of personal preference?
4. Below you mention, "Once we are happy with it, we should update the "how to contribute guide" in the main site [2] with the contents in the wiki".
Please no!!! This was my biggest concern when we decided to start using a wiki. Documentation needs to be DRY too. We must not duplicate our docs.
We have the wiki for developer documentation (this guide definitely falls into that category) and we have the main site for user documentation.
Once we are happy with this guide, we need to *delete* the contributing-to-jclouds page.
Regards,
Everett
[1] https://gist.github.com/adriancole/5592785
On Jun 18, 2013, at 3:37 AM, Ignasi wrote:
Hi!
I've created a page in the wiki [1] explaining the new procedure to
contribute code to jclouds. Its purpose it to provide a standard way
to proceed, although steps like opening a JIRA, etc, can be ignored
when it applies, as we already discussed it in the ML.
Please, hava a look at it and feel free to comment/add/change anything
(fixing my English would be highly appreciated :)). Once we are happy
with it, we should update the "how to contribute guide" in the main
site [2] with the contents in the wiki, since it is out of date (at
least regarding the ICLAs).
[1] https://wiki.apache.org/jclouds/How%20to%20contribute
[2] http://jclouds.incubator.apache.org/documentation/devguides/contributing-to-jclouds/