Gentoo Archives: gentoo-dev

From: Sebastian Pipping <sping@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] paper on oss-qm project
Date: Sun, 09 May 2010 06:04:14
Message-Id: 4BE65034.3000301@gentoo.org
In Reply to: Re: [gentoo-dev] paper on oss-qm project by Enrico Weigelt
1 On 05/08/10 22:11, Enrico Weigelt wrote:
2 > what problems do you see w/ licensing ?
3 >
4 > IMHO, each branch simply has to follow the upstream's license.
5
6 i have yet to see easy cases with licensing.
7 i haven't thought about it in detail yet, tough, to be honest.
8
9
10 > simply normalize: don't use letters but numbers.
11
12 i don't believe in simple normalization before i have seen it.
13
14
15 > b) it's not really a release but just a development snapshot -
16 > that doesnt belong into the main oss-qm repository
17
18 why doesn't it belong in there?
19
20
21 > I've chosen that scheme to make the borders more clear (also for
22 > automatic filtering, etc). In my concept, the vendor is the major
23 > point of distinction, package comes at second, ...
24
25 i guess we agree to disagree then.
26 i don't think the current scheme promotes cooperation well.
27
28
29 > Well, the term vendor here is defined as a party which provides
30 > packages in certain variants. "UPSTREAM" is a kind of meta vendor,
31 > describing the upstreams. "Vendor" is IMHO more generic, since there
32 > may be vendors who aren't actually a real distro. For example, I
33 > myself don't publish a complete distro, but a foundation for clean
34 > building especially for special embedded devices or appliances.
35
36 yes, that's why i proposed "downstream" as a replacement.
37 you don't consider yourself downstream?
38
39
40 > Yes, that's still an open topic. I've chosen to use one big repo
41 > for easier maintenance, but I'm aware of the problem that the
42 > repo might become very fat some day.
43
44 my point is not about size, only about "users".
45
46
47 > I see two options:
48 >
49 > a) split it off into several ones, eg. on per-package basis
50 > and create a system for (semi-)automatic mass-repo maintenance
51 > (not completely trivial when using free git hosters as mirrors)
52
53 are you aware that splitting it up will reduce the savings in space?
54 say if they all had byte-identical GPLv3 COPYING files that would be one
55 blob atm and N blobs in split mode.
56
57
58 > b) add an selective filtering system. AFIAK current stable git
59 > doesnt provide that yet - I've added an little patch for that:
60 > http://repo.or.cz/w/oss-qm-packages.git/shortlog/refs/heads/METUX.git.master
61
62 while i'm not sure about this in detail yet, could it be this loop
63 misses to filter the very first entry?
64
65 + while (walk && (walk->next))
66 + {
67 + if (_filter_remote_ref(transport, walk->next))
68 + walk->next = walk->next->next;
69 + else
70 + walk = walk->next;
71 + }
72 +
73
74 best,
75
76
77
78
79 sebastian

Replies

Subject Author
Re: [gentoo-dev] paper on oss-qm project Enrico Weigelt <weigelt@×××××.de>