Eric Pugh wrote:
I think it comes down to maintence. If projects have active committers who are trying to fix them when they break, then great, lets keep them. Regardless of where they come from. But, if projects are in the system that don't have active committers trying to fix them/deal with the issues, then lets remove them.
Agreed.
I wish that we tracked who the "goto" person was versus just mailing list for various projects. Maybe set up a more flexible approach like 'after 10 failures' we contact the goto person to remind them. After '30 failures' then we remove any leaf projects.
I completely agree on the fact that pointing a problem to a single person is way more efficient. There is a way to understand who break what, but it's not easy to implement efficiently since it requires gump to know what "versions" of the dependencies projects depend on.
Part of the complexity of Gump is that so many things can go wrong. And when things start going wrong, the rate really speeds up and then everything goes wrong. And fixing it can seem like a mountain to climb.
That's why it took 3 years and several burned-out people to reach 85%.
To help with the number of projects, have we thought about more aggressive
use of installed packages?
Yes, and the number of packages we have already worries me. In the future my goal is exactly the opposite: remove as many packages as we can.
I know that goes against the current spirit of
gump. But really, I don't care about the OpenSymphony dependencies I am
using, I just want my ASF projects that depend on OpenSymphony code to build
under gump!
This is why we need explicit versioned dependencies (maven pom provides that already) so that we can be *both* a build system *and* a continous integration system.
Maybe someday, when everything is rocksolid, then I'll start paring out the number of packages that I am using. Related to this, I am starting to think about dependencies not just in a "is it a good dependency to have" but in a "what challenges will having this dependency give me in Gump land", which isn't a great thing...
I think this is just awesome: the day a FOG is considered a "dependency" risk by people downstream is the day gump starts to make sense.
Eric, solving the pain right now might just increase it later on.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
