> ... it would be nice if the issue with patch would be read by a core > developer that responded ...
I agree this would be nice. However, as Fabio points out, there are currently 320 requests: http://216.121.112.228/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+NH+AND+status+in+(Open,+%22In+Progress%22,+Reopened)+ORDER+BY+votes+DESC,+key+DESC,+updated+DESC If it takes (say): To read through an issue: 2 mins; To understand the issue: 20 mins; (hard to judge *1) To review the code: 60 mins; (another hard to judge *2) To write a coherent response: 10 mins. So that’s 92 minutes per issue * 320 issues == 29,440 minutes (490 hours, or 20 days). And that’s not necessarily to implement it ... that’s just to get a sensible/useful response. *1 – actually I can rarely come to a good conclusion in 20 mins ... I guess I’m just slow, but I like to chew on things for a few days. *2 – locate the appropriate code, download/apply patches, compile/run tests etc .... and again, I’m not the fastest programmer, 60 mins is a good day I think. For both of these, your mileage will vary wildly depending on issue + developer. All this weighs against (of course): Happy customer + proud to have implemented new feature/fixed bug == priceless. (said like a Mastercard advert voiceover) Best suggestion is to try to get it voted up I think. Oh ... and ... unfortunately it took me 10 minutes to write this e-mail. > Would be nice to have it in the next release as all others fixes; hopefully > we will not have others 318 mails asking the same. I hope so too Fabio. From: Ramon Sent: Thursday, February 17, 2011 2:51 PM To: [email protected] Subject: Re: [nhibernate-development] Is it possible to include patch NH-2520 in the next release? I added the schema change to have intellisense when using the schema in visualstudio. There is a difference between the behaviour of types DateTime and TimeStamp. NH3 introduced the types UtcDateTime and LocalDateTime but that change did not include support for Timestamp in UTC format. That is why I made this change to be complete. I often make use of the timestamp type but it is very annoying that it uses the local time when generating a new value and that it does not set its Kind. I fully understand that there is a backlog of patches to merge in the next release but what I ment is that I checked the issue that I submitted and there was no action performed on it or any comments posted. It is still unassigned so I wondered why that is and that is the reason for my question. If it does not make it into the next release then no hardfeelings, then maybe in a version after that or maybe not in *any* future version. But it would be nice if the issue with patch would be read by a core developer that responded if it is usefull and/or responded about the quality of my patch and/or what I need to change to get it included in a future release. -- Ramon On Thu, Feb 17, 2011 at 3:27 PM, Fabio Maulo <[email protected]> wrote: You are changing the schema (xsd) adding a new element <timestamputc> that is outside the scope of the issue and, overall is unneeded (<version> with its 'type' is enough). The change on the schema is not managed during deserialization/binding of meta-data. Then we can discuss about the real need of TimestampUtc vs a DateTime2 with its Kind but this is another stuff. Would be nice to have it in the next release as all others fixes; hopefully we will not have others 318 mails asking the same. On Thu, Feb 17, 2011 at 11:02 AM, Ramon <[email protected]> wrote: The title is about something, the patch is about something and something else. I don't understand you :-) The patch is about adding a new type TimestampUtc which uses DateTime.UtcNow instead of DateTime.Now to get the current system time. Is that what you wanted to know? -- Fabio Maulo
<<wlEmoticon-sadsmile[1].png>>
