[Dev] Acerca de libretools/About libretools

Wed, 19 Sep 2012 21:37:16 -0700 



Attachment:
pgpq8uwhpXI05.pgp

Description: PGP signature


Intenté hacer un buen PKGBUILD para [chiliproject] [] ([el que encontré en AUR] 
[chili aur] apesta).

Libretools _era_ perfecto para esa tarea `aur ruby-rails` pero al parecer `aur` 
intenta usar `vimdiff` y falla sin avisar. ¿No deberían instalarse las 
dependencias automáticamente? ¿o manejar el caso de que no estén instalados?

Creo que __es un problema que modifiquemos los scripts para uso personal cuando 
deberían ser genéricos__.

Además tenemos 3 de 8 puntos en [el test de Joel Spolsky] [Joel test] (4 
preguntas no aplican):

1. Control de versiones.
2. Empaquetado en un paso.
3. Base de datos para errores.

Pero nos falta:

4. Arreglar errores antes de hacer código nuevo.
5. Agenda al día.
6. Especificaciones.
7. Control de calidad.
8. Pruebas de usabilidad.

Yo agregaría:

9. Documentación efectiva y actualizada.

Creo que __es importante hacer algo al respecto porque los scripts se están 
volviendo difíciles de mantener__ (`toru` no funciona, un montón de código 
duplicado...) __y adaptados al estilo de uso de__ unos __pocos__ (¿`vimdiff` 
obligatorio en `aur`?).

No voy a hacerlo inmediatamente, pero empiezo con las especificaciones de 
`fullpkg` y sus pruebas unitarias. A propósito, 
https://bugs.parabolagnulinux.org/ está caído.

---
I tried to do a good PKGBUILD for [chiliproject] [] ([the one on AUR] [chili 
aur] sucks).

Libretools _was_ perfect for that task `aur ruby-rails` but it seems like `aur` 
try to run `vimdiff` and fails without notice. Shouldn't dependencies be 
managed automatically? Or handle the missing program?

I think __modifying scripts for personal use when they should be generic is a 
problem__.

Also, we have 3 from 8 points in [Joel Spolsky's test] [Joel test] (4 questions 
do not apply):

1. Version Control.
2. One step packaging.
3. Bug database.

We are missing:

4. Fixing bugs before writing new code.
5. Up to date schedule.
6. Specs.
7. Quality Assurance.
8. Usability tests.

I would add:

9. Effective and updated Docs.

I think __it's important to do something about it because libretools is getting 
hard to maintain__ (`toru` is broken, a lot of duplicated code...) __and 
adapted to few's personal workflow__ (forced `vimdiff` on `aur`?).

I'm not going to start inmediately, but I'm starting with `fullpkg` specs and 
it's unit tests. BTW, https://bugs.parabolagnulinux.org/ is down.

[chiliproject]: https://www.chiliproject.org/
[chili aur]: https://aur.archlinux.org/packages.php?ID=60338
[joel test]: http://www.joelonsoftware.com/articles/fog0000000043.html











Intenté hacer un buen PKGBUILD para chiliproject (el que encontré en AUR apesta).


Libretools era perfecto para esa tarea aur ruby-rails pero al parecer aur intenta usar vimdiff y falla sin avisar. ¿No deberían instalarse las dependencias automáticamente? ¿o manejar el caso de que no estén instalados?


Creo que es un problema que modifiquemos los scripts para uso personal cuando deberían ser genéricos.


Además tenemos 3 de 8 puntos en el test de Joel Spolsky (4 preguntas no aplican):


    

  1. Control de versiones.
    2. 

  2. Empaquetado en un paso.
    3. 

  3. Base de datos para errores.
    4. 



Pero nos falta:


    

  1. Arreglar errores antes de hacer código nuevo.
    2. 

  2. Agenda al día.
    3. 

  3. Especificaciones.
    4. 

  4. Control de calidad.
    5. 

  5. Pruebas de usabilidad.
    6. 



Yo agregaría:


    

  1. Documentación efectiva y actualizada.
    2. 



Creo que es importante hacer algo al respecto porque los scripts se están volviendo difíciles de mantener (toru no funciona, un montón de código duplicado...) y adaptados al estilo de uso de unos pocos (¿vimdiff obligatorio en aur?).


No voy a hacerlo inmediatamente, pero empiezo con las especificaciones de fullpkg y sus pruebas unitarias. A propósito, https://bugs.parabolagnulinux.org/ está caído.




I tried to do a good PKGBUILD for chiliproject (the one on AUR sucks).


Libretools was perfect for that task aur ruby-rails but it seems like aur try to run vimdiff and fails without notice. Shouldn't dependencies be managed automatically? Or handle the missing program?


I think modifying scripts for personal use when they should be generic is a problem.


Also, we have 3 from 8 points in Joel Spolsky's test (4 questions do not apply):


    

  1. Version Control.
    2. 

  2. One step packaging.
    3. 

  3. Bug database.
    4. 



We are missing:


    

  1. Fixing bugs before writing new code.
    2. 

  2. Up to date schedule.
    3. 

  3. Specs.
    4. 

  4. Quality Assurance.
    5. 

  5. Usability tests.
    6. 



I would add:


    

  1. Effective and updated Docs.
    2. 



I think it's important to do something about it because libretools is getting hard to maintain (toru is broken, a lot of duplicated code...) and adapted to few's personal workflow (forced vimdiff on aur?).


I'm not going to start inmediately, but I'm starting with fullpkg specs and it's unit tests. BTW, https://bugs.parabolagnulinux.org/ is down.




_______________________________________________
Dev mailing list
[email protected]
https://lists.parabolagnulinux.org/mailman/listinfo/dev






















					Reply via email to