On Mon, Jul 20, 2009 at 10:06 AM, Rickard Öberg<[email protected]> wrote:
> There are a couple of issues that comes to mind. One is nightmares from my > time working with ClearCase, where all work had to be done in branches. One > week work, one week merging, was the norm. Absolutely horrible. YES, I have been there, done that... UCM I think it was called... No, I don't want to get to such position at all. > Also, for > the time being I am relying on being able to do fixes in Qi4j quickly > whenever problems arise in the StreamFlow project. Having more overhead to > do that is not helpful. Agree completely, but I don't think I see much of an issue here either. I think the underlying idea is quite the opposite, that individuals can do such quick turn-around, even if others (or main project) need to move less quickly, and pick up those changes at their convenience. > To turn it around: what are the advantages of working in the outlined way? > What's the big gain by it? The "big" gain for *me* is to not having to host it at all. Right now, we have a set up that only I know how it works, and I am not keen on trying to add support for people with Firewall issues (http protocol). The overall ideas is that anyone could contribute to Core without us opening it up. An individual only need to point us (e.g. email) to a a set of changes and it is said to be easy to pull that in, on a case-by-case basis. I wonder how the mechanics of Rails work behind the scenes in reality (assuming if they weren't happy they would stop using it). There are officially 677 forks (individuals working on it), 7 core team members, and our current commit rate isn't higher than theirs... Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
