Gentoo Archives: gentoo-dev

From: "Jorge Manuel B. S. Vicetto" <jmbsvicetto@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [bugzilla-daemon@gentoo.org: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]
Date: Sun, 11 Jul 2010 16:54:22
Message-Id: 4C39F722.3050809@gentoo.org
In Reply to: Re: [gentoo-dev] [bugzilla-daemon@gentoo.org: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs] by Nirbheek Chauhan
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-----

Replies