1 |
* Nirbheek Chauhan <nirbheek@g.o> schrieb: |
2 |
|
3 |
> If I understand your system correctly, you essentially maintain clones |
4 |
> of upstream repos, with all the various distro patches applied on top, |
5 |
> and release tarballs as well. |
6 |
|
7 |
Yes. And if some upstream does not provide suitable vcs access |
8 |
(or doesnt even have one), I make an pseudo-upstream branch by |
9 |
committing the release source trees. |
10 |
|
11 |
> I don't see how these various distros can be made to agree with |
12 |
> each other and I certainly can't see them using a common tarball |
13 |
> source. |
14 |
|
15 |
Thats not even necessary. They just should use the infrastructure, |
16 |
as described in my paper. So everyone can easily set up automatic |
17 |
notifications, cherry-pick, etc, etc. |
18 |
|
19 |
> On a technical level, it's got serious security, trust, and |
20 |
> redundancy problems. |
21 |
|
22 |
Git makes that very easy ;-p |
23 |
|
24 |
> It is extremely important that distros collaborate in some form |
25 |
> when it comes to patches that *can* be shared, |
26 |
|
27 |
If we're doing a good job (my generic fixes instead of distro- |
28 |
specfic dirty hacks) about 99% can be shared ;-p |
29 |
|
30 |
> but the solution you have devised is fundamentally flawed. |
31 |
|
32 |
If it's really flawed, then just for pure "social" reasons, no |
33 |
serious technical ones. |
34 |
|
35 |
> A practical solution to the problem of patch sharing is to |
36 |
> have a website with a search interface for upstream source |
37 |
> tarballs, which can display all the patches that various |
38 |
> distros apply, as well as a download link for the patchsets |
39 |
> (hotlinked to the distro files where possible). |
40 |
|
41 |
Too complicated, and actually would not help me a single bit. |
42 |
What I could offer is an (semi-)automatic import mechanism |
43 |
(assuming certain package managers dont do such insane things |
44 |
like directly sed'ing sources etc) - there's still a bunch of |
45 |
work to do for that, but its possible. |
46 |
|
47 |
> Distro packagers are much more comfortable with downloading |
48 |
> patchsets from a foreign source than complete tarballs. |
49 |
|
50 |
man git-format-patch ;-p |
51 |
|
52 |
Maybe I could set up an git webfrontend (or automatically push |
53 |
to some public service). |
54 |
|
55 |
> I know you have spent a lot of time on this already, but please |
56 |
> understand it from where we stand. We're short on manpower, and |
57 |
> there's no real benefits of shifting our tarball source; OTOH there |
58 |
> are major disadvantages too unless we pitch in with manpower |
59 |
> ourselves. And honestly speaking, that manpower is better spent making |
60 |
> stuff work locally. |
61 |
|
62 |
Well, Gentoo is short of manpower ? hmm, perhaps some should think |
63 |
about why so many folks are resigning and so few fresh coming in |
64 |
(at least according to this lists traffic) ;-O |
65 |
|
66 |
> Please consider the "patch-website" idea above. We definitely need |
67 |
> someone to code it up, gather the source-package to distro patches |
68 |
> mappings, and advertise it. |
69 |
|
70 |
Actually, I once had somehing in that area, called "comprehensive |
71 |
source database", but unfurtinately it got lost in an disk array |
72 |
crash a few years ago, and I didnt find the time to rewrite it yet. |
73 |
|
74 |
Meanwhile I dont need it anymore, since I gave up maintaining |
75 |
plaintext patches in favour of git. And that makes my daily works |
76 |
_much_ easier. |
77 |
|
78 |
Oh, btw: I'm announcing my oss-qm releases via twitter: |
79 |
|
80 |
http://twitter.com/oss_qm |
81 |
|
82 |
|
83 |
cu |
84 |
-- |
85 |
---------------------------------------------------------------------- |
86 |
Enrico Weigelt, metux IT service -- http://www.metux.de/ |
87 |
|
88 |
phone: +49 36207 519931 email: weigelt@×××××.de |
89 |
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 |
90 |
---------------------------------------------------------------------- |
91 |
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme |
92 |
---------------------------------------------------------------------- |