And in particular, pull requests need the agreement of the maintainers of all affected modules. Unattended pull requests may require lobbying. Maintainers can be nagged on the mailing lists or by assigning issues to them in Jira.
Pull requests from committers get faster attention because of reciprocity: committers are often maintainers and are likely to themselves receive requests from other committers. Open source is a social activity and based on relationships. One hand washes the other. Open source is a gift culture. If you are not a committer, you can establish your presence with gifts of source code, with units tests to support their value; you still need to present your gift and encourage the recipients to accept it. How do we know that your code is worthwhile and wanted unless you are willing to advocate for it? Some patches are too expensive to accept. Once accepted, we will be maintaining it forever. Your description of how important a patch is, even if only to you, may be enough to convince a maintainer. Once you have built your relationship with the community, your pull requests will likely be attended more quickly. Kind regards, Ben. On 26/06/13 06:09, Jody Garnett wrote: > Same as a patch in Jira - should have a test case, subject to volunteer time, > etc... > > Pull request coming in via our change control procedure are planned during > our bi-weekly meeting, and in the case of GeoSolutions API change the subject > of scheduling. In this case geotools is entering lockdown shortly, so as a > volunteer I want to see any API changed done *now* so it does not wait 6 > months. > > We have a small number of active participants, if your organization needs > more timely service consider taking part in the project (as a module > maintainer or obtaining commit access). Some groups that have restrictions on > programming in public go the commercial support option. > > We're there any pull requests in particular you were concerned with? > > -- > Jody Garnett > > On 26/06/2013, at 7:39 AM, Brett Walker <brett.wal...@geometryit.com> wrote: > >> Hi, >> >> What is the policy/procedure/expectation for pull requests that have been >> submitted for more than a couple of weeks? >> >> There are a number of pull requests that have been sitting 'dormant' for a >> while. Do they sit forever open with no feedback, or should they be closed, >> with comment, if not found suitable. >> >> It seems that pull requests from developers with commit access have >> preference with daylight second. >> >> Ignoring worthwhile patches could appear to give the cold shoulder to the >> wider community. >> >> Your thoughts please, >> Brett >> >> Sent from my iPad >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-dev2dev >> _______________________________________________ >> GeoTools-Devel mailing list >> GeoTools-Devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geotools-devel > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au> Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
