On Fri, 2007-02-23 at 10:42 -0500, James Carlson wrote: > Laszlo (Laca) Peter writes: > > It's not a workload issue. We can handle more packages (as long as > > our nightly build completes in 24 hours ;) But it doesn't seem > > logical. > > It does seem logical to me: the consolidation with the closest ties to > a given bit of software is the one that delivers it.
I agree, whenever there are close ties. I'm not sure if, for example, libtool is any closer to JDS than to SFW or X. > We very much want to avoid breaking the software into unnecessary > consolidations, because synchronizing delivery across multiple > consolidations is quite difficult and error prone. Right. One of the reasons why I though it should be separate from JDS is so that we don't need to synchronize with the GNOME schedule. An example is when another consolidation requests fixes in Python and I'm telling them that it's fixed, but it will only appear in Nevada with the next (6-monthly) GNOME drop. > In other words, if your consolidation depends on foo-1.2.3 and you > need to upgrade to foo-1.2.4, things are simple if you can do that as > an atomic 'putback' or 'commit' to a single consolidation's > repository. You (and your customers) are in a world of hurt if you > need to do that to multiple repositories, particularly so if there are > incompatible changes involved. I not following why I would need to commit to multiple repositories. "foo" would still be in one repository only. However, most of the build tools that I'm talking about affect more than just one consolidation. > So, unless there's a clear need for a new consolidation, and complex > _technical_ ties between the packages delivered there, consider this a > "-0" from me. I still need to see a proposal that defines what those > natural groupings are. > > > Well, the GNU/UNESCO list has 5300 packages. But I guess you're > > right, there is no reason to exclude packages because they are not > > on the list. How about defining the universe as packages with an > > OSI approved open source license? (Sigh... I need a new project > > name then.) > > Yes, there is a reason to exclude them: the ARC approval for /usr/gnu > was for things on that list, and no others. And that's fine, it just means that things not on that list cannot go into /usr/gnu. They can still go into /usr if there is no conflict. > > That's a good point. I don't think it's feasible to go to ARC each > > time we integrate a package into the proposed repository. ARC would > > soon have a huge backlog. > > I doubt it. These sound like the most trivial of fast-tracks to > me. Most are probably closed-approved-automatic. You mean if the fast-track only deals with the name space and not with the technology itself? > > Perhaps we could have a BFT (blindingly > > fast track) that allocates the name space only. > > We already have that process. It's called "automatic approval." No > need to invent a new one. :-/ Apologies, did not intend to step on ARC toes (; Thanks, Laca _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
