I also love to be part of it if you set up a github project I'll be glad to send some PL on this subject
----- Gaetan 2014-02-19 14:43 GMT+01:00 Daniel Fath <[email protected]>: > > Hi everyone, > > > So I would like to know if anyone else working on this and to read your > > comments on the JSR 310 choice. > > > I was interested but day job, master thesis and my own XML parser got in > the way :( > > If you are starting I'd love to join and help you, but I have a LOT of > reading on my plate. From what I've gathered you best > start from ISO-8601 add the Olson time database and basically build from > there. > > Sincerely, > -Y- > > > On Wed, Feb 19, 2014 at 4:38 AM, <[email protected]> wrote: > >> Send Rust-dev mailing list submissions to >> [email protected] >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://mail.mozilla.org/listinfo/rust-dev >> or, via email, send a message with subject or body 'help' to >> [email protected] >> >> You can reach the person managing the list at >> [email protected] >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Rust-dev digest..." >> >> >> Today's Topics: >> >> 1. lib: Datetime library (Alfredos (fredy) Damkalis) >> 2. RFC: About the library stabilization process (Brian Anderson) >> 3. Re: RFC: About the library stabilization process (Huon Wilson) >> 4. Re: issue numbers in commit messages (Benjamin Striegel) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 18 Feb 2014 23:52:45 +0200 >> From: "Alfredos (fredy) Damkalis" <[email protected]> >> To: [email protected] >> Subject: [rust-dev] lib: Datetime library >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hi everyone, >> >> I am new to rust and interested in writing datetime library. >> >> I have already read most of the linked documents and code gathered by >> Luis de Bethencourt and others in wiki page [1]. >> >> I have also read the thread [2] where Luis offered his help on writing >> this library. I have talked to Luis and unfortunately he is busy these >> days, so I have offered to continue his work. >> >> Searching about datetime libraries ended up to JSR 310 [3] which was >> also mentioned in the previous thread [2]. This specification is in >> final draft state and it seems to be the most complete one out there >> about datetime libraries. You can take a quick look at its basic ideas >> in a recent article [4] in java magazine. >> >> I am also aware of Ted Horst's work[5] where the last commits look like >> maintenance work. I am not sure if he is going to expand his library, >> unfortunately I didn't have the chance to talk to him. >> >> So I would like to know if anyone else working on this and to read your >> comments on the JSR 310 choice. >> >> Thank you, >> fredy >> >> [1] https://github.com/mozilla/rust/wiki/Lib-datetime >> [2] >> https://mail.mozilla.org/pipermail/rust-dev/2013-September/005528.html >> [3] https://jcp.org/en/jsr/detail?id=310 >> [4] >> >> http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html >> [5] https://github.com/tedhorst/rust_datetime >> >> >> ------------------------------ >> >> Message: 2 >> Date: Tue, 18 Feb 2014 17:40:26 -0800 >> From: Brian Anderson <[email protected]> >> To: "[email protected]" <[email protected]> >> Subject: [rust-dev] RFC: About the library stabilization process >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Hey there. >> >> I'd like to start the long process of stabilizing the libraries, and >> this is the opening salvo. This process and the tooling to support it >> has been percolating on the issue tracker for a while, but this is a >> summary of how I expect it to work. Assuming everybody feels good about >> it, we'll start trying to make some simple API's stable starting later >> this week or next. >> >> >> # What is the stability index and stability attributes? >> >> The stability index is a way of tracking, at the item level, which >> library features are safe to use backwards-compatibly. The intent is >> that the checks for stability catch all backwards-incompatible uses of >> library features. Between feature gates and stability >> >> The stability index of any particular item can be manually applied with >> stability attributes, like `#[unstable]`. >> >> These definitions are taken directly from the node.js documentation. >> node.js additionally defines the 'locked' and 'frozen' levels, but I >> don't think we need them yet. >> >> * Stability: 0 - Deprecated >> >> This feature is known to be problematic, and changes are >> planned. Do not rely on it. Use of the feature may cause >> warnings. Backwards >> compatibility should not be expected. >> >> * Stability: 1 - Experimental >> >> This feature was introduced recently, and may change >> or be removed in future versions. Please try it out and provide >> feedback. >> If it addresses a use-case that is important to you, tell the node >> core team. >> >> * Stability: 2 - Unstable >> >> The API is in the process of settling, but has not yet had >> sufficient real-world testing to be considered stable. >> Backwards-compatibility >> will be maintained if reasonable. >> >> * Stability: 3 - Stable >> >> The API has proven satisfactory, but cleanup in the underlying >> code may cause minor changes. Backwards-compatibility is guaranteed. >> >> Crucially, once something becomes 'stable' its interface can no longer >> change outside of extenuating circumstances - reviewers will need to be >> vigilant about this. >> >> All items may have a stability index: crates, modules, structs, enums, >> typedefs, fns, traits, impls, extern blocks; >> extern statics and fns, methods (of inherent impls only). >> >> Implementations of traits may have their own stability index, but their >> methods have the same stability as the trait's. >> >> >> # How is the stability index determined and checked? >> >> First, if the node has a stability attribute then it has that stability >> index. >> >> Second, the AST is traversed and stability index is propagated downward >> to any indexable node that isn't explicitly tagged. >> >> Reexported items maintain the stability they had in their original >> location. >> >> By default all nodes are *stable* - library authors have to opt-in to >> stability index tracking. This may end up being the wrong default and >> we'll want to revisit. >> >> During compilation the stabilization lint does at least the following >> checks: >> >> * All components of all paths, in all syntactic positions are checked, >> including in >> * use statements >> * trait implementation and inheritance >> * type parameter bounds >> * Casts to traits - checks the trait impl >> * Method calls - checks the method stability >> >> Note that not all of this is implemented, and we won't have complete >> tool support to start with. >> >> >> # What's the process for promoting libraries to stable? >> >> For 1.0 we're mostly concerned with promoting large portions of std to >> stable; most of the other libraries can be experimental or unstable. >> It's going to be a lengthy process, and it's going to require some >> iteration to figure out how it works best. >> >> The process 'leader' for a particular module will post a stabilization >> RFC to the mailing list. Within, she will state the API's under >> discussion, offer an overview of their functionality, the patterns used, >> related API's and the patterns they use, and finally offer specific >> suggestions about how the API needs to be improved or not before it's >> final. If she can confidently recommend that some API's can be tagged >> stable as-is then that helps everybody. >> >> After a week of discussion she will summarize the consensus, tag >> anything as stable that already has agreement, file and nominate issues >> for the remaining, and ensure that *somebody makes the changes*. >> >> During this process we don't necessarily need to arrive at a plan to >> stabilize everything that comes up; we just need to get the most crucial >> features stable, and make continual progress. >> >> We'll start by establishing a stability baseline, tagging most >> everything experimental or unstable, then proceed to the very simplest >> modules, like 'mem', 'ptr', 'cast', 'raw'. >> >> >> >> ------------------------------ >> >> Message: 3 >> Date: Wed, 19 Feb 2014 13:54:21 +1100 >> From: Huon Wilson <[email protected]> >> To: [email protected] >> Subject: Re: [rust-dev] RFC: About the library stabilization process >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset=UTF-8; format=flowed >> >> There are some docs for these attributes: >> http://static.rust-lang.org/doc/master/rust.html#stability (which may >> need to be updated as we formalise exactly what each one means, and so >> on.) >> >> And, FWIW, the default currently implemented is unmarked nodes are >> unstable: that is, putting #[deny(unstable)] on an item will emit errors >> at the uses of functions etc. that lack an explicit stability attribute. >> >> Huon >> >> >> On 19/02/14 12:40, Brian Anderson wrote: >> > Hey there. >> > >> > I'd like to start the long process of stabilizing the libraries, and >> > this is the opening salvo. This process and the tooling to support it >> > has been percolating on the issue tracker for a while, but this is a >> > summary of how I expect it to work. Assuming everybody feels good >> > about it, we'll start trying to make some simple API's stable starting >> > later this week or next. >> > >> > >> > # What is the stability index and stability attributes? >> > >> > The stability index is a way of tracking, at the item level, which >> > library features are safe to use backwards-compatibly. The intent is >> > that the checks for stability catch all backwards-incompatible uses of >> > library features. Between feature gates and stability >> > >> > The stability index of any particular item can be manually applied >> > with stability attributes, like `#[unstable]`. >> > >> > These definitions are taken directly from the node.js documentation. >> > node.js additionally defines the 'locked' and 'frozen' levels, but I >> > don't think we need them yet. >> > >> > * Stability: 0 - Deprecated >> > >> > This feature is known to be problematic, and changes are >> > planned. Do not rely on it. Use of the feature may cause >> > warnings. Backwards >> > compatibility should not be expected. >> > >> > * Stability: 1 - Experimental >> > >> > This feature was introduced recently, and may change >> > or be removed in future versions. Please try it out and provide >> > feedback. >> > If it addresses a use-case that is important to you, tell the node >> > core team. >> > >> > * Stability: 2 - Unstable >> > >> > The API is in the process of settling, but has not yet had >> > sufficient real-world testing to be considered stable. >> > Backwards-compatibility >> > will be maintained if reasonable. >> > >> > * Stability: 3 - Stable >> > >> > The API has proven satisfactory, but cleanup in the underlying >> > code may cause minor changes. Backwards-compatibility is >> guaranteed. >> > >> > Crucially, once something becomes 'stable' its interface can no longer >> > change outside of extenuating circumstances - reviewers will need to >> > be vigilant about this. >> > >> > All items may have a stability index: crates, modules, structs, enums, >> > typedefs, fns, traits, impls, extern blocks; >> > extern statics and fns, methods (of inherent impls only). >> > >> > Implementations of traits may have their own stability index, but >> > their methods have the same stability as the trait's. >> > >> > >> > # How is the stability index determined and checked? >> > >> > First, if the node has a stability attribute then it has that >> > stability index. >> > >> > Second, the AST is traversed and stability index is propagated >> > downward to any indexable node that isn't explicitly tagged. >> > >> > Reexported items maintain the stability they had in their original >> > location. >> > >> > By default all nodes are *stable* - library authors have to opt-in to >> > stability index tracking. This may end up being the wrong default and >> > we'll want to revisit. >> > >> > During compilation the stabilization lint does at least the following >> > checks: >> > >> > * All components of all paths, in all syntactic positions are checked, >> > including in >> > * use statements >> > * trait implementation and inheritance >> > * type parameter bounds >> > * Casts to traits - checks the trait impl >> > * Method calls - checks the method stability >> > >> > Note that not all of this is implemented, and we won't have complete >> > tool support to start with. >> > >> > >> > # What's the process for promoting libraries to stable? >> > >> > For 1.0 we're mostly concerned with promoting large portions of std to >> > stable; most of the other libraries can be experimental or unstable. >> > It's going to be a lengthy process, and it's going to require some >> > iteration to figure out how it works best. >> > >> > The process 'leader' for a particular module will post a stabilization >> > RFC to the mailing list. Within, she will state the API's under >> > discussion, offer an overview of their functionality, the patterns >> > used, related API's and the patterns they use, and finally offer >> > specific suggestions about how the API needs to be improved or not >> > before it's final. If she can confidently recommend that some API's >> > can be tagged stable as-is then that helps everybody. >> > >> > After a week of discussion she will summarize the consensus, tag >> > anything as stable that already has agreement, file and nominate >> > issues for the remaining, and ensure that *somebody makes the changes*. >> > >> > During this process we don't necessarily need to arrive at a plan to >> > stabilize everything that comes up; we just need to get the most >> > crucial features stable, and make continual progress. >> > >> > We'll start by establishing a stability baseline, tagging most >> > everything experimental or unstable, then proceed to the very simplest >> > modules, like 'mem', 'ptr', 'cast', 'raw'. >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > [email protected] >> > https://mail.mozilla.org/listinfo/rust-dev >> >> >> >> ------------------------------ >> >> Message: 4 >> Date: Tue, 18 Feb 2014 22:38:02 -0500 >> From: Benjamin Striegel <[email protected]> >> Cc: "[email protected]" <[email protected]> >> Subject: Re: [rust-dev] issue numbers in commit messages >> Message-ID: >> < >> caavrl-kyjprudicyqlnhrtp2e5zhmf1ywn96wn35bjrlbmv...@mail.gmail.com> >> Content-Type: text/plain; charset="iso-8859-1" >> >> Having read this week's meeting notes on this topic: >> >> > we'll get bors to warn people about not putting the issue number in >> commit messages >> >> Can anyone elaborate on what this will entail? By "commit message" do you >> mean the honest-to-god git commit message, or the Github PR message, or >> both? What form will the warning take, and how easy will it be to ignore >> it >> in order to accomodate one-off contributors submitting typo fixes? >> >> >> On Tue, Feb 18, 2014 at 8:06 AM, Huon Wilson <[email protected]> wrote: >> >> > I wrote a quick & crappy script that automates going from commit -> PR: >> > >> > #!/bin/sh >> > >> > if [ $# -eq 0 ]; then >> > echo 'Usage: which-pr COMMIT' >> > exit 0 >> > fi >> > >> > git log master ^$1 --ancestry-path --oneline --merges | \ >> > tail -1 | \ >> > sed 's@.*#\([0-9]*\) : .*@ >> http://github.com/mozilla/rust/pull/\1@' >> > >> > Putting this in your path gives: >> > >> > $ which-pr 6555b04 >> > http://github.com/mozilla/rust/pull/12345 >> > >> > $ which-pr a02b10a0621adfe36eb3cc2e46f45fc7ccdb7ea2 >> > http://github.com/mozilla/rust/pull/12162 >> > >> > Of course, I'm sure there are corner cases that don't work, and it's >> > definitely not as usable as something directly encoded in the commit. >> > >> > >> > Huon >> > >> > >> > >> > On 18/02/14 13:17, Nick Cameron wrote: >> > >> > Right, that is exactly what I want to see, just on every commit. For >> > example, >> > >> https://github.com/mozilla/rust/commit/a02b10a0621adfe36eb3cc2e46f45fc7ccdb7ea2 >> . >> > has none of that info and I can't see any way to get it (without the >> kind >> > of Git-fu suggested earlier). (Well, I can actually see that >> r=nikomatsakis >> > from the comments at the bottom, but I can't see how that r+ came about, >> > whether there was any discussion, whether there was an issue where this >> was >> > discussed or not, etc.). >> > >> > >> > On Tue, Feb 18, 2014 at 3:02 PM, Corey Richardson <[email protected] >> >wrote: >> > >> >> >> >> >> https://github.com/mozilla/rust/commit/25147b2644ed569f16f22dc02d10a0a9b7b97c7e >> >> seems to provide all of the information you are asking for? It >> >> includes the text of the PR description, the PR number, the name of >> >> the branch, and who reviewed it. I agree with your premise but I'm not >> >> sure I agree that the current situation isn't adequate. But I wouldn't >> >> be opposed to such a change. >> >> >> >> On Mon, Feb 17, 2014 at 8:54 PM, Nick Cameron <[email protected]> >> wrote: >> >> > Whether we need issues for PRs is a separate discussion. There has >> to be >> >> > _something_ for every commit - either a PR or an issue, at the least >> >> there >> >> > needs to be an r+ somewhere. I would like to see who reviewed >> something >> >> so I >> >> > can ping someone with questions other than the author (if they are >> >> offline). >> >> > Any discussion is likely to be useful. >> >> > >> >> > So the question is how to find that, when necessary. GitHub sometimes >> >> fails >> >> > to point to the info. And when it does, you do not know if you are >> >> missing >> >> > more info. For the price of 6 characters in the commit message (or >> "no >> >> > issue"), we know with certainty where to find that info and that we >> are >> >> not >> >> > missing other potentially useful info. This would not slow down >> >> development >> >> > in any way. >> >> > >> >> > Note that this is orthogonal to use of version control - you still >> need >> >> to >> >> > know Git in order to get the commit message - it is about how one >> can go >> >> > easily from a commit message to meta-data about a commit. >> >> > >> >> > >> >> > On Tue, Feb 18, 2014 at 12:53 PM, Kevin Ballard <[email protected]> >> wrote: >> >> >> >> >> >> This is not going to work in the slightest. >> >> >> >> >> >> Most PRs don't have an associated issue. The pull request is the >> issue. >> >> >> And that's perfectly fine. There's no need to file an issue separate >> >> from >> >> >> the PR itself. Requiring a referenced issue for every single commit >> >> would be >> >> >> extremely cumbersome, serve no real purpose aside from aiding an >> >> >> unwillingness to learn how source control works, and would probably >> >> slow >> >> >> down the rate of development of Rust. >> >> >> >> >> >> -Kevin >> >> >> >> >> >> On Feb 17, 2014, at 3:50 PM, Nick Cameron <[email protected]> >> wrote: >> >> >> >> >> >> At worst you could just use the issue number for the PR. But I think >> >> all >> >> >> non-trivial commits _should_ have an issue associated. For really >> tiny >> >> >> commits we could allow "no issue" or '#0' in the message. Just so >> long >> >> as >> >> >> the author is being explicit, I think that is OK. >> >> >> >> >> >> >> >> >> On Tue, Feb 18, 2014 at 12:16 PM, Scott Lawrence <[email protected]> >> >> wrote: >> >> >>> >> >> >>> Maybe I'm misunderstanding? This would require that all commits be >> >> >>> specifically associated with an issue. I don't have actual stats, >> but >> >> >>> briefly skimming recent commits and looking at the issue tracker, a >> >> lot of >> >> >>> commits can't be reasonably associated with an issue. This >> >> requirement would >> >> >>> either force people to create fake issues for each commit, or to >> >> reference >> >> >>> tangentially-related or overly-broad issues in commit messages, >> >> neither of >> >> >>> which is very useful. >> >> >>> >> >> >>> Referencing any conversation that leads to or influences a commit >> is a >> >> >>> good idea, but something this inflexible doesn't seem right. >> >> >>> >> >> >>> My 1.5?. >> >> >>> >> >> >>> >> >> >>> On Tue, 18 Feb 2014, Nick Cameron wrote: >> >> >>> >> >> >>>> How would people feel about a requirement for all commit messages >> to >> >> >>>> have >> >> >>>> an issue number in them? And could we make bors enforce that? >> >> >>>> >> >> >>>> The reason is that GitHub is very bad at being able to trace back >> a >> >> >>>> commit >> >> >>>> to the issue it fixes (sometimes it manages, but not always). Not >> >> being >> >> >>>> able to find the discussion around a commit is extremely annoying. >> >> >>>> >> >> >>>> Cheers, Nick >> >> >>>> >> >> >>> >> >> >>> -- >> >> >>> Scott Lawrence >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> Rust-dev mailing list >> >> >> [email protected] >> >> >> https://mail.mozilla.org/listinfo/rust-dev >> >> >> >> >> >> >> >> > >> >> > >> >> > _______________________________________________ >> >> > Rust-dev mailing list >> >> > [email protected] >> >> > https://mail.mozilla.org/listinfo/rust-dev >> >> > >> >> >> > >> > >> > >> > _______________________________________________ >> > Rust-dev mailing [email protected]:// >> mail.mozilla.org/listinfo/rust-dev >> > >> > >> > >> > _______________________________________________ >> > Rust-dev mailing list >> > [email protected] >> > https://mail.mozilla.org/listinfo/rust-dev >> > >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://mail.mozilla.org/pipermail/rust-dev/attachments/20140218/769ba219/attachment.html >> > >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> Rust-dev mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/rust-dev >> >> >> ------------------------------ >> >> End of Rust-dev Digest, Vol 44, Issue 70 >> **************************************** >> > > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
