On Mon, 2007-11-12 at 11:22 -0500, Jesse Keating wrote: > On Mon, 12 Nov 2007 17:02:40 +0100 > Matej Cepl <mcepl@xxxxxxxxxx> wrote: > > > I am not really sure, that it means that -- I am not saying "never > > ever use upstream tarball, ever." My idea would be that koji would > > get couple of backends and Source could be more creative. So instead > > of just "download tarball from this URL, unpack and work", it could > > understand alos URLs like git://, bzr://, hg:// (or something like > > that), meaning "clone/checkout/<whatever is the local name of getting > > the sources> from somewhere, and then build over that". And of > > course, one of these methods of getting sources would be downloading > > tarball. > > And now your buildsystem is entirely reliant upon upstream locations > staying up, staying consistent, not being compromised, etc... > Definitely not something you want for Fedora, and certainly not > something we can even consider for RHEL. > A better way and one of the tools I am looking into building is to have an external client which can pull from tarball locations or any RCS tag to build new versions of packages at the touch of a button. This would solve the issue of it being time consuming to simply package up new releases. There have been other discussing changing how we keep track or upstream sources and in fact the X packages are now managed through a tarred up git tree I believe. In any case the backend isn't as important as the frontend we give to developers to make them more efficient. I guess this is a good point to introduce myself and my new role to the Fedora Infrastructure community (and those who use it). Those who don't know me, my name is John Palmieri though people in the development community just call me J5. I'm one of the D-Bus maintainers and GtkPrint creators and have worked on Red Hat's Desktop Team as well as being a build master and Fedora integration point for the OLPC project. I've have recently been tasked within Red Hat to find ways to make consumers of the infrastructure more efficient. My previous role as the build master for OLPC made me realize that there are huge hurdles to contributing and maintaining various elements within Fedora. My job is to make it easier by working with the different groups with the Fedora Infrastructure so that we are all on the same page as well as defining areas which need more attention or perhaps need a project to be created to fill in the gaps. Fedora is steaming ahead at an awesome pace and it gets better and better each day. I believe in keeping that pace of innovation going while I work to get all of the distractions and roadblocks out of the developer's way. As I ease into my new role I am looking forward to discussing ideas on the list and at the next FUDCon. -- John (J5) Palmieri <johnp@xxxxxxxxxx> -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
