Code Reviews - aka "oh god... he's at it again..."

Nick Quaranto nick at
Mon Nov 28 18:41:54 EST 2011

May I suggest we do this in a branch instead of master? Just in case we
need to cut a new release and we can go bananas in a separate branch and
merge it in once we're happy.

On Mon, Nov 28, 2011 at 5:56 PM, Ryan Davis <ryand-ruby at>wrote:

> I'd like to get rubygems moving again.
> Specifically, rubygems codebase is a crufty mess and we need to fix it.
> First, we need to know what to fix. I'd like to see us do a full set of
> code reviews across the entire codebase with comment tags put in where the
> pain points are (detailed below). That way we can prioritize our pain and
> start to address it.
> This effort is intended to go towards a 2.0 release, NOT a 1.x release. It
> is meant to rejuvenate the codebase and get us pointed in the right
> direction.
> We've got 95 files in lib with ~20k lines in them. Every file should have
> at least one set of eyeballs on every line them with certain files having
> MANY sets of eyeballs on them. We've got 94 files in test with ~17k lines
> in them. They're just as important (if not more) as the files in lib.
> I'd like to get people to step up and schedule code reviews over the next
> 2-4 weeks. Who's in? Let me know here that you're interested and how much
> you think you'd like to do.
> ## Tagging:
> Nothing complex... I standardize on the following (examples):
> # FIX: xxx is wrong
> # HACK: should have done xxx instead
> # TODO: xxx needs yyy
> # DOC
> # REFACTOR: duplicated from xxx
> # RETIRE: replaced by xxx
> # WARN: xxx is scary
> I have a script that shows all of these in a clean way. Here is the
> summary of specification.rb:
> Occurances:
>  32: TODO
>   2: FIX
>   1: HACK
> So you can use that as the basic idea that I'm going for.
> _______________________________________________
> RubyGems-Developers mailing list
> RubyGems-Developers at

More information about the RubyGems-Developers mailing list