incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick North <nort...@gmail.com>
Subject Re: Process for code submissions?
Date Mon, 06 Aug 2012 08:51:36 GMT
I've updated the pull request with these changes and updates to the NEWS
and CHANGES files. The note at the bottom of the THANKS file implied that
maybe I did not need to add my name, but I did it just in case. I'm
slightly wary of the git processes involved in all this, but the GitHub
diff looks good, so I hope I haven't made any mistakes. Thanks again for
your help, and please do let me know of there's anything else I should do,

Nick
On 5 August 2012 16:43, Robert Newson <robert.newson@gmail.com> wrote:

> Sorry for the delay, the patch looks good to me.  I'm happy to merge
> it if you do two things. 1) consistent use of utc_id_suffix instead of
> id_suffix in config 2) add your name to the THANKS file.
>
> B.
>
> Sent from my iPad
>
> On 5 Aug 2012, at 16:05, Nick North <north.n@gmail.com> wrote:
>
> > I'm wondering if there is any process for dealing with code submissions
> > i.e. for getting a decision that they are accepted, rejected, or
> ignored. I
> > hope the following doesn't come across as a complaint, because I think
> > CouchDb and the community are great, but I feel in limbo on this
> particular
> > topic.
> >
> > The reason for asking is that I submitted JIRA issue
> > COUCHDB-1373<https://issues.apache.org/jira/browse/COUCHDB-1373>a
> > while back, then let it drop for some while before submitting pull
> > request 28 <https://github.com/apache/couchdb/pull/28> with proposed
> code
> > for implementing the suggestion. After some initial discussion on the
> JIRA
> > issue, there was no response to the pull request, and I don't know if
> that
> > means I didn't follow the right process, it has been rejected, it's been
> > decided to ignore it, or it's gone into a queue to be considered
> eventually.
> >
> > There are many good reasons for not accepting submitted code: the
> > suggestion may be bad, the code may be bad, there may not be the
> resources
> > to deal with it, it may be undesirable creeping featurism, it may come
> from
> > someone who hasn't demonstrated good understanding of the project etc.
> Any
> > of those verdicts might apply in this case but, whatever the reason is,
> it
> > would be good to be told it so that I know whether it's worth expending
> > more effort to improve my chances of acceptance, or whether to spend that
> > time on finding ways to carry on without the proposed code.
> >
> > If someone can help or guide me, or give an outline of how things operate
> > in this area, I'd be really grateful. Many thanks,
> >
> > Nick North
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message