Re: [Ekiga-devel-list] Improving the GNOME experience : request for help

["David Corking" <lists dcorking com>]

On 6/26/07, Kilian Krause <kk verfaction de> wrote:
> 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. ;)

No worries.  I haven't got very far with tasks 1 to 4 yet.

> > > > > > 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.

Killian,  Which code does your nightly build script take from the
OpenH323 project now:  HEAD, an official tarball from voxgratia.org or
a tarball fom sourceforge?

> 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.

I think if we are making snapshots for GNOME testers every 2 to 4
weeks, we _could_ try a half-way house:  edit your checkout script
manually.  If it looks useful to have more frequent tarball sets, we
can try to automate it.

I think that it would also be useful to have a human readable mapping
of library dependencies in a README file in SVN (unless it is already
there.)

I want to make it quick and easy.  Not for my sake, but in case
someone else is compiling it in a hurry (say for a security bug - God
forbid), they can quickly check out their own branch/tag tarballs for
their new source deb / rpm / port.

> > > 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. ;)

Is archive.buildserver.net a place where you can grant upload rights
to package builders ?

For the repository itself, my plan for 2.0.10 is just to make a
private directory tree on a server of mine, give Damien rsync/ssh
access, and allow him to mirror it onto www.ekiga.org

If people need urpmi etcetera I guess they can create it and submit it
to you.  However, I think the ekiga.org repository is only a place for
test packages and the Windows release, so perhaps people don't find
package install automation too important there (though the apt source
seems quite popular!)

I think the unix downstream maintainers - the distributions and BSD
ports collections - should get ekiga, opal and pwlib tarballs from
gnome.org.

--
David