1 |
* Nirbheek Chauhan <nirbheek@g.o> schrieb: |
2 |
|
3 |
> Ah, so you want us to use your git repos as patch managers? That |
4 |
> clears up a few things. |
5 |
|
6 |
I dont want you to use *my* repos. But I'd like to advocate git-based |
7 |
workflows (eg. downstream branches w/ rebase, etc) instead of loose |
8 |
patches. And I'm offering you an proven model for that. |
9 |
|
10 |
> >> No, it does not. The security problems come because you are the single |
11 |
> >> point of failure. |
12 |
> > |
13 |
> > Which SPOF ? |
14 |
> > |
15 |
> > man 1 git-cone ;-p |
16 |
> > |
17 |
> |
18 |
> So you don't want us to use your tarballs? |
19 |
|
20 |
Why still using tarballs at all (if the UPSTREAM.* branches actually |
21 |
come from tarballs is a different topic) ? Even on projects w/ heavy |
22 |
change rates, eg. the Linux kernel, the git repo isn't much larger |
23 |
than a release tarball. (and here, the vast majority is shared between |
24 |
several kernel types, eg. vanilla <-> ovz <-> xen). |
25 |
|
26 |
Tarballs provide only work on the granularity of one big tree at once, |
27 |
so support only one operation: fetch a whole tree at once. |
28 |
No differential transmissions or storage, no changesets, etc, etc. |
29 |
|
30 |
> > BTW: as long as not all upstreams sign their releases, our trust |
31 |
> > relies just relies on their server's integrity (and the connection |
32 |
> > to them). |
33 |
> |
34 |
> Difference is that there are multiple upstreams while you are one, and |
35 |
> the larger upstreams (such as GNOME/KDE/FDO) have a professional |
36 |
> admins devoted to the security of their machines, while you're using a |
37 |
> free service on a public git website. |
38 |
|
39 |
I never said, that I want to be your (only) upstream. Again: all I'm |
40 |
offering is a generic model (and a fist reference implementation). |
41 |
|
42 |
> > d) some vendor (possibly myself) adds crappy changes: you'll most |
43 |
> > likely have a look at the changes before cherry-picking them. |
44 |
> |
45 |
> Makes sense. If we use your git repos for pulling patches we'll verify |
46 |
> them before applying them locally. |
47 |
|
48 |
Right. And you would put your changes in your repos and automatically |
49 |
pushing it back to the concentrated repository, and other distros would |
50 |
do the same. So in the end, everybody still has his own repo, but also |
51 |
everything's collected in a central place. |
52 |
|
53 |
> > That wouldn't affect your clones. You simply won't get anything |
54 |
> > new from my site anymore. |
55 |
> |
56 |
> Of course, since now I understand that you don't want us to use your |
57 |
> tarballs, the hosting problem is a non-issue. |
58 |
|
59 |
Exactly. |
60 |
|
61 |
> Oh wait, I just remembered. All the ebuilds that you submitted use |
62 |
> *your* tarballs. And since you want us to use snapshot tarballs, the |
63 |
> same old problems of trust, security, redundancy come into play. |
64 |
|
65 |
Just make your own repo, maybe put into into an simple dns-based |
66 |
cluster (multiple a-records), and send me the pointer - so I'll give |
67 |
you a fixed ebuild. Trivial. |
68 |
|
69 |
> Please decide if you want us to use your git repos as patch |
70 |
> aggregators or as snapshot tarball sources. |
71 |
|
72 |
Please differentiate between the model and the concrete implementation. |
73 |
The model just specifies the basic logic structure, eg. naming etc. |
74 |
But the infrastructure is an different issue. You'd most likely have |
75 |
your own repos, but I'd like to have your refs automatically pushed |
76 |
(within your namespace) into my aggregator repos. |
77 |
|
78 |
> > First, I have to build that website and maintain it over a long time. |
79 |
> > Then I'll have to do a lot of advertisement work to get people to |
80 |
> > actually push their patches there. |
81 |
> > |
82 |
> |
83 |
> Why would they push their patches? You'd be an RSS reader. An |
84 |
> aggregator, You wouldn't need anyone to push anything. |
85 |
|
86 |
Assuming they all publish their patches via RSS-feeds. |
87 |
|
88 |
And still this would only operate on single patches, not changesets |
89 |
and branches w/ histories. |
90 |
|
91 |
> > On the other hand, the git-based infrastructure is already there, |
92 |
> > people can use it right now. And it gives my exactly what I need. |
93 |
> > So I prefer spending my time in advocating this one. |
94 |
> |
95 |
> Yes, in a sense you've already made the patch aggregation website. |
96 |
> Except you use git to store whatever patches you get manually from |
97 |
> the various sources. |
98 |
|
99 |
No, I've made a branch aggregator. Git does not store patches, it |
100 |
stores histories of trees. Thats completely different, see above. |
101 |
|
102 |
> > It's not that simple. Many distros don't even do proper patches, |
103 |
> > instead wildly copy over or directly sed certain sourcesfiles, |
104 |
> > or even (like Debian) use their own broken tarballs. |
105 |
> > (the worst srcpkg I've ever seen is Debian's mysql-5.0.32 ...) |
106 |
> |
107 |
> *Shrug* you aggregate whatever is there in patch form. Refinements |
108 |
> can happen later. |
109 |
|
110 |
I could only aggregate patches, not other changes (eg. those done |
111 |
by those ugly sed hacks), and also missing the right apply order. |
112 |
So I'd loose a lot of important information. |
113 |
|
114 |
> The same problem is also present in your current approach, but |
115 |
> that didn't stop you. |
116 |
|
117 |
Right, that's why I'd people to use a proper vcs from start up, |
118 |
and I'll step by step tweak certain packaging systems to create |
119 |
git commits. (eg. a tweaked portage could import epatches directly |
120 |
into git and also commits between all commands that might change |
121 |
the tree, within the src_unpack stage). |
122 |
|
123 |
> On the other hand, if you propose benefits w/o a change of workflow, |
124 |
> I'm sure many more people will be interested. |
125 |
|
126 |
The major benefit is that changesets can be easily shared between |
127 |
various distros and upstreams, up to fully notifications, etc. |
128 |
|
129 |
|
130 |
cu |
131 |
-- |
132 |
---------------------------------------------------------------------- |
133 |
Enrico Weigelt, metux IT service -- http://www.metux.de/ |
134 |
|
135 |
phone: +49 36207 519931 email: weigelt@×××××.de |
136 |
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 |
137 |
---------------------------------------------------------------------- |
138 |
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme |
139 |
---------------------------------------------------------------------- |