1 |
On Mon, Jul 12, 2010 at 8:14 AM, Enrico Weigelt <weigelt@×××××.de> wrote: |
2 |
> * Nirbheek Chauhan <nirbheek@g.o> schrieb: |
3 |
>> > Thats not even necessary. They just should use the infrastructure, |
4 |
>> > as described in my paper. So everyone can easily set up automatic |
5 |
>> > notifications, cherry-pick, etc, etc. |
6 |
>> |
7 |
>> Why should we? |
8 |
> |
9 |
> To make tracking and applying other's changes much easier. |
10 |
> Currently it's quite work intensive to do so. |
11 |
> |
12 |
> If - hypothetically - everyone work within an git repo, using a |
13 |
> normalized naming/versioning scheme, it is trivial to set some |
14 |
> little tracking system, informing package maintainers if something |
15 |
> happens (new upstream, new patches from distro XYZ, etc). And |
16 |
> we can inspect that easily, take patches, etc, etc, using |
17 |
> standard git tools. |
18 |
> |
19 |
|
20 |
Ah, so you want us to use your git repos as patch managers? That |
21 |
clears up a few things. |
22 |
|
23 |
>> No, it does not. The security problems come because you are the single |
24 |
>> point of failure. |
25 |
> |
26 |
> Which SPOF ? |
27 |
> |
28 |
> man 1 git-cone ;-p |
29 |
> |
30 |
|
31 |
So you don't want us to use your tarballs? That's a relief. If you'd |
32 |
tell us on the bugs you opened that you want us to start using your |
33 |
git repos, and add another layer of abstraction to our patch process, |
34 |
say so! Then we can clearly say why we don't want to use them. |
35 |
|
36 |
>> The trust problems come because we have no reason to trust you. |
37 |
> |
38 |
> You dont have to trust me. Just let me point out some possible |
39 |
> leak points (if I missed some, feel free to add them ...): |
40 |
> |
41 |
|
42 |
[snip info about basic git working] |
43 |
> BTW: as long as not all upstreams sign their releases, our trust |
44 |
> relies just relies on their server's integrity (and the connection |
45 |
> to them). |
46 |
> |
47 |
|
48 |
Difference is that there are multiple upstreams while you are one, and |
49 |
the larger upstreams (such as GNOME/KDE/FDO) have a professional |
50 |
admins devoted to the security of their machines, while you're using a |
51 |
free service on a public git website. |
52 |
|
53 |
[snip proposal about us changing our workflow] |
54 |
|
55 |
> d) some vendor (possibly myself) adds crappy changes: you'll most |
56 |
> likely have a look at the changes before cherry-picking them. |
57 |
> |
58 |
|
59 |
Makes sense. If we use your git repos for pulling patches we'll verify |
60 |
them before applying them locally. |
61 |
|
62 |
>> The redundancy problems come because if your hosting goes |
63 |
>> down or you lose interest, we're left high and dry. |
64 |
> |
65 |
> That wouldn't affect your clones. You simply won't get anything |
66 |
> new from my site anymore. |
67 |
> |
68 |
|
69 |
Of course, since now I understand that you don't want us to use your |
70 |
tarballs, the hosting problem is a non-issue. |
71 |
|
72 |
Oh wait, I just remembered. All the ebuilds that you submitted use |
73 |
*your* tarballs. And since you want us to use snapshot tarballs, the |
74 |
same old problems of trust, security, redundancy come into play. If |
75 |
you went away, all of them would break and we would need to go through |
76 |
each and every ebuild, fix the SRC_URI to point back to upstream, and |
77 |
apply the patches the way we do now. |
78 |
|
79 |
Please decide if you want us to use your git repos as patch |
80 |
aggregators or as snapshot tarball sources. Although, the question is |
81 |
quite futile. The latter is completely unacceptable, and the former is |
82 |
a major change in workflow and a dependency on you that few (if any) |
83 |
will accept. |
84 |
|
85 |
>> > Meanwhile I dont need it anymore, since I gave up maintaining |
86 |
>> > plaintext patches in favour of git. And that makes my daily works |
87 |
>> > _much_ easier. |
88 |
>> > |
89 |
>> |
90 |
>> You don't need to maintain **anything** manually if you code the |
91 |
>> website properly. That's the whole point. You get major benefits with |
92 |
>> minimal long-term work which can be done by a single person in their |
93 |
>> free time. |
94 |
> |
95 |
> First, I have to build that website and maintain it over a long time. |
96 |
> Then I'll have to do a lot of advertisement work to get people to |
97 |
> actually push their patches there. |
98 |
> |
99 |
|
100 |
Why would they push their patches? You'd be an RSS reader. An |
101 |
aggregator, You wouldn't need anyone to push anything. |
102 |
|
103 |
> On the other hand, the git-based infrastructure is already there, |
104 |
> people can use it right now. And it gives my exactly what I need. |
105 |
> So I prefer spending my time in advocating this one. |
106 |
> |
107 |
|
108 |
Yes, in a sense you've already made the patch aggregation website. |
109 |
Except you use git to store whatever patches you get manually from the |
110 |
various sources. In essence, you've traded lots of short-term work for |
111 |
extended work of manual patch aggregation and integration. Sure, |
112 |
that's your choice, but that ensures that we will never make our |
113 |
workflow dependent on your continued interest in the project. |
114 |
|
115 |
>> This job is easily automated to simply aggregate links to patches |
116 |
>> which all the distros manually publish themselves. |
117 |
> |
118 |
> It's not that simple. Many distros don't even do proper patches, |
119 |
> instead wildly copy over or directly sed certain sourcesfiles, |
120 |
> or even (like Debian) use their own broken tarballs. |
121 |
> (the worst srcpkg I've ever seen is Debian's mysql-5.0.32 ...) |
122 |
> |
123 |
|
124 |
*Shrug* you aggregate whatever is there in patch form. Refinements can |
125 |
happen later. The same problem is also present in your current |
126 |
approach, but that didn't stop you. |
127 |
|
128 |
> And even *if* we assume, that everyone's just doing patches, we |
129 |
> still need to transform the everbody's strange (often not even |
130 |
> linear) versioning schemes. One of OSS-QMs primary goals is to |
131 |
> use a strictly normalized/canonical naming/versioning scheme in |
132 |
> the primay source repository. |
133 |
> |
134 |
|
135 |
I'm reading this as: "I want everyone to change to my way of doing |
136 |
things because it supposedly makes patch management easier". But since |
137 |
you say that you're only offering a service, and we aren't compelled |
138 |
to use it, I won't feel bad about firmly saying "No thanks. Most of us |
139 |
see no net benefit in relation to the proposed change in workflow". |
140 |
|
141 |
On the other hand, if you propose benefits w/o a change of workflow, |
142 |
I'm sure many more people will be interested. Otherwise, all your |
143 |
current efforts *will* go to waste. Infact, I've explained this twice |
144 |
now[1], and you should really understand that people will not change |
145 |
their workflow unless you give them a very good reason to do so. |
146 |
"Possibly better patch management as long as I'm interested in it" is |
147 |
not a valid reason (to say the least). |
148 |
|
149 |
|
150 |
1. This means I won't try to explain it again. |
151 |
|
152 |
-- |
153 |
~Nirbheek Chauhan |
154 |
|
155 |
Gentoo GNOME+Mozilla Team |