This looks great - thank you, and apologies for the broken test. I've closed the pull request, so I think everything is done. Nick On 6 August 2012 13:02, Robert Newson <[email protected]> wrote:
> Hi Nick, > > I've merged your new feature to couchdb master, thanks very much! > > You'll notice a few tweaks from me; > > 1) I removed you from THANKS, given that it's now auto-generated (slipped > my mind) > 2) I fixed the broken etap test (sometimes get_suffix receives a binary, > sometimes a list) > 3) The algorithm is called utc_id, the suffix property is called > utc_id_suffix > > We're only partially integrated with github pull requests, so you will > need to close the PR yourself once you're satisfied that I've incorporated > your work correctly. > > B. > > On 6 Aug 2012, at 09:51, Nick North wrote: > > > 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 <[email protected]> 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 <[email protected]> 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 > >> > >
