Re: FYI: OSS-project

* Daniel James <daniel@...> schrieb:
> Hi Enrico,
> 
> > just in case anyone might be interested: i've written a little
> > paper on the OSS-QM project, which aims to offload generic 
> > package QM works from distros to a common place:
> > 
> > http://www.metux.de/download/oss-qm-project-2010050101.pdf
> 
> That is interesting, thanks! I think you might find some resistance from
> distros who wouldn't want an extra middleman between them and upstream.

The isn't necessarily a middleman. It's primarily about a common
repository and ref naming structure. So, eg. you 64studio guys could
decide to maintain your own repos, and I just would let a little
bot fetch from there.

> You might like to start by providing a new home for useful packages
> which have been orphaned upstream.

Well, I'm right now maintaining packages I need. Some of them dont
even have an upstream repository, some of them also seem to be
quite dead.

But: taking over dead projects is _not_ scope of oss-qm - that's
an orthogonal issue. Anyways, I'm willing to take maintenance of
other projects if I'm asked to.

> There are so many different variables in package maintenance 
> that you will probably find it easier to focus on one type of

Re: FYI: OSS-project

> * Daniel James <daniel@...> schrieb:
>> Hi Enrico,
>>
>> > just in case anyone might be interested: i've written a little
>> > paper on the OSS-QM project, which aims to offload generic
>> > package QM works from distros to a common place:
>> >
>> > http://www.metux.de/download/oss-qm-project-2010050101.pdf
>>
>> That is interesting, thanks! I think you might find some resistance from
>> distros who wouldn't want an extra middleman between them and upstream.
>
> The isn't necessarily a middleman. It's primarily about a common
> repository and ref naming structure. So, eg. you 64studio guys could
> decide to maintain your own repos, and I just would let a little
> bot fetch from there.
>
>> You might like to start by providing a new home for useful packages
>> which have been orphaned upstream.
>
> Well, I'm right now maintaining packages I need. Some of them dont
> even have an upstream repository, some of them also seem to be
> quite dead.
>
> But: taking over dead projects is _not_ scope of oss-qm - that's
> an orthogonal issue. Anyways, I'm willing to take maintenance of
> other projects if I'm asked to.
>
>> There are so many different variables in package maintenance
>> that you will probably find it easier to focus on one type of

Re: FYI: OSS-project

* patrick@...
<patrick@...> schrieb:

> I can see some value in this approach as there are now almost too many
> music and multimedia distros to choose from. A lot of the work is being
> replicated and with varying results. It makes the overall platform seem
> unstable and it must be frustrating for new users or users who don't want
> to spend time working on installation issues before they can start
> producing.

ACK. That's one of the reasons why I founded the OSS-QM project.
IMHO the first thing we should do is importing the packages with
their local changes into git (turn dpatch files into direct commits)
and then create the debian-patch from this. 

So the history of an imported debpkg release would look like this:

  -> [upstream-release]                               <- tag: UPSTREAM.$pkg-$version
  -> dpatch #0
     ...
  -> remaining direct changes (w/o ./debian/)         <- tag: 64STUDIO-SRC.$pkg-$version
  -> applying ./debian/ (w/ dpatches already removed) <- tag: 64STUDIO-DEB.$pkg-$version

I'll see if I can hack someting up that automates this.

Later releases (when directly maintained in git) would be rebased
to the following upstream releases and fixes done in git. Right
before the final deb-release, the branch gets sorted/refined 
(interactive rebase, etc) so that the ordering described about
remains intact.

Re: FYI: OSS-project

<snip>

Just began hacking up a bit: here's a little script which imports
dpatch'es directly as git commits.

One thing I can't clearly figure out yet is the original author,
it doesnt seem to be a standard there (mbox-style patchfiles
would be much better here, IMHO), but thats not that important.

cu
--

-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@...
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

#!/bin/bash

[ "$AUTHOR" ] || AUTHOR="Debian Autoimport <weigelt@...>"

DPATCH_FILE=$1
if [ ! -f ${DPATCH_FILE} ]; then
    echo "$0 <dpatch file>"
    exit 1