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 1OY98F-0005Rb-Gz for garchives@archives.gentoo.org; Mon, 12 Jul 2010 02:52:35 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F0E05E09E4; Mon, 12 Jul 2010 02:52:32 +0000 (UTC) Received: from s15216962.onlinehome-server.info (forum.psychotherapie.org [217.160.22.205]) by pigeon.gentoo.org (Postfix) with ESMTP id 4660EE06C1 for ; Mon, 12 Jul 2010 02:52:08 +0000 (UTC) Received: (from uucp@localhost) by s15216962.onlinehome-server.info (8.13.3/8.13.3) with UUCP id o6C2q7CH032406 for gentoo-dev@lists.gentoo.org; Mon, 12 Jul 2010 04:52:07 +0200 Received: (from weigelt@localhost) by nibiru.metux.de (8.12.10/8.12.10) id o6C2ir3Y025245 for gentoo-dev@lists.gentoo.org; Mon, 12 Jul 2010 04:44:53 +0200 Date: Mon, 12 Jul 2010 04:44:53 +0200 From: Enrico Weigelt To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [bugzilla-daemon@gentoo.org: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs] Message-ID: <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> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Terror: bin laden, kill bush, Briefbombe, Massenvernichtung, KZ, X-Nazi: Weisse Rasse, Hitlers Wiederauferstehung, 42, X-Antichrist: weg mit schaeuble, ausrotten, heiliger krieg, al quaida, X-Killer: 23, endloesung, Weltuntergang, X-Doof: wer das liest ist doof X-Archives-Salt: 51eb7fbd-13e8-45ae-90da-a3480de89fa2 X-Archives-Hash: 2194fee76b6695a74dc7262aa10cfc43 * 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. > I am *yet* to see a single reason for us to change how we work > other than "please use this since I've been putting a lot of > effort into it". I have no intention to urge you to use my approach, I'm just offering you my works, nothing more. > >> On a technical level, it's got serious security, trust, and > >> redundancy problems. > > > > Git makes that very easy ;-p > > > > No, it does not. The security problems come because you are the single > point of failure. Which SPOF ? man 1 git-cone ;-p > 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 ...): a) repository manipulation (directly changing objects): will be found out by git-gc. b) injecting changed upstream: you can easily compare my UPSTREAM.* tags against the real upstream's tarballs or vcs tags. BTW: as long as not all upstreams sign their releases, our trust relies just relies on their server's integrity (and the connection to them). c) manipulated tags: someone, perhaps myself overwrites other's tags use signed tags, and check the signatures (easily doable by a little shell script d) some vendor (possibly myself) adds crappy changes: you'll most likely have a look at the changes before cherry-picking them. > 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. > > If we're doing a good job (my generic fixes instead of distro- > > specfic dirty hacks) about 99% can be shared ;-p > > > > I'd advise you to take a look at the sort of patching Ubuntu/Debian > does, and then revisit that figure. You'll find it more along the > lines of 30%. I never claimed that Ubuntu does clean and generic fixes. BTW: Gentoo tends to have similar problems, just look at the zlib ebuild: >> # trust exit status of the compiler rather than stderr #55434 >> # -if test "`(...) 2>&1`" = ""; then >> # +if (...) 2>/dev/null; then >> sed -i 's|\&1`" = ""|\1 2>/dev/null|' configure || die >> sed -i -e '/ldconfig/d' Makefile* || die > >> A practical solution to the problem of patch sharing is to > >> have a website with a search interface for upstream source > >> tarballs, which can display all the patches that various > >> distros apply, as well as a download link for the patchsets > >> (hotlinked to the distro files where possible). > > > > Too complicated, and actually would not help me a single bit. > > Help *you*? I thought this was about helping the distros. Yes, I first want to solve my daily business problems, but in a way that other folks can benefit from my works. > >> Distro packagers are much more comfortable with downloading > >> patchsets from a foreign source than complete tarballs. > > > > man git-format-patch ;-p > > > > So why don't you submit that to bugzilla? Yet too complicated/work intensive to do this for each individual distro. It would be a completely different issue, if there was some robot interface for that. On the other hand, if you pull from my repo, you can easily hack up a little bot, which tells you when something happens (or even send you patches). > > 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. 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. > 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 ...) 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. cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------