From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4201 invoked by uid 1002); 2 Jul 2003 11:29:07 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 8289 invoked from network); 2 Jul 2003 11:29:07 -0000 From: Alastair Tse To: gentoo-dev@gentoo.org In-Reply-To: <20030702054221.GR1912@squish.home.loc> References: <87r85fba2o.fsf@killr.ath.cx> <1056840024.14725.62.camel@nosferatu.lan> <200306291512.46271.pauldv@gentoo.org> <20030702054221.GR1912@squish.home.loc> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hqsEJvyTakFpJLc88qp2" Message-Id: <1057145341.10019.46.camel@huggins.eng.cam.ac.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 02 Jul 2003 12:29:02 +0100 X-Cam-ScannerAdmin: mail-scanner-support@ucs.cam.ac.uk X-Cam-AntiVirus: Not scanned X-Cam-SpamDetails: scanned, SpamAssassin (score=-7.4, required 10, EMAIL_ATTRIBUTION, IN_REP_TO, PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_XIMIAN) Subject: Re: [gentoo-dev] Re: Public Relations X-Archives-Salt: 0a49f400-9a81-4815-95dd-4b340911425e X-Archives-Hash: ffb773df0bc06166b017c1be39006e73 --=-hqsEJvyTakFpJLc88qp2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2003-07-02 at 06:42, Paul wrote: > I have been conditioned to not submit ebuilds anymore, after > having submitted them regularly for some time; (I touch upon this > in bug 6808) I still hope to continue contributing bugs, Hi Paul, I've always tried to stay out of this "-core being open" debate because I too don't feel much either way. But that bug reference has pushed me to answer some of your concerns in this email. Comment on the your concerns about submitted ebuilds being ignored. At least on all the bugs I'm assigned, I _try_ to give feedback whenever it is possible, say what is holding up an ebuild going into portage, and be frank about what I think about the ebuild or the fitness of the application/library. Of course, you'll find exceptions to that comments if you go thru all my bugs :P In this case with gbonds, given that most, if not all, devs in gnome@gentoo.org are not US citizens and have no US bond. It was very difficult for us to support the ebuild to any degree. With committing the ebuild, comes responsibility and expectation that it would work. For example, similar situation I encounter now is I'm maintaining gphoto2/gtkam suite even though I have no digital camera compatible with that. Users come to me with bugs about it, and I can't do any real bugfixing on it. Sure it compiles, installs, and launches, but I can't verify any of the functionality. Maybe we really need dedicated users who do commit to being responsible for a particular package because they are very familiar with it, and actively submit version updates, help to debug problems with the package, etc. We don't have a system for this right now, although some time previously, we had the idea of "watchers" who would be similar to that type of user. But I don't know what happened to the idea or why it was abandoned. > preferably with patches. (although I often have better luck just > pushing them upstream.) This is ok for me, since writing ebuilds Pushing patches upstream is always easier, because they'll either be rejected and accepted. The problem with us maintaining patches that are not officially accepted is that the developers for the package will blame us for modifying their app/library and refuse to support Gentoo users, leaving a sour taste in both the developer's and user's mouth. > Instead of tortured analogies, just say it the way it > is; "we want core closed, and if you dont like it, you are free > to choose another distribution, or fork..." I'm very certain that has never been the view of the dev-team. I've certainly not encountered anyone who has said anything similar to this. > organisation. (Ive seen it on my local LUG list-- people saying > 'Ive heard this and that and this; maybe youd better think twice > before commiting to Gentoo...') That is to say, these feelings > and doubts are very real, and I hope that even though core > members find them baseless, that they find a way to communicate > that without seeming so condescending. Well, distro wars are what LUGs are about, or that's what I've heard :) Anyway, I'll have my small comment about -core opening up. I could write a whole essay if I wanted to. So, if we do open up -core, what is to say that devs would not push inter-dev communication on contentious issues to private CC lists, or a gentoo-core-core? Also, how open do these lists have to be? Would people comprimise on an archive that just lists the subjects discussed on -core? This would alleviate "security matters" being exposed because only the topic would not provide enough details for anyone to pre-emptively exploit, or would it? On the concluding note, before I became a dev, I didn't even know a -core list existed, and to be honest, I didn't even care. What I was trying to do was just make the distro I was using better. Getting involved with a distro is more than reading mail archives of -core, getting involved is actually contributing to the distro or help other users. I understand this issue will never go away. Maybe someone with enough time on their hands would actually write a summary on all the arguments presented since the beginning of time about -core. That would be an interesting read :) Cheers, --=20 Alastair 'liquidx' Tse >> Gentoo Developer >> http://www.liquidx.net/ | http://cvs.gentoo.org/~liquidx/ >> GPG Key : http://cvs.gentoo.org/~liquidx/liquidx_gentoo_org.asc >> FingerPrint : 579A 9B0E 43E8 0E40 EE93 BB1C 38CE 1C7B 3907 14F6 --=-hqsEJvyTakFpJLc88qp2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA/AsH9OM4cezkHFPYRAr+0AKDHJ17RTs1WtQkdrLMwxV0xEj659ACgsTR0 7MFO8DfGXcRIQBnKEi2/vKA= =1kH5 -----END PGP SIGNATURE----- --=-hqsEJvyTakFpJLc88qp2--