Current state of things

[Michal Hrušecký]

Hi,

I just want to ask, what is the current state of things? Is there
already some collaboration process defined? Is there something already
going on? I was just thinking that it might make sense to extend
collaboration even to non-embedded distributions...

---
Michal Hrusecky <Michal.Hrusecky-***@public.gmane.org>

[Enrico Weigelt]

* Michal Hru?ecký <Michal.Hrusecky-***@public.gmane.org> schrieb:

Hi,

Post by Michal Hrušecký
I just want to ask, what is the current state of things? Is there
already some collaboration process defined?

not that I'm aware of ;-p

Post by Michal Hrušecký
Is there something already going on?

I've written a little paper describing a common source repository
layout, where everybody (each distro, etc) can publish their own
changes ontop the upstream, so others can easily monitor/pick them:

http://www.metux.de/download/oss-qm/normalized_repository.pdf

Post by Michal Hrušecký
I was just thinking that it might make sense to extend
collaboration even to non-embedded distributions...

ACK. Embedded systems are in no way special here (besides the fact
that they just might have larger changes and stick in specific
versions for a bit longer).


cu

[Michal Hrušecký]

Hi,

thanks for your replies. Looks like this topic isn't completely solved
yet. At distribution mailing list for FOSDEM 2011 this topic was
proposed (by Hans de Goede (Fedora) and me (openSUSE)). We hope to get
some attention, discussion and hopefully some collaboration (on
desktop distribution level as well).

If you are interested, thread starts here:
http://lists.fosdem.org/pipermail/dist2011/2010-December/000067.html

I proposed my own approach to the problem in that thread, but while
searching for already existing solutions I came across this site and
wanted to know, what is already there, so we wouldn't reinvent the
wheel and maybe join the efforts...

---
Michal Hrusecky <Michal.Hrusecky-***@public.gmane.org>

[Enrico Weigelt]

Post by Michal Hrušecký
http://lists.fosdem.org/pipermail/dist2011/2010-December/000067.html

Well, if the upstream is dead, the cleanest way is to take over ;-p
(we did it w/ mc a few years ago, and so revived the project).


cu

[Robert Schwebel]

Post by Michal Hrušecký
I just want to ask, what is the current state of things? Is there
already some collaboration process defined? Is there something already
going on? I was just thinking that it might make sense to extend
collaboration even to non-embedded distributions...

Patch collaboration seems to be the first thing we could take care of.
The problem seems to be that the maintainers of the different distros
have their own quality requirements and want to decide which patches to
take.

rsc

[Leon Woestenberg]

Hello all,

Post by Robert Schwebel
Patch collaboration seems to be the first thing we could take care of.
The problem seems to be that the maintainers of the different distros
have their own quality requirements and want to decide which patches to
take.

A good idea would be to be aware of each other patch flows,

How can we locate the patches of all related project?
Are there patch trackers?

Best regards,

[Enrico Weigelt]

Post by Leon Woestenberg
How can we locate the patches of all related project?

Some time ago, I wrote some automatic importers from several distros
into the OSS-QM's git repos. (eg. directly importing Debian's patch
queue within their big patch ...). All these trees are tagged in
separate (per-distro/vendor) namespaces and can be easily tracked
using some piece of shellscript.


cu

[Enrico Weigelt]

Post by Robert Schwebel
Patch collaboration seems to be the first thing we could take care of.

I'd drop the idea of patches at all and instead use normalized
git repos ;-p

http://www.metux.de/download/oss-qm/normalized_repository.pdf

Post by Robert Schwebel
The problem seems to be that the maintainers of the different distros
have their own quality requirements and want to decide which patches to
take.

Of course. That's what distros are for. But what we could do is
maintaining bugfixed source trees (whole trees instead of patches ;-p),
of high quality, which can be directly used as "secondary" upstream,
always based on the appropriate upstream release (for virtually any
upstream release) with an release-ASAP policy (well, essentially the
idea of the OSS-QM project ;-p)


cu