Build service meeting at SUSE, 6. July 2007 mls, darix, tscholz, poeml, lrupp Topics: (1) commit method (2) local build of linked packages (3) method of sending files for buildinfo (4) diff (5) osc: log/buildlog (6) wipe (7) osc: editing project config (8) api version enforcement Action Items: - poeml, mls: talk to Andreas Bauer about committing files and necessary api changes - poeml: implement new commit method in osc - poeml: ask on opensuse-buildservice for osc log/buildlog command - mls: see how well the code handling linked packages can be separated and placed in build.rpm - poeml: for buildinfo, parse rpm headers of local packages and send along buildinfo request - abauer: check whether / how requests on /source/prj/pac could provide information about linked packages (see (2)) - abauer: check if diff route allows file= and ofile= parameters in the query string - mls implement "single file diff" - poeml: finish osc's project config editing feature - poeml: let osc send api version, as a first step - lrupp: check if selective wipe command really doesn't work :-) (1) commit method Committing files to the backend is going to be atomar in the future, and planned to happen like this: 1) client sends list of files' md5sums to server 2) server checks which files are already in the repo, and replies with list of "missing" files 3) client POSTs files (possibly packed together as cpio? See (3). Possibly compressed to save bandwidth) Implementation status: backend already supports this. API needs to be extended to pass through the POST request. osc needs to be changed for this. How about compatibility to old clients? (2) local build of linked packages Exhaustive list of _link file features: http://opensu.se/~darix/link.xml.txt Questions: - whether to handle this on the server or client side - whether _link file contents should be stored as XML metadata instead - whether _link contents (and patches) are "metadata" at all, or "source" the distinction is relevant with regard to triggering rebuilds. Generally, there are properties which may trigger a rebuild, and others which may not. Now, metadata changes do not trigger rebuilds, source changes do. Use cases: - linked package, local build, either a) the sources and patches need to be send to the server and the patched sources returned to the client for building, or b) or the the client needs to implement the same logic as the server, and possibly needs to check out all packages linked to and apply the patches - link to locally modified package (hardly possible to handle this on the server side) - link to other link (no problem for the server) - when trying to check in changed sources, but encountering a "not allowed", create a linked package on-the-fly and commit the local changes as linked package instead. a.k.a. "Adrian use case" ;-) Extension to this train of thought: Possibly submit a "merge request" Theoretically, a /source/prj/pac request should provide information about linked packages, where applicable (like: package and project linked to) (3) method of sending files for buildinfo osc needs to send two things to the backend for calculation of the buildinfo: a) the specfile b) provides/requires lists of local packages which should be used in the server-side expansion The request will be a POST with a a) and b) encoded together as cpio. The provides/requires come as P:x,y,... R:x,y,... lists. (4) diff "osc diff" of the working copy against old revisions is implemented (Thanks, Marcus!). This is done via a temporary checkout of the revision in question. There is a server-side diff provided by the backend for an arbitrary revision against another one. This has the advantage of being "intelligent" (by noticing renames and diffing tarball contents) and the disadvantage of working only on package level (so it can't be used to diff a single file). We decided to add a way to diff single files. Thinking about the needed API, it was felt that the simplest thing is to add file= and ofile= query parameters, resembling the rev= and orev= parameters, which means that the api route probably doesn't need a change. (5) osc: log/buildlog Question: - should the osc log subcommand be renamed to buildlog (bl), so log can be used to retrieve the commit log? -> ask users for feedback Also to do: change the log/buildlog command to work without a checked out working copy (6) wipe Users want a command to wipe all packages which have been built already, but for which "publishing" has been later disabled. Selective wiping is implemented for packages marked with build=disabled. (If this wipe doesn't work as expected yet, there might be a bug in the current implementation. Please check, and report failures.) Question: - is it sufficient if there is a way to wipe all packages for which _build_ is disabled (vs. "publishing disabled" or other properties) ? It might be enough, since users could wipe the entire repo and then build the desired packages again. - how to do this in a way compatible to package renames? Actually, there is no facility to rename packages anyways. There is only a copy (client side in osc). Michael says that the backend's repository handling might need a rewrite, in order to properly track disabling/enabling packages (so to be able to keep old versions in the repo as long a package is disabled). Such a rewrite is also needed to support clustering. (7) osc: editing project config - A facility in osc to edit project configuration is work in progress, but takes a little time because I'm cleaning up code for that and want to clean up the other metadata editing facilities first. (8) api version enforcement - the osc client should send the api version it is known to support. - the api should should return "412 Precondition Failed" if the site administrators decide to depracate old clients and a client isn't up to date enough. - the client needs to provision for this condition, and error out. Open question: can this be performed in a way that a user, who is forced to update the client, can still have a client wich is functional with other (e.g. local) buildservice instances. If the client doesn't stop working, but only issues a warning, the server can't reply with HTTP code 412. But it can perhaps add a warning header line which is seen by the client, which issues a warning then. Peter -- Allen Gewalten zum Trutz sich erhalten. SUSE LINUX Products GmbH Research & Development