[ruby-core:17349] Re: A plea for a release process

Hello,

On Jun 18, 8:16=A0pm, Urabe Shyouhei <[e-mail]> wrote:
> I think I was called :)

Thank you for the input. :)

>
> The reasons why I committed so much was:
>
> 1) I wanted to fix as much bugs in 1.8.5 as possible, before it expires.
>
> 2) Sadly I was busy for a while so there were many bugs stacked, and at
> last I got time to touch them in 3 June. =A0This was my fault. =A0I shoul=
d
> have done this more frequently, little by little.
>
> Brian Ford wrote:
> > So, I'd like to suggest that the community and the MatzRuby core
> > developers come to some agreement on a process for MatzRuby releases.
> > Here are several features I hope the process will include:
>
> > 1. Security fixes should be highest priority. A patchlevel across
> > versions that incorporates security fixes should be released as soon
> > as possible. It would be great to have the issues communicated to key
> > folks across all alternative implementations, but that might not be
> > possible in every situation.
>
> They are already. =A0But please also note that we are not always possible
> to disclose then immediately. =A0Security incidents are treated based on
> international concord; =A0not fully controlled by us.
>
> > 2. A regular schedule of patchlevel releases on some reasonable
> > timetable (one month, two months?). For each of these scheduled
> > releases:
>
> Maybe I've not said this? =A0Patchlevel "releases" (apart from those tags=
)
> are released every 3 months normally in Mar, Jun, Sep, Dec, except for
> security fixes of course. We did not released 1.8 patchlevels on last
> Dec because we released 1.9.0 instead.
>
> > 2.a. A wiki page on the new Redmine tracker that lists the features to
> > be rolled in from the particular version's development branch.
>
> We should have this. =A0I'm currently managing that kind of list by hand
> (accessible viahttp://coderepos.org/share/browser/docs/shyouhei/ruby%20de=
velopment/r...).

Ah, the release schedule is good to know. I'm sure some of the
concerns here will be addressed by having a single good source of
information about the process for all the non-Japanese speakers.
Having this wiki page would be awesome.

>
> > 2.b. An opportunity for folks to run the specs against these proposed
> > changes to catch errors before the release is done.
> > 2.c. Along with 2.b. this would give alternative implementations an
> > opportunity to plan to release the same fixes/features with the
> > corresponding RUBY_VERSION and RUBY_PATCHLEVEL synchronized to match
> > the MatzRuby releases at a time closer to when the MatzRuby releases
> > occur.
>
> That is a nice idea.
>
> > 2.d. An opportunity for the community to then be aware of what is
> > planned to be released and comment on it so that we don't have
> > situations like what recently happened here (http://groups.google.com/
> > group/ruby-core-google/browse_thread/thread/1b116e4bbaeca3d2).
>
> What recently happened there was actually "the community to be aware of
> what is planned to be released." =A0No?

Yes, I think this situation worked out well. My concern is that we
continue to catch these issues before releases. Which means figuring
out how to run the RubySpecs against the development branch "head" for
each version

1) without causing a lot of churn in the specs (i.e. a bunch of specs
had to be modified to not fail after the convert_type change), and
2) without causing confusion from failing specs for issues that have
been fixed.

In the first case, I think we should only add ruby_bug guards for
failures in a released patchlevel of a particular version, but never
for issues that exist in the development branch for that version. Does
that sound reasonable?

In the second case, if we only add ruby_bug guards for released
versions, then any specs that fail in the development branch might be
bugs? In that case, we should file tickets on the new tracker? Will
this lead to a lot of work for everyone? Or is there a better way to
recommend that we handle this?

Thanks,
Brian