<zzak>
drbrain: what do you think about backporting docs?
<drbrain>
zzak: I don't see the harm in it, I have never had the time, though
<zzak>
maybe after release we can do like a bulk diff for some of the obvious fixes and submit one request
<zzak>
its a pain to do it per patch
<kosaki2_>
zzak: pong
<zzak>
kosaki2_: ohayou!
<zzak>
kosaki2_: which bostonrb are you attending?
<kosaki2_>
ohayou mean "good morning". It is not morning in EST.
<mame0>
indeed I admit that the current backport policy is arguable
<zzak>
haha
<kosaki2_>
I plan to attend at March 12.
<zzak>
kosaki2_: that's right you are not jst
<mame0>
but in the case, please discuss the rule first
marcandr_ has joined #ruby-core
<mame0>
do not force your commit before discussing and changing the rule
marcandr_ has quit [Remote host closed the connection]
<zzak>
ofcourse
<zzak>
kosaki2_: ok! i wanted to register before it was sold out
<kosaki2_>
Guys, mame-san is rare resource. Release manager is a sing point of failure of us. Please respect him.
<marcandre>
mame0: Are you talking to me?
<mame0>
you and nobu
<mame0>
i warned nobu yesterday
<kosaki2_>
s/sing/single/
nari has quit [Ping timeout: 246 seconds]
<marcandre>
mame0: I would appreciate if you avoid using all caps. I find it offensive, and many others on the net do.
<marcandre>
Also, it was discussed before. For example, [ruby-core:43301]
<marcandre>
Please correct my understanding that the only problem a rdoc backport can create is not increasing the patch version, and that's only in case there is a patch version out there.
<mame0>
sorry, i used all caps just to emphasize, not to be offensive
<mame0>
it is a matter of my English.
<marcandre>
Also, I recommend that unless it is very clear who you are responding to, that you include nick. This also brings attention because I don't always look at irc.
<marcandre>
So, is my understanding correct?
<mame0>
no, increasing a patch version is not needed before p0
drbrain has quit [Quit: Goodbye]
<mame0>
Did you see [ruby-core:52034] ?
<mame0>
I said: Please get my "ack" before you commit anything to that branch.
<kosaki2_>
[ruby-core:43301] is discussion under 1.9.3. Every release and Every release manager may have a slightly different policy.
<mame0>
what I want to say is to obey this rule
<mame0>
if you are against this rule, please discuss it first, before forcing your commit
drbrain has joined #ruby-core
<kosaki2_>
each release manager have a right and responsibility to make their own branches/release's policy.
<mame0>
changing rdoc is almost benign, but not alyways, I think
<marcandre>
So you are saying that you do not trust other committers to change rdoc and want approval before we do so?
<kosaki2_>
because, again, release manager is most busy and spof. their thinking should have high priority.
<mame0>
I wanted to apply software review for backport
<zzak>
if you want my idea
<zzak>
i think a documentation backport manager would be good
ryanf has joined #ruby-core
<zzak>
maybe supply backport commits to a separate fork
<zzak>
and then documentation manager will merge these commits at once to backport
<zzak>
only documentation related
<zzak>
this way documentation manager can review all backport docs, before release manager can review them in bulk
<zzak>
less commit noise == easier to review i think
<kosaki2_>
Sound good. however, i believe policy should be discussed on ruby-core. otherwise other committer will get a strong frustrations.
<banister`tyrion>
kosaki2_: how do i get ops here
<marcandre>
Sorry, I'm trying to collect my thoughts, I'm not sure how to express what I feel.
<kosaki2_>
banister`tyrion: I don't know. And I don't know who know.
<zzak>
kosaki2_: agree, my idea is rough but it should be well thought out and proposed to redmine
<drbrain>
banister`tyrion: it seems like only committers should have ops
<zzak>
mame0: when will nagachika take over after p0?
<mame0>
yes
<banister`tyrion>
drbrain: you're right, i also want it for the wrong reasons
<zzak>
you mean the topic?
<mame0>
the current policy before p0 is mine, and the next policy after p0 is nagachika's
<mame0>
nagachika stated his policy
<mame0>
[ruby-core:52534]
<zzak>
i just emailed shyouhei re: the channel topic
<marcandre>
[ruby-core:52534] makes no mention of rdoc only commits
<mame0>
zzak: btw, is there no reference showing the doc improvement?
<marcandre>
I feel that enforcing a code freeze policy for rdoc-only commits is either paranoia or a power-trip. The worst that could happen is that the documentation is worse then before. I seriously doubt this would happen, and if it did noone would be greatly impacted. If a Ruby committer is confident enough about a rdoc change, and willing to spend his free time backporting that change like I did today, I can only see upside.
<marcandre>
I don't care to "obey the rules". Rules must have valid reasons to exist, and this one does not. If other maintainers could live without it, so can you.
<mame0>
ri ruby: shows just a file list
<zzak>
mame0: for doc improvement, i mentioned drbrain's syntax guides in our email
<zzak>
mame0: ri ruby: lists all of the guides, like syntax/*
<mame0>
marcandre: sorry, now let me focus the immediate release
<zzak>
mame0: for example ri ruby:syntax/methods
<mame0>
sorry for harm your feelings
<mame0>
note that i'll leave your commits in ruby_2_0_0
<mame0>
zzak: i want the evidence of "We have added a huge amount of rdoc for modules and methods."
<zzak>
hmm
<mame0>
drbrain's syntax documents are indeed worh mentioning
<zzak>
mame0: do you know about the rdoc coverage report?
<mame0>
ah, it sounds good
<zzak>
1.9.3 was about 60% documented
<zzak>
2.0.0 will be around 75%
<mame0>
great!
<zzak>
'rdoc -C $srcdir
<drbrain>
zzak: 1.9.3 today is 66, 2.0.0 today is 76
<zzak>
mame0: ^
<mame0>
is the unit a file?
<drbrain>
comment, method, class, module or attribute
<drbrain>
some of these Array#sample specs look like they should fail on 1.9.3 too
<drbrain>
it doesn't call Kernel#rand by default
<marcandre>
I'm confused, I thought we were running rubyspecs?
<drbrain>
the other night _ko1 saw a bunch of these in the ci system
<drbrain>
but it was many, many commits that appeared suddenly
<drbrain>
so maybe it's a CI bug
<zzak>
mame0: sent
<mame0>
many! :-)
<marcandre>
coz these are clearly old failure. For example the fact that remove_instance_variable is no longer private
<zzak>
those are the major recent doc patches i'd like in 2.0
<ryanf>
I think brixen might have said he undisabled some specs for mri that were previously disabled
<ryanf>
the tweet that linked that gist was "The MSpec ruby_bug guard is disabled on master and gone in 2.0.0. These are possible unaddressed bugs in MRI 2.0"
<drbrain>
ryanf: so he didn't check if they were valid first?
<ryanf>
I have absolutely no idea
<drbrain>
because Proc#inspect has never returned file and line numbers in 1.9+
<ryanf>
that just seemed like relevant information
<ryanf>
huh, interesting
<drbrain>
ryanf: well, for that spec in particular
<zzak>
mame0: if you want i can add link to patch in description
<mame0>
some sentences looks deleted, but actually they are just moved?
<zzak>
moved and reformatted
<mame0>
okay i trust you
<zzak>
for pty, i moved the small example to show ::open with block
<zzak>
oh, for pty i also deleted getpty from call-seq
<zzak>
it's listed as an alias so i thought that was enough
<zzak>
i didnt like having so many duplicate call-seq's
<zzak>
that is for ::spawn
dorei has quit []
<zzak>
mame0: please give me some time to commit these
takeru has quit [Remote host closed the connection]
<marcandre>
I'm exhausted. I'm going to bed. For the Rubyspecs: #15 can be fixed but is really not important. I started checking the Random stuff and got caught up in a bug.
<marcandre>
What's the difference between 2.1.0, next minor and next major as targets on redmine??
kosaki2_ has quit [Remote host closed the connection]
<zzak>
mame0: ^
<zzak>
good question
<zzak>
wondering that myself, and i missed the implementers meeting
<mame0>
pong
<mame0>
i think there is no agreed criterion for them
<marcandre>
Ok, let me rephrase this, since I really want to go to bed. Which one is for sure the next release?
<marcandre>
Unless I'm too tired, it means the custom random generator will have to be broken again. Since there's already a note about incompatibility in the NEWS, we probably should note that it's also buggy.
* marcandre
rumbles about committers writing clearly incomplete and imprecise tests and resisting to their death writing RubySpec style with complete test of inputs and outputs
<marcandre>
actually, there are tests for this.
<marcandre>
I can't see clearly. Can't even find where this feature change was discussed.
marcandre has quit [Remote host closed the connection]
<znz_v>
biff: [ruby-changes:27404] zzak:r39456 (ruby_2_0_0): * object.c: Document Data class by Matthew Mongeau [Backport #7929] - http://mla.n-z.jp/?ruby-changes=27404
<znz_v>
biff: [ruby-changes:27405] zzak:r39457 (ruby_2_0_0): * ext/pty/pty.c: Documentation for the PTY module [Backport #7928] - http://mla.n-z.jp/?ruby-changes=27405
<znz_v>
biff: [ruby-changes:27406] zzak:r39458 (ruby_2_0_0): * lib/abbrev.rb: Add words parameter to Abbrev::abbrev - http://mla.n-z.jp/?ruby-changes=27406
<_ko1>
> Eagle Talon (秘密結社 鷹の爪 Himitsu Kessha Taka no Tsume?, lit. Secret Society Eagle Talon) is a Japanese Flash animation created by Shimane Prefecture resident Ryo Ono (FROGMAN) and produced by DLE.[1]
<_ko1>
in Shimane Matz's living.
<_ko1>
and Shimane goverment want to promote Shimane itself with Ruby and Yoshida-kun.
<_ko1>
s/goverment/prefecture/
<marcandre>
Can we bump the version in trunk, now that 2.0.0 is out?
<marcandre>
^Can^Shouldn't
<_ko1>
We asked matz to update version.h
<_ko1>
but he ignore now...
<_ko1>
last saturday, we discussed about next version
<_ko1>
(1) basically, we will release 2.1.0
<_ko1>
(2) if some big changes including spec should be change, we will release 2.0.1
<_ko1>
(3) if some security fix, then release 2.0.0pXXX
<_ko1>
(1) and (2) is ambiguous.
<_ko1>
but we will make schedule for (1).
schaerli has joined #ruby-core
<_ko1>
one idea is relese 2.1.0 at X'mas 2013 (not 2014)
<_ko1>
this is why we don't need 2.0.1
<_ko1>
(only shoter than one year)
<_ko1>
but we need more discussion about it.
<_ko1>
make sense?
schaerli has quit [Remote host closed the connection]
<_ko1>
maybe mame-san propose this idea.
<marcandre>
Sure. I don't have opinion on 2.0.1 or 2.1.0, but 2.0.0 seems confusing, since there's a branch for this!
<marcandre>
Can we change to 2.0.1 and this can later be changed to 2.1.0 if desired? Just so version != 2.0.0
<_ko1>
i agree it is confusing
<marcandre>
We agree that if security release 2.0.0pXXX, it will be from 2.0.0 branch, right?
<_ko1>
marcandre: what is your twitter id?
<marcandre>
or bug fix release :-)
<marcandre>
@malafortune
<_ko1>
I can't guess it :)
<_ko1>
i mention to matz
<marcandre>
I know :-(
<marcandre>
Mention what to Matz?
<_ko1>
modify version.h is festival. so it should be matz's task
<_ko1>
i beleve
<_ko1>
believe
<marcandre>
Ah, I understand. There's like a zillion +1 on github.
<marcandre>
Can I move the NEWS file over, at least?
<_ko1>
ask mame-san :)
<_ko1>
or should we move NEWS file to Wiki?
<marcandre>
I like to be able to do `git log -p NEWS`
<_ko1>
ah.
<marcandre>
Much nicer than wiki history...
<_ko1>
i don't have any idea about it :)
kosaki8 has quit [Ping timeout: 260 seconds]
takeru has joined #ruby-core
takeru has quit [Ping timeout: 276 seconds]
charliesome has joined #ruby-core
kosaki8 has joined #ruby-core
xibbar has joined #ruby-core
<lopex>
rb_obj_id doc/info doesnt take into account Flonum mask
<lopex>
in gc.c
<lopex>
it should be updated right ?
<zzak>
_ko1: ping
<_ko1>
pong
<zzak>
any idea on lopex question?
<zzak>
rb_obj_id says it returns a Fixnum
<lopex>
I mean the scheme
<_ko1>
rb_obj_id returns Integer now
<_ko1>
(maybe...)
<lopex>
the new bits scheme thats' described in include/ruby/ruby.h
<lopex>
wrt USE_FLONUM
<zzak>
you mean 32-bit VALUE space and object_id space
<zzak>
i'm not sure, koichi-san can you comment?
<lopex>
I mean the scheme described in ruby.h doesnt match the one described in gc.c
<lopex>
now
<_ko1>
lopex: I see.
<lopex>
someone might get confused
<_ko1>
You mean only comments
<_ko1>
not a rdoc
<lopex>
yep
<_ko1>
it is old.
<lopex>
yeah
<_ko1>
lopex: i agree it should be fixed
<_ko1>
ah,
<lopex>
_ko1: I know it's a trivial thing to bother with
nari has joined #ruby-core
<lopex>
but I'm used to be a heavy ruby source reader
<zzak>
lopex: its a good catch!
<zzak>
people do read the source
<zzak>
did you know there are also doxygen comments on some of mri?
<lopex>
zzak: I mostly used to read the function bodies when implementing things in jruby
<_ko1>
maybe 32bit CPU, it is not old.
<_ko1>
only 64bit, it is old.
<lopex>
oh you mean the /*! ?
<lopex>
_ko1: yeah, the flonum is never used on 32 bit right ?
<_ko1>
yes
<_ko1>
double (64bit) can't insert 32bit VALUE
<lopex>
_ko1: you check the mantissa whether it fits right ?