From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1OYHc3-0007dB-OM for garchives@archives.gentoo.org; Mon, 12 Jul 2010 11:55:55 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2D707E09EE; Mon, 12 Jul 2010 11:55:52 +0000 (UTC) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 93A0EE096B for ; Mon, 12 Jul 2010 11:55:13 +0000 (UTC) Received: by gxk28 with SMTP id 28so3224825gxk.40 for ; Mon, 12 Jul 2010 04:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=B87EF4qzPZRpIdporuyzYb9/pDCE9FueXn0USoBwecQ=; b=mAYh5gY+c6FVJiuERFJ58R3EV3aY0RsfKrGXlYQGSfwKVZ/iSc0rrgjadGX5paT0FC 2c6CE0pbJ3vmuqiDapBmje4a1+4drZKGXbmuIWH5gsUUtOBqaLtdZ6gGyiu9qq3KsjIB kFZrnnTjC1AizjZa35GJlWEVchI4+Agjy4Ms4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=Q3l/Bw+uF28HYsb0xY3pjGaNvVUwEnm13SG5KfCGHyNCXPAvLNKQ3hRxnvQoNh1dtl sNaev29MbtezVINErJgrSQp5dTcazu4matCo6Otm4noildfLUmejrdjUUfrLw87nPgmx YUsE6LVcHMW6kr0aaxtLFNCNUGBxCsmEWVD4g= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.151.78.6 with SMTP id f6mr5077618ybl.52.1278935713158; Mon, 12 Jul 2010 04:55:13 -0700 (PDT) Sender: nirbheek.chauhan@gmail.com Received: by 10.151.10.11 with HTTP; Mon, 12 Jul 2010 04:55:13 -0700 (PDT) In-Reply-To: <20100712024452.GC30793@nibiru.local> References: <20100707225651.GA8832@nibiru.local> <4C35099C.2010202@gentoo.org> <20100710161343.GC15161@nibiru.local> <1278831707.1752.17.camel@localhost> <20100711070902.GA30793@nibiru.local> <20100711095300.GB30793@nibiru.local> <20100712024452.GC30793@nibiru.local> Date: Mon, 12 Jul 2010 17:25:13 +0530 X-Google-Sender-Auth: QxIEjK39dNqbLxOni0LAIZ6ktFU Message-ID: Subject: Re: [gentoo-dev] [bugzilla-daemon@gentoo.org: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs] From: Nirbheek Chauhan To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: c7e60355-8947-48f8-8d45-44667fc9333e X-Archives-Hash: e16fe8e95e32004de9768786fa0c21d5 On Mon, Jul 12, 2010 at 8:14 AM, Enrico Weigelt wrote: > * Nirbheek Chauhan schrieb: >> > Thats not even necessary. They just should use the infrastructure, >> > as described in my paper. So everyone can easily set up automatic >> > notifications, cherry-pick, etc, etc. >> >> Why should we? > > To make tracking and applying other's changes much easier. > Currently it's quite work intensive to do so. > > If - hypothetically - everyone work within an git repo, using a > normalized naming/versioning scheme, it is trivial to set some > little tracking system, informing package maintainers if something > happens (new upstream, new patches from distro XYZ, etc). And > we can inspect that easily, take patches, etc, etc, using > standard git tools. > Ah, so you want us to use your git repos as patch managers? That clears up a few things. >> No, it does not. The security problems come because you are the single >> point of failure. > > Which SPOF ? > > man 1 git-cone ;-p > So you don't want us to use your tarballs? That's a relief. If you'd tell us on the bugs you opened that you want us to start using your git repos, and add another layer of abstraction to our patch process, say so! Then we can clearly say why we don't want to use them. >> The trust problems come because we have no reason to trust you. > > You dont have to trust me. Just let me point out some possible > leak points (if I missed some, feel free to add them ...): > [snip info about basic git working] > =C2=A0 BTW: as long as not all upstreams sign their releases, our trust > =C2=A0 relies just relies on their server's integrity (and the connection > =C2=A0 to them). > Difference is that there are multiple upstreams while you are one, and the larger upstreams (such as GNOME/KDE/FDO) have a professional admins devoted to the security of their machines, while you're using a free service on a public git website. [snip proposal about us changing our workflow] > d) some vendor (possibly myself) adds crappy changes: you'll most > =C2=A0 likely have a look at the changes before cherry-picking them. > Makes sense. If we use your git repos for pulling patches we'll verify them before applying them locally. >> The redundancy problems come because if your hosting goes >> down or you lose interest, we're left high and dry. > > That wouldn't affect your clones. You simply won't get anything > new from my site anymore. > Of course, since now I understand that you don't want us to use your tarballs, the hosting problem is a non-issue. Oh wait, I just remembered. All the ebuilds that you submitted use *your* tarballs. And since you want us to use snapshot tarballs, the same old problems of trust, security, redundancy come into play. If you went away, all of them would break and we would need to go through each and every ebuild, fix the SRC_URI to point back to upstream, and apply the patches the way we do now. Please decide if you want us to use your git repos as patch aggregators or as snapshot tarball sources. Although, the question is quite futile. The latter is completely unacceptable, and the former is a major change in workflow and a dependency on you that few (if any) will accept. >> > Meanwhile I dont need it anymore, since I gave up maintaining >> > plaintext patches in favour of git. And that makes my daily works >> > _much_ easier. >> > >> >> You don't need to maintain **anything** manually if you code the >> website properly. That's the whole point. You get major benefits with >> minimal long-term work which can be done by a single person in their >> free time. > > First, I have to build that website and maintain it over a long time. > Then I'll have to do a lot of advertisement work to get people to > actually push their patches there. > Why would they push their patches? You'd be an RSS reader. An aggregator, You wouldn't need anyone to push anything. > On the other hand, the git-based infrastructure is already there, > people can use it right now. And it gives my exactly what I need. > So I prefer spending my time in advocating this one. > Yes, in a sense you've already made the patch aggregation website. Except you use git to store whatever patches you get manually from the various sources. In essence, you've traded lots of short-term work for extended work of manual patch aggregation and integration. Sure, that's your choice, but that ensures that we will never make our workflow dependent on your continued interest in the project. >> This job is easily automated to simply aggregate links to patches >> which all the distros manually publish themselves. > > It's not that simple. Many distros don't even do proper patches, > instead wildly copy over or directly sed certain sourcesfiles, > or even (like Debian) use their own broken tarballs. > (the worst srcpkg I've ever seen is Debian's mysql-5.0.32 ...) > *Shrug* you aggregate whatever is there in patch form. Refinements can happen later. The same problem is also present in your current approach, but that didn't stop you. > And even *if* we assume, that everyone's just doing patches, we > still need to transform the everbody's strange (often not even > linear) versioning schemes. One of OSS-QMs primary goals is to > use a strictly normalized/canonical naming/versioning scheme in > the primay source repository. > I'm reading this as: "I want everyone to change to my way of doing things because it supposedly makes patch management easier". But since you say that you're only offering a service, and we aren't compelled to use it, I won't feel bad about firmly saying "No thanks. Most of us see no net benefit in relation to the proposed change in workflow". On the other hand, if you propose benefits w/o a change of workflow, I'm sure many more people will be interested. Otherwise, all your current efforts *will* go to waste. Infact, I've explained this twice now[1], and you should really understand that people will not change their workflow unless you give them a very good reason to do so. "Possibly better patch management as long as I'm interested in it" is not a valid reason (to say the least). 1. This means I won't try to explain it again. --=20 ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team