> 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
