[Rubygems-developers] Rubygems Packaging Enhancements and Designs

James Tucker jftucker at gmail.com
Thu Mar 25 10:49:47 EDT 2010


Hi all,

So after another hairy discussion on various lists, IRC channels and what not, I'm getting the urge to try and fix this for reals this time around. In an effort to do this, I'm dropping the ever so popular agile approach. This is a platform heavy issue, so I need better specs about platform specific requirements. That requires input from you guys, and from anyone else in a similar position. Spec collection is to happen on this wiki page, and I've started a small template of the discussion already. My lunch hour is coming to an end though, so there's plenty more to be added. Please add your opinions, requirements, design level bugs and so on, and I'll do what I can to distill this all down into a set of requirements that I can produce patches against.

http://wiki.github.com/jbarnette/rubygems/packaging-designs

As a sort of aside, I'm doing this to fix these problems as best as possible, and as such, I'm simply going to ignore any flame war that starts. The only way to move forward is to understand, and that's my intention, so please, I implore you all, explain your position clearly, rather than making demands, and whatever history you have is unimportant now, we're moving forward.

If you know other maintainers that were not included in this email, please do forward this on to them, I need as much info as possible about what peoples requirements are in order to satisfy as many of them as possible in as few patches as possible.

The final stages of this process should result in:

* Fresh documentation for teams packaging rubygems and gems inside other package managers
* A set of platform test infrastructure wired to build / commit / gem push hooks allowing us to be more proactive about these issues in future (the SUSE team have some great tools here, and a lot of domain knowledge already)
* An agreeable attitude and platform for open discussion of these issues

A quick word of warning about expectations. I'm not looking to move really fast on this. We need to get it right, and we need to avoid adding bugs as we do it, that's going to require /real/ and /extensive/ manual testing and a mature approach. Expecting fixes next month is not the intention here. What I do expect is that we can have standard ways to get this stuff off the ground, and reduce support requests for all related projects, with releases in most of your platforms hopefully by next year.

Please, "help us to help you",

Cheers,

James


More information about the Rubygems-developers mailing list