Hi David, first, sorry for the delay. I thought I should take my time to get the answers more comprehensible, but I guess before this will not get answered at all, I'll just jumpstart and whoever thinks it's not clear enough, please bug me with questions. ;) > > > > > 5) Build a repository > > > > > > > > What are the issues with the existing repositories? > > > > > > The existing repositories will be built from the repository the release > > > maintainer will build. Currently, each time I receive a package, I need > > > to scp it to ekiga.org. That is time consuming for me. Every release, I > > > loose a few hours on that instead of coding. > > > > Could a release manager extend the script that builds the nightly > > snapshots to also make release packages? Does the build script > > automatically slurp the library tarballs or CVS down from Sourceforge? > > I don't really know, Kilian is handling that script, he is in CC. > Notice you will have to use specific branches and tags, so the script > should be made generic. You do not need to build on all distributions, > you just need to create the tarballs and test. Well, the problem with release packs is not really with packaging, but with Craig and the official tarballs on voxgratia.org. These tarballs should be well tested (as is the case with CVS snaps already), so we might want to introduce an extra snapshots part for the other branches. For this, my current script doesn't scale too well, but I'm willing to put it onto public webspace for review. As the generation of package sources is done outside in an extra script anyway, this will scale pretty nicely once the checkout script can do more than one branch. The main problem with this is that the config should reside in the SVN/CVS of the project, so that upstream maintainers can choose the mappings. For this we'd need to put up a map like: HEAD => ekiga-snapshots gnome-2-18 => ekiga-2-18 etc. From there the question is how to handle the library dependencies with these snapshots. For example HEAD can be built with HEAD libs, but gnome-2-18 should be built with Phobos or some other branch. If you can come up with a scheme that can do this kind of mapping in a flexible and scalable config (so that my script will be able to read it and make packs non-interactively), I'll be happy to include it. > > Finally, do you think the package maintainers could be persuaded to > > upload packages (or package definition files) to a stable location? > > Or do they do this already? > > We could do that if somebody setups the server. That kind of archive should be possible on archive.buildserver.net. In that case the RPMs would mingle just nicely in between the deb-structure. For now we don't export the urpmi and ap4rpm style lists, but this could be added to the dak if someone stands up to doing this. The ideas are all there. ;) -- Best regards, Kilian
Attachment:
signature.asc
Description: Digital signature