On Thu, 30 Sep 2010 21:40:42 +0200 Sam Geeraerts <[email protected]> wrote:
> Karl Goetz wrote: > > On Thu, 30 Sep 2010 10:39:01 +0200 > > jaromil <[email protected]> wrote: > > > >> hi Karl, > >> > >>> On Mon, 27 Sep 2010 10:10:44 +0200 jaromil <[email protected]> > >>> wrote: > >>>> one solution i see is just provide a .patch for the upstream code > >>>> and leave distro developers and mantainers apply it every time > >>>> they make a new release: a minimal, short term solution. > >> On Wed, Sep 29, 2010 at 08:36:35PM +0930, Karl Goetz wrote: > >>> Not really. its /the/ solution if upstream doesn't want to accept > >>> the patch. One of the big problems with this is different distros > >>> with different versions of applications trying to use the same > >>> patches as code evolves. > >> ACK. so i should include in the steps outlined the first one: > >> propose the patch to upstream. > >> > >> is there a page resuming a short "what to do" when trying to > >> liberate software packages? > > > > No, but I think there should be one :) (on libreplanet ?). > > Indeed. A common generic procedure could make distro development and > communication between distros easier. How about this to start with: looks good, but i'd rearrange it like this: > * Identify the problem. > * Contact gnu-linux-libre list. > * Report a bug upstream. > * Add to NONFSDG list with link to upstream and distro bug reports > * Create a patch. > * Publish the patch; send a copy to gnu-linux-libre and a copy to > upstreams bts. > * Apply careful diplomacy to upstream to accept the patch. > > YMMV, depending on the sort of problem. and the level of life in upstream :) > >>>> upstream development of software: builds at every new commit and > >>>> reports failure on building on various platforms (via mail or > >>>> irc), ATM we have 32 and 64 bit debian, fedora, gentoo and > >>>> ubuntu. > >>> I've thought about such things for various projects im involved > >>> in, but maintaining it and debugging requires much > >>> time/effort/skill then i have to hand. > >> of course this is a task for sysadmins with time at hand. and we > >> know > > > > Not just sysadmins, thats the problem. it requires developer input > > every time a package build fails. (otherwise, what was the point of > > the build?) > > For just our patched packages it seems manageable. To take managable, yes. but this started as 'builds at every new commit' - a very different story. > responsibility for a whole (or even multiple) distro repo we'd need a > few more people, I figure. :) Perhaps, depends how different the software we are working on is. > >> buildbot its kind of one one could see it as a "launchpad" for > >> linux-libre.. ..without having to sign silly contracts and be > >> called "ubuntero" :) and most importantly based on more > >> distributions, not just ubuntu, but all those platforms adopted by > >> libre distros here. > > > > I like the vision, I just don't feel i'll be able to contribute as > > much as i'd like. > > Would the vision require a big bang complete setup or could we slowly > start with a proof of concept (e.g. the patch set in VCS or build > only one of the packages) and grow from there? Starting small would be starting it with one or two distros - something reasonable imo. kk -- Karl Goetz, (Kamping_Kaiser / VK5FOSS) Debian contributor / gNewSense Maintainer http://www.kgoetz.id.au No, I won't join your social networking group
signature.asc
Description: PGP signature
