On 2010-03-16, at 10:27 AM, Jeremiah Foster wrote: > > On Mar 16, 2010, at 3:00 PM, Anas Nashif wrote: >> On 2010-03-15, at 6:52 AM, Jeremiah Foster wrote: >>> On Mar 15, 2010, at 9:59 AM, Quim Gil wrote: >>>> ext Andreas Osowski wrote: >>>>> >>>>> >>>>> 1. Scope and area of this working group >>> >>>>> 2. ... ? >>> >>> >>> I think we should address: >>> >>> - How do packages get from the build system (whatever that is) to the >>> repos >>> * Do developers upload to the repos? > >> No, That is done by release engineers, developers submit their changes and >> if they go in they will be part of the repos. > > Who are the "release engineers"? Are these people chosen by Intel / Nokia?
Yes. > Or are they from the community? How will MeeGo handle the inevitable spread > of developer's repositories? For community projects and repos probably someone from the community... >> >>> * Does built software get pulled into the repos automatically? >> >> Yes. > > So a developer would upload source into a build system, most likely an OBS > instance somewhere, and that source code would get built, then pulled in as > an RPM into the repo? True, that is done by the build system with all kind of hooks on top of that to generate a proper meego repo > >>> >>> - Will repo layouts reflect products >>> * Do we need an IVI repo? A video repo? A desktop repo? >> >> Yes, that is important to avoid cross dependencies and for maintenance >> reasons. There will be one core repo and many ux extra repos on top of that. > > I guess that makes sense. But it sounds complicated. Are there going to be > identical versions of the kernel in each repo? Or does one pull the base > system from one repo and then pull from an IVI repo (for example) on top of > the base repo? Yes, that is the case, 1 base repo and at least one overlay. > >>> >>> - Opportunities for QA >>> * Are there analogs to debian's puiparts or other QA? >> Yes, there is QA, not familiar with puiparts... > > http://wiki.debian.org/piuparts > Essentially it is quality assurance for a deb package. > > Is there are tools like this in the RPM world? > >> >>> * Do we set up tools to test the packages in the repos? In the >>> build system? >> What kind of tests? > > It would be nice to know if a given package actually would install, > uninstall, and is properly formatted. Format would include things like > maintainer email address, license declaration, etc. >> >> >>> * Are there tools in the rpm world that do what debian's >>> lintian does? >>> >> ATM, We have multiple lint, code and packages checks done after every build. > > Lintian is debian's policy checker. It checks that a given package adheres to > the debian policy. That is to say; does the package ship UTF-8 files, man > pages, is the control file correct, etc. This tool checks large parts of > debian policy and fairly thoroughly takes apart a package. It does more than > just a lint check, which is often just related to programming language > specific files, i.e. check C files for errors. > > Is there something like this in the RPM world? If not, will there be hooks > available to do system and functional tests? > We have all of that, using rpmlint, rpmchech and post-build-checks that checks for common compile warnings and other policy violations and also does basic package installation and checks for update issues in post install scripts. > Jeremiah > > > _______________________________________________ > MeeGo-dev mailing list > [email protected] > http://lists.meego.com/listinfo/meego-dev
_______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
