I am wondering what is the status of #5481 . Although the target version
is
3.0, there is some ongoing effort such as #6875 and [1]. So will the
StdLib
be gemified or not? If yes, will it be done properly, i.e. all the
bundled
libraries such as Rake, Minitest, RDoc, Psych becomes real gems, since
the
current status is suboptimal #6124
Vit
[1] Support normal gem require without explicit 'gem "name"' for default gem by kou · Pull Request #377 · rubygems/rubygems · GitHub
2012/10/24 Yusuke E. [email protected]
Hello,
2012/10/25, Vit O. [email protected]:
I am wondering what is the status of #5481 . Although the target version is
3.0, there is some ongoing effort such as #6875 and [1]. So will the StdLib
be gemified or not?
The short answer is “no.”
We discussed #5481 at the developers’ meeting (Jul. 21), and
it was not accepted. I’ll add the brief log to that ticket.
Hello Marco,
2012/10/25, Marco C. [email protected]:
Does that apply to the stdlib too?
Yes, in principle.
What about the proposal to gemify the stdlib?
See my reply in #5481 and wait for NaHi.
I’ve raised the following feature request quite some time ago
Feature #4569: Replace IPAddr with IPAddress - Ruby master - Ruby Issue Tracking System
but nothing has been done so far, I haven’t received any feedback, and
now this 2.0 feature freeze announcement comes out of the blue (for me
at least).
Sorry, but please do NOT assume that you can get a feedback
just by opening a feature request ticket.
All feature proposers are supposed to make an effort to get
related committers’ interest and matz’s approval.
You can exploit the opportunity such as [ruby-core:45474].
It is also a very good idea to appeal to matz face-to-face,
e.g., at some conferences.
(Note that this does not apply to bug report ticket. The
committers must check and fix them.)
In short, you don’t have to hesitate, or even you are
encouraged to open any feature request ticket, but it is
often insufficient.
2012/10/24 Yusuke E. [email protected]:
Hi all –
Today, I’d like to declare “feature freeze” according to the schedule [1].
2.0.0 will NOT include any feature that is not accepted yet by matz at
this time.
[1] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/40301
Sorry for no prior announce of this. If you, especially committers, have
any significant problem, please let me know by next Sunday.
Hello Yusuke
Does that apply to the stdlib too? Or is it just for the core? What
about the proposal to gemify the stdlib?
I’ve raised the following feature request quite some time ago
but nothing has been done so far, I haven’t received any feedback, and
now this 2.0 feature freeze announcement comes out of the blue (for me
at least).
On Thu, Oct 25, 2012 at 2:14 PM, Yusuke E. [email protected] wrote:
but nothing has been done so far, I haven’t received any feedback, and
now this 2.0 feature freeze announcement comes out of the blue (for me
at least).
Sorry, but please do NOT assume that you can get a feedback
just by opening a feature request ticket.
All feature proposers are supposed to make an effort to get
related committers’ interest and matz’s approval.
Thanks for your answer and your advices Yusuke.
I have written to mr. Knu (maintainer of IPAddr) multiple times, I
have interacted with Matz which was positive about the idea, I have
opened the ticket and even asked what I could do to help.
Next step was to be reported for stalking, but I have a family to take
care of and they don’t let me code from prison 
It is also a very good idea to appeal to matz face-to-face,
e.g., at some conferences.
I’ve tried with a horse head in the bed, didn’t work.
In short, you don’t have to hesitate, or even you are
encouraged to open any feature request ticket, but it is
often insufficient.
Got the message. I’ll have to improve my determination from this point
of view. Thanks again for your adivces.
Now, my 2 cents: IPAddr should not be part of Ruby 2.0. It is too
outdated and too strangely behaving to be the default IP addresses
management library for a mainstream language such as Ruby. I know Ruby
doesn’t exactly target to networking, but If you don’t plan to replace
it with some other library (there are many) at least consider to just
not include it.
Hi,
I checked all “not closed” features.
and I send notice with
- add comment (ping) on redmine
- assign to mame-san on redmine the ticket which I can’t judge
- change target to next minor when it seems no discussion on it
- twitter to people who check twitter frequently
- skype to nobu
- IRC to nurse-san
- mail (akr-san and matz)
Please correct me if my changes are not correct.
Note that ~assigned to Matz" is almost equivalent to “ignored”.
I think you need to make pressure to Matz (with good explanation, good
usecase, etc).
Thanks,
Koichi
I found that there are 183 not-closed features which are not specified
target version…
I didn’t check it. Please set target version if you strongly believe it
should be introduce into 2.0.
Thanks,
Koichi
Hi,
In cgi.rb,
I think HTML5 tag generater will be include in 2.0
I will commit to update include this ticket while few days.
Hello,
2012年10月24日 20:39 Yusuke E. [email protected]:
Let me know any feature that is already
accepted by matz but not implemented yet.
As far as I’m concerned, these two tickets match the condition.
- Feature #6670: str.chars.last should be possible
- Feature #3346: DIR revisted
(2012/10/24 5:39), Yusuke E. wrote:
Sorry for no prior announce of this. If you, especially committers, have
any significant problem, please let me know by next Sunday.
I will consider/chanabout the following 10 tickets.
Sorry for my late response.
Hello ko1,
2012/11/1 SASADA Koichi [email protected]:
(2012/10/24 5:39), Yusuke E. wrote:
Sorry for no prior announce of this. If you, especially committers, have
any significant problem, please let me know by next Sunday.
I will consider/chanabout the following 10 tickets.
Thank you.
-
I think that #6895, #7051, and #6762 are too heavy to include in 2.0.
I’m reluctant.
-
Did matz accepted the parameter setting features by environment
variables
(#4614 and #3187)?
-
Matz looks negative to #6710.
-
Adding only a document is okay. (#3731)
-
#1586 is already accepted.
-
#2294 and #1952 looks okay, but please hurry to implement.
If they prevent the release engineering, I will defer them to next
minor.
I recognize #3731, #1586, #2294 and #1952 are accepted but unimplemented
2.0 features.
AFAIK matz has not accepted #6636 completely yet.
2012/11/2 Marc-Andre L. [email protected]:
Sorry, late to the party, but what’s the status of #6679?
2012/11/3 [email protected]:
What status of #6638
Up to nobu.
But my personal opinion is that it may be difficult to include that in
2.0.0. Sorry.
2012/11/3 Clay T. [email protected]:
Sorry, late to the party, but what’s the status of #6679?
#6679 is already accepted, and is on the waiting for Naruse’s
implementation.
But if it is implemented by code freeze at the latest, I must postpone
that to Next Major.
2012/11/3 Юрий Соколов [email protected]:
What status of #6638
Up to nobu.
But my personal opinion is that it may be difficult to include that in
2.0.0. Sorry.
Endoh-san, why (specifically) do you believe the patch would be
difficult to include in 2.0.0?
I assume you’re OK with patch application mechanics, but have concerns
about something else?
Jon
Just because it is technically advanced and not well-tested yet.
It often makes debugging hard for us to complicate basic data invariant.
But I’m not against if nobu applies the patch and if it causes no problem.
So press him to review and commit the patch.
Understood. I just posted successful make test
and make test-all
results on trunk@37463 using win7 32bit and mingw-w64 gcc 4.7.2 and will
try on my arch 3.6.5 vm w/4.7.2 when I see an updated trunk pushed to
the github mirror. And if I’m feeling particularly flush with free time
I may try it on my snow leopard vm.
nobu-san…any specific concerns or additional tests you’d like to see
that are not already covered by trunk’s test suite?
Jon
Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http://thecodeshop.github.com | http://jonforums.github.com/
twitter: @jonforums
2012/11/4 Jon [email protected]:
2012/11/3 [email protected]:
What status of #6638
Up to nobu.
But my personal opinion is that it may be difficult to include that in
2.0.0. Sorry.
Endoh-san, why (specifically) do you believe the patch would be difficult to
include in 2.0.0?
Just because it is technically advanced and not well-tested yet.
It often makes debugging hard for us to complicate basic data invariant.
But I’m not against if nobu applies the patch and if it causes no
problem.
So press him to review and commit the patch.