Hi, On Saturday, March 04, 2006 at 14:25:29, Pascal Bleser wrote:
Henne Vogelsang wrote:
On Saturday, March 04, 2006 at 08:54:41, James Ogley wrote:
This would be an option - but currently does not happen since everybody is working on the release tree and therefore nobody puts the latest and greatest in... Would it be more likely to happen once the Build Service is up and running, and trusted community packagers are able to contribute to Factory?
Get rid of this tree-thinking. Read the build service white paper again or have a look at mls's presentation from FOSDEM. We are not going to have different trees (like core/extras or stable/unstable). Everything will be project based. So your project can be BetaN+Bleeding edge version of project foo.
Sure, but we don't know how the repositories will be hosted/assembled yet, do we ? ;)
Well hosting is no problem, its just putting files somewhere ;)
And that's great for experienced users, but for end-users, we should still be able to give them repositories where they can fetch all their stuff from (and not just several repositories per project, which would be far too complex and unmanageable).
Yes. We need to make this project concept fly for end-users. Let me try to explain whats in my mind about this topic. We know a project can consist of packages can be based on other projects. But you can also link packages from other projects to your project. So a project SUSE-unstable could consist of FACTORY + ProjectN bleeding edge packages You would aggregate all things that are bleeding edge to a project which would produce one installation source where people could install from. But that would only be one approach. The better one would be to define such "stamps" (nothing else is a stable/unstable tree concept) on real data. Now we are getting in the realm of the still not even defined trust/rating system. If we do this right then this system brings all data that you need to know for "stamps" like stable/unstable. This would also mean that these stamps function evolutionary and individually. Because stable for pascal means something completely then stable for Henne. So pascal stable could consist of projects with the attributes of * Trusted 99% * Quality 95% * Downloaded more then 100 times * Some other attribute 70% * Some other attribute 50% Of course you could share these "settings" with other users of the build service and they could use pascal's stable settings too. I really think "stamps" like stable/unstable should not be defined by some uberpackager or, god forbid, some committee for everybody. Henne -- Henne Vogelsang, http://hennevogel.de "To die. In the rain. Alone." Ernest Hemingway