Hi folks,

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

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

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 174 7066481 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel

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.

You might like to start by providing a new home for useful packages
which have been orphaned upstream. There are so many different variables
in package maintenance that you will probably find it easier to focus on
one type of package to begin with.

Cheers!

Daniel
_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel

* Daniel James <daniel@64studio.com> 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
> package to begin with.

No, that would be an entirely different frontier. My scope (for oss-qm)
is to do QM/Fixing of *many* packages in a strictly-downstream (IOW:
frequently rebased onto upstream) fork and so close the gap between
upstreams and the dozens of distros. The idea behind oss-qm is that
individual distros shouldn't do everything on their own, but instead
collaborate (on per-package basis) in the common things (so also
doing generic instead of distro-specific fixes).


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

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel

> * Daniel James <daniel@64studio.com> 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
>> package to begin with.
>
> No, that would be an entirely different frontier. My scope (for oss-qm)
> is to do QM/Fixing of *many* packages in a strictly-downstream (IOW:
> frequently rebased onto upstream) fork and so close the gap between
> upstreams and the dozens of distros. The idea behind oss-qm is that
> individual distros shouldn't do everything on their own, but instead
> collaborate (on per-package basis) in the common things (so also
> doing generic instead of distro-specific fixes).
>


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.



> cu
> --
> ----------------------------------------------------------------------
> Enrico Weigelt, metux IT service -- http://www.metux.de/
>
> phone: +49 36207 519931 email: weigelt@metux.de
> mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
> ----------------------------------------------------------------------
> Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
> ----------------------------------------------------------------------
> _______________________________________________
> 64studio-devel mailing list
> 64studio-devel@lists.64studio.com
> http://lists.64studio.com/mailman/listinfo/64studio-devel
>


_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel

* patrick@64studio.com <patrick@64studio.com> 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.

If the upstream has some public vcs w/ (maybe via automatic mirrors,
like those I'm maintaining on pubgit.metux.de) w/ proper tagging,
its tags should be directly used as upstream (or maybe adding the
release tarball as a intermediate commit).

I'll see if I hack up some automatic robot ...


BTW: feel free to join oss-qm: https://sourceforge.net/p/oss-qm/home/


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

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel

<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@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
#!/bin/bash

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

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

## retrieve the header of an dpatch file
dpatch_header() {
local file=$1
local hdr_lines=`grep -m 1 -n "@DPATCH@" < $file | head -n 1 | sed -E 's~:.*~~; s~([0-9]*).*~1~;'`
((hdr_lines--))
head -n "$hdr_lines" < $file |
grep -v "#! /bin/sh /usr/share/dpatch/dpatch-run" |
grep -vE 'All lines beginning with .## DP:. are a description of the patch.' |
sed -E 's~^## *~~; s~^DP: *~~'
}

TMP_HEADER=`mktemp`

(
echo "(Debian) dpatch: $DPATCH_FILE"
echo ""
dpatch_header $DPATCH_FILE
) > $TMP_HEADER

git reset

if ! git apply --index $DPATCH_FILE ; then
echo "git-apply failed: $DPATCH_FILE" >&2
exit 1
fi

cat $TMP_HEADER

git commit --author="$AUTHOR" --allow-empty -F $TMP_HEADER

rm -f $TMP_HEADER
_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel

* Enrico Weigelt <weigelt@metux.de> schrieb:

Hi folks,

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

Meanwhile hacked a bit more
I've now got a bunch of git porcelain scripts, lots of shell
functions and some example importers, which import everything
into oss-qm's normalized naming/versioning scheme (including
applying the dpatches as separate commits, etc).

git://pubgit.metux.de/oss-qm/TOOLS.git


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

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel