1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Nirbheek, |
5 |
|
6 |
thanks for writing such a well thought-out and comprehensive reply to |
7 |
Enrico. I agree with all the points you raised. |
8 |
|
9 |
On 11-07-2010 10:28, Nirbheek Chauhan wrote: |
10 |
> On Sun, Jul 11, 2010 at 3:23 PM, Enrico Weigelt <weigelt@×××××.de> wrote: |
11 |
>> * Nirbheek Chauhan <nirbheek@g.o> schrieb: |
12 |
>>> I don't see how these various distros can be made to agree with |
13 |
>>> each other and I certainly can't see them using a common tarball |
14 |
>>> source. |
15 |
>> |
16 |
>> Thats not even necessary. They just should use the infrastructure, |
17 |
>> as described in my paper. So everyone can easily set up automatic |
18 |
>> notifications, cherry-pick, etc, etc. |
19 |
>> |
20 |
> |
21 |
> Why should we? I am *yet* to see a single reason for us to change how |
22 |
> we work other than "please use this since I've been putting a lot of |
23 |
> effort into it". |
24 |
|
25 |
Enrico, |
26 |
|
27 |
just because you decided to "offer" some service, it in no way "forces |
28 |
us" to accept it. |
29 |
|
30 |
>>> On a technical level, it's got serious security, trust, and |
31 |
>>> redundancy problems. |
32 |
>> |
33 |
>> Git makes that very easy ;-p |
34 |
>> |
35 |
> |
36 |
> No, it does not. The security problems come because you are the single |
37 |
> point of failure. The trust problems come because we have no reason to |
38 |
> trust you. The redundancy problems come because if your hosting goes |
39 |
> down or you lose interest, we're left high and dry. Git has nothing to |
40 |
> do with any of this. |
41 |
|
42 |
These 3 issues are in my view the most important issues regarding your |
43 |
proposal and I agree with Nirbheek's reply. |
44 |
With your proposal, you're expecting us (distro maintainers) to put our |
45 |
trust and our users safety in you and your service - what made you think |
46 |
we would or should do it? Besides, what significant gain would we have |
47 |
to justify trusting your service? |
48 |
|
49 |
>>> It is extremely important that distros collaborate in some form |
50 |
>>> when it comes to patches that *can* be shared, |
51 |
>> |
52 |
>> If we're doing a good job (my generic fixes instead of distro- |
53 |
>> specfic dirty hacks) about 99% can be shared ;-p |
54 |
>> |
55 |
> |
56 |
> I'd advise you to take a look at the sort of patching Ubuntu/Debian |
57 |
> does, and then revisit that figure. You'll find it more along the |
58 |
> lines of 30%. |
59 |
> |
60 |
> |
61 |
>>> A practical solution to the problem of patch sharing is to |
62 |
>>> have a website with a search interface for upstream source |
63 |
>>> tarballs, which can display all the patches that various |
64 |
>>> distros apply, as well as a download link for the patchsets |
65 |
>>> (hotlinked to the distro files where possible). |
66 |
>> |
67 |
>> Too complicated, and actually would not help me a single bit. |
68 |
> |
69 |
> Help *you*? I thought this was about helping the distros. If your |
70 |
> proposal is not about making our work easier, please don't waste our |
71 |
> time. |
72 |
> |
73 |
>>> Distro packagers are much more comfortable with downloading |
74 |
>>> patchsets from a foreign source than complete tarballs. |
75 |
>> |
76 |
>> man git-format-patch ;-p |
77 |
>> |
78 |
> |
79 |
> So why don't you submit that to bugzilla? |
80 |
|
81 |
Please don't assume replies are based solely on people not knowing the |
82 |
tools (git in this case). |
83 |
|
84 |
>>> I know you have spent a lot of time on this already, but please |
85 |
>>> understand it from where we stand. We're short on manpower, and |
86 |
>>> there's no real benefits of shifting our tarball source; OTOH there |
87 |
>>> are major disadvantages too unless we pitch in with manpower |
88 |
>>> ourselves. And honestly speaking, that manpower is better spent making |
89 |
>>> stuff work locally. |
90 |
>> |
91 |
>> Well, Gentoo is short of manpower ? hmm, perhaps some should think |
92 |
>> about why so many folks are resigning and so few fresh coming in |
93 |
>> (at least according to this lists traffic) ;-O |
94 |
|
95 |
This type of argument when you're trying to convince others to use your |
96 |
service is in the least a disservice to your purpose. |
97 |
|
98 |
> I'm beginning to think that you're not taking my honest advice very seriously. |
99 |
> |
100 |
>>> Please consider the "patch-website" idea above. We definitely need |
101 |
>>> someone to code it up, gather the source-package to distro patches |
102 |
>>> mappings, and advertise it. |
103 |
>> |
104 |
>> Actually, I once had somehing in that area, called "comprehensive |
105 |
>> source database", but unfurtinately it got lost in an disk array |
106 |
>> crash a few years ago, and I didnt find the time to rewrite it yet. |
107 |
>> |
108 |
>> Meanwhile I dont need it anymore, since I gave up maintaining |
109 |
>> plaintext patches in favour of git. And that makes my daily works |
110 |
>> _much_ easier. |
111 |
>> |
112 |
> |
113 |
> You don't need to maintain **anything** manually if you code the |
114 |
> website properly. That's the whole point. You get major benefits with |
115 |
> minimal long-term work which can be done by a single person in their |
116 |
> free time. |
117 |
> |
118 |
> This job is easily automated to simply aggregate links to patches |
119 |
> which all the distros manually publish themselves. For Gentoo, it's |
120 |
> the ebuilds; for Debian/Ubuntu, they actually publish the diffs[1]; |
121 |
> Fedora keeps its patches in a common CVS repo[2], etc etc. Once the |
122 |
> website is up and running, maintenance is minimal, and can be done by |
123 |
> a single person looking at it in their free time. |
124 |
> |
125 |
> 1. See packages.(debian|ubuntu).(org|com) |
126 |
> 2. cvs.fedoraproject.org/viewvc/ |
127 |
> |
128 |
|
129 |
- -- |
130 |
Regards, |
131 |
|
132 |
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org |
133 |
Gentoo- forums / Userrel / Devrel / KDE / Elections |
134 |
-----BEGIN PGP SIGNATURE----- |
135 |
Version: GnuPG v2.0.15 (GNU/Linux) |
136 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
137 |
|
138 |
iQIcBAEBAgAGBQJMOfchAAoJEC8ZTXQF1qEPoCcQAKlDi9d7GgZPK00kq+6lRZRF |
139 |
+JW5kTvOoOyu75X9nglzxKuJCWqOFMV6T1X5CvKOr/5XOJbdmAdrd7flSHxixlsI |
140 |
DZi+62u3at7rq26pPOpt5wCNdR+PVSvGp0J8Y+X1AtB8UpYk6P/3Zjqk1ZyS9HSp |
141 |
zqX4TCnEXOoQd6uNueiPh3qF7hr5F1dZSsqEaO99A9CVPwkGzLZE2/yyYDPB2ZU9 |
142 |
KqFdd+MyBpdgCOW02QjZAymKfn1C9sDjifWflj48mAhJEgRSMrAmf3/m8dzEy5qm |
143 |
T/qNGTgehN1cNgIREm4BBiwIwgYoYDUAr9plurgTDuJ6S8uSOUnk++8EF07uUnjo |
144 |
qTKR6Xxf86YN0zjwEgQhzfY8FfVvD26DJVg3woJSzrDM+ZGXfiCBjzX+tOpcRq54 |
145 |
vNE8+egMrce3V0ypI6iLc3fvY7pyOyRUuuwMT4vzau9fb7EL3YcGJvtXT+3ozm+n |
146 |
bXpp+wK8BJy7QRa3O+A6d9GbuLM8u+rsRw85Oc/j59rJ/5e+QWqOvg1su7p6bG4D |
147 |
rL26CxnRUMOAM9VtL2zfVa4rZTqsD1KVaT5RQ+u989P4FHJc+NcmLtE1cvV42iR7 |
148 |
GEl3fHinq37XiSug2YwTIO8pnc8O0jYibQw3IDmHlNdxFCZ3lgsC/Ir7mIUjkzgh |
149 |
3Gcc1L+1LNeYh+fF4wNN |
150 |
=Lpc6 |
151 |
-----END PGP SIGNATURE----- |