here two options http://dpaste.com/hold/86438/ option1 http://dpaste.com/hold/86439/ option2
El 27/08/09 10:11, Andres Vargas escribió: > the only what i can add its the Metada file format can change a > little... for fix/fill/reuse a python module what can parse. example > configobject > http://www.voidspace.org.uk/python/configobj.html#configobj-in-the-real-world > > 2009/8/27 António Meireles <s...@reboot.sh> > > > the end-goal of any (product) development model is to get discipline, > accountability, predictability, scalability in order to get stability > and quality on the goods deliverable. Everything else is subsidiary > to this. > > As i've written before, conary is 'just' a packaging/configuration > management technology, the best one, but still just that. And, that kind > of technology, per definition, as good or evolved as it may be, will > never be a substitute to understand what is being handled in concrete, > and it's role in the environment it runs. Also, no one, on sane > grounds, should expect anyone to be fluent on all packages, all stacks, > all levels. More, the core basis of the whole open source development > model, what really makes it scale, is openness and collaboration. We do > not have the resources, the people, the money, nor we should have the > ego, to try, even pretend to, reinvent the wheel. If something is well > done/maintained elsewhere, and it works and suits our needs, and we can > legally leverage it, we should just use it, and move ahead. We should > just invest our time, which is our most precious resource, in places > where we can add value and make a difference, for the better. Being just > different will not bring us any good, being better will. > > With this lines draw clearly draw in the wall, here's what i envision > for foresight3, and beyond... > > ... on package naming and package Specing > > Foresight will be a from the ground, up from the source (:recipe) > full distribution. We will just follow Fedora's package > naming/splitting conventions, wherever they are sane or not. We need > this in order to leverage the works that will come from 'boots'. > Please do note that we will have to follow rigidly fedora at their > naming conventions at binary package level, at recipe level, we have > more flexibility, anyway, for consistence, we will use _not_ cheaply > that flexibility, and if and when we do, we should document properly > why we did it, for future memory. In order to get lightweight on > size we will need more granularity in the way we deliver binaries. > This implies more fine grained pkgSpecing. Again we will follow > fedora on this. A tool will be provided that for any given package, > will give us the fedora spec rpm name of it, and all the different > binary packages it will produce. > > > ... on file layout > > We will follow exactly RHs/Fedora file layout conventions, for > compatibility and convenience. Exception, will be hooks, to preserve > existing behavior, or to assure migration paths. If, and when, we > deviate, it should be properly documented why, and the benefits we > get from that. > > > ... on package versions, and patchsets > > For all the packages, to which we do not have proper know-how, or > which are not core to the value we intend to deliver, we will use > strictly Fedora as our upstream. When we do not, it should be clear > on our side why, and who is responsible to handle those packages. > The major goal, is to have just two kinds of bugs - either upstream > ones (Fedora) or ones for which we have people savvy enough to > tackle them. Please do note that there are at any given times two > Fedora trees that matter to us - shipped one (N), and rawhide (that > will turn into N+1). Our immediate goal, is to match feature wise a > given stable Fedora release, and then, start leveraging the work > they do in N + 1, as our tools allow that. With that said, we will > not be blindly bleeding edge, and things only should get in > production after it is clear that there's is really added value > there. Again, remember "" At any given time, not try to provide > the "best new technology of tomorrow", but the best "*working* > technology of today" """. > Exceptions are support for 'legacy/corner' technologies like selinux > and gcj support. Regarding selinux. which is largely irrelevant for > our use cases, we have two options either _actively_ ignoring it, > dropping all patches related to it, and all configs selinux related, > or simply have it around, and still ignoring it, as it will be > always off by default. Which one we choose is a matter of what > gets cheaper resource-wise for us. Regarding gcj & associates, which > is largely superseded by the icedtea/openjdk stuff, is adds an > overhead that we can clearly stay without, so we will pretend it > does not exist. > > Again, anytime we deviate from fedora, we should document properly . > At higher levels we can, and should, track the goodies elsewhere, > but always in a consistent and documented manner. Picking random > patches from random places is not the way to go. > > > ... on package maintenance > > Packaging is not the hardest part. Maintaining a package is. A > logical result of everything said above, is that we should only have > to worry with the stuff we feel confortable with. all else we follow > upstream decisions. When not, we should document. > > ... on metadata > > Albeit conary has good support for metadata (it swallows happily > rpm's and deb's one), we, at foresight, are not actively, yet, > leveraging it. We will, from now. In order to ease maintainability, > scalability, scriptability and integration with 3rd party tools, > metadata for each :source package will start to get stored > separately, say in a INFO file. the goal is to make it easily > parsable. a prototype skeleton bellow > > -- x-- > > [packageName] < -- needs to match recipeName > summary ... > description ... > URL > arch x86 x86_64 # or x86 or x86_64 or noarch > [[license]] > < -- we should have a canonical list of licenses to accept, and if > fetching > something new one, force us to add it to list. also, we may > need to to support packagings with multiple licenses and > comments see bellow > GPLv3 > CC # for documentation > [[patches]] > patchName patchOrigin - Fxx/rpath/foresight/add otherSources > here)) patchPristiness(optional field only used for non > foresight patches, either does not exist or says modified) > this last field is to warn against too fast patch > application if they > have to be modded first. also this will allow to track > patch lifetime > 'upstream', with info bellow in tracks > > [tracks] <-- what we are tracking/following > Fxx (optionalAliasIfRhNamingDifferentFromOurs) > srpm/tarball/whatever.version.XX.f1Y > > [sets] > # this will be used in future for dynamic group creation. > # syntax to be refined. > gnome > gnome-lite > > [[subpackage and or :component]] > summary > description > > [sets] > > --x-- > > > the fields to be populated above have two main purposes, to get > plain metadata (descriptions, etc) fetched by our conary policies at > build time (to be consumed by packageKit, etc) and to help on > maintenace (more on this later). For economy, we will reuse, > whenever is possible Fedora's work on metadata (package descriptions > et al, as, again, we have no point in reinventing the wheel. > > ... on management tools. > > mirrorball (http://hg.rpath.com/mirrorball) has already some nice > hooks to compare what is in a rpm repository and what got already in > a conary one. Right now it cares most about binary packages. We will > extend it to introspect source rpms and debs too, and cross the data > we get from that to the data we are putting in the meta-data, as > described above. This way, we will get close to real time reports, > on how we are re: the alternatives, etc. This new tool, whose > development will be lead by Scott Parkerson, who kindly volunteered, > will be the center of all our development activities and will > integrate closely with our issue tracker, and upstream ones. This is > absolutely key to keep us focused and disciplined, and ultimately > for us to scale. The extensions we provide for mirrorball > funtionality will naturally will be provided back to upstream, > rather than being a fork. > > ... on editions / profiles > > Gnome, XFCE, KDE, as we already have people who understand these > well. Would like to have moblin too in the future, allelse we get > commited people too. > > > ... on priorities > > get feature parity with the parts we care of F12, at time of F12 > release, and go from there. If not possible, F13. > > > ... on groups > > Groups are way too complicated right now. We will have a base group, > roughly equivalent to the rPL's appliance one, a minimal GUI one, > with X and the libs/services we want common to all variations, and > all else edition specific (or devel groups). One single top level > group will assure dep closure, per arch. > > > ... on community > > our (marketing) focus strategy wise, short term, should be not to > try, 'too hard' to recruit new plain end users, whose will better > served by 'boots', but to make dead easy for power users, and > existing and wannabe developers elsewhere, to integrate in our > community. We really need to cut down on the Signal/Noise ratio we > wave right now, if we ever want to get things to scale. > > Why would ogthers come to join us ? - one single reason, not to > think different but to act differently and helping to shape how > things should really become. The fact that we are a small, friendly, > community needs to get leveraged right versus the too big, too gray, > too bureaucratic ones, that exist elsewhere. > > > > > -- to be continued > > > All the best, > > António > > P.S. This paper does not pretend to be the perfect or definitive answer > to anything. It must be seen as a small part of an ongoing effort to > help us separate what is for us, core, and what isn't, what is > essential, and what is accessory. > _______________________________________________ > Foresight-devel mailing list > Foresight-devel@lists.rpath.org <mailto:Foresight-devel@lists.rpath.org> > http://lists.rpath.org/mailman/listinfo/foresight-devel > > _______________________________________________ Foresight-devel mailing list Foresight-devel@lists.rpath.org http://lists.rpath.org/mailman/listinfo/foresight-devel
