Anterior: How-To Subir: Tabla de Contenido Siguiente: Como escribir una especificación en Ruby

Como - Escribir un ticket

El issue tracker de Rubinius es http://github.com/rubinius/rubinius/issues.

Para ser útiles, los tickets deben ser concisos, específicos y acciones concretas. Si no, el ticket va a languidecer y convertirce en desorden. En consecuencia, los tickets deben caer en una (o más) de las siguientes categorías:

  1. . Una historia precisa de la línea de comandos para demostrar cómo instalar e invocar el programa y que muestra el backtrace de una excepción.
  2. . Un pequeño fragmento de código que ilustra el problema y la línea de comandos que lo invoca.
  3. . Un parche, incluyendo specs, si no existen, y mostrando la spec funcionando antes y después de aplicar el parche.

Si el problema no se ajusta a una de las categorías, no es válido. Simplemente no es apropiado para un ticket.

  1. . Si se trata de una característica, considere discutirla en la lista de correo. Además, podría intentar implementarla y demostrar cómo su característica es útil.
  2. . Si se trata de una biblioteca o gema que no está funcionando, tómese un tiempo para investigar y ver si se puede reproducir y envíe eso como ticket.

Procedimiento general para enviar un ticket

  1. Verifique dos veces.

    1. . Hacer una reconstrucción completa ('rake clean; rake') después de un 'git pull' o un clone fresco.
    2. . Leer Troubleshooting ver si algo resuelve el problema.
    3. . Leer Specs.

    4. Dé a su ticket un título específico, preferentemente corto.

    5. Etiquete correctamente su ticket.

    6. Dar suficientes detalles sobre el tema.

      • La línea de comandos para invocar el programa
      • El backtrace o resultado del programa en comparación con resultado esperado.
      • La información de su máquina. uname -a está generalmente bien (si hay algun "unkown" en cualquiera de los campos, por favor, dar más detalles sobre ellos.)

Instrucciones adicionales para tickets con parches

A menos que por alguna razón sea imposible, por favor use git-format-patch para crear el patchset. Es mucho más fácil de aplicar y conserva la atribución correcta. De lo contrario, un diff unificado.

Ejemplo de la presentación de un parche

Supongamos que la siguiente spec existe y está fallando:

describe "Kernel.format" do
  it "is accessible as a module function" do
    Kernel.format("%s", "hello").should == "hello"
  end
end
  1. Título del ticket:

    "[PATCH] No method 'format' on Kernel (Module)"

  2. Tags:

    "patch core spec"

  3. Mensaje del ticket:

    The method 'format' is not available as a module function of Kernel.

    $ bin/mspec spec/ruby/core/kernel/format_spec.rb
    Started
    .E
    
    1)
    Kernel.format is accessible as a module function ERROR
    No method 'format' on Kernel (Module):
    

    The method 'format' already exists but has not been set as a module function. This patch does so.

    After the patch is applied:

    $ bin/mspec spec/ruby/core/kernel/format_spec.rb
    Started
    ..
    
    Finished in 0.016031 seconds
    
    2 examples, 2 expectations, 0 failures, 0 errors
    
  4. Attachment:

Por último, ponga el parche en un gist y agregue el enlace al gist de su issue. A continuación se reproduce el parche en una línea por una cuestión de integridad:

From c61cecce6442347ebbdf1ded7a5c0832c97582c1 Mon Sep 17 00:00:00 2001
From: Brian Ford <bford@engineyard.com>
Date: Sat, 19 Jan 2008 17:48:19 -0800
Subject: [PATCH] Set Kernel#format as a module function.


diff --git a/kernel/core/kernel.rb b/kernel/core/kernel.rb
index 2d2e508..f2a382e 100644
--- a/kernel/core/kernel.rb
+++ b/kernel/core/kernel.rb
@@ -150,6 +150,7 @@ module Kernel
   end
   alias_method :format, :sprintf
   module_function :sprintf
+  module_function :format
   module_function :abort

   def puts(*a)
Anterior: How-To Subir: Tabla de Contenido Siguiente: Como escribir una especificación en Ruby

Tweet at @rubinius on Twitter or email community@rubini.us. Please report Rubinius issues to our issue tracker.