[gentoo-dev] unsuscribe
-- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Alec Warner wrote: The fact that Gentoo can continue with the codebase is irrelevant. I think moreso the fact that a particular Package Manager would be the 'Gentoo Package Manager' means in my mind that Gentoo is responsible for said Package Manager. If someone were to slip evil code into said Package Manager and Gentoo released it; that would be bad. Note that with Portage, Gentoo could pull svn access for any individuals who commit such code. Gentoo have no gaurantee of that with an externally managed Manager as Gentoo has no control over the source repositories. If, by your comment above, Gentoo should maintain it's own branch of said package manager to insulate itself from issues such as the security issue defined above; well I think that may be one way to address the problem presented by Seemant. Come on, that's a bogus argument. By that logic, we should be maintaining our own branches of, say, sys-apps/shadow, since we don't control the upstream CVS repository. I think something that's installed in the base system set would also be perceived as something that Gentoo is responsible for, since we ship it in our stage tarballs, the basic building blocks of a Gentoo system. -- Mike Kelly signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: SCM choices
On Sat, 2007-03-31 at 11:52 +0200, Marijn Schouten (hkBst) wrote: So in light of all that I don't think it is wasteful to restart this discussion. I do. Want to bring it back up? Go perform some tests and report back with some data if you feel prior efforts weren't done properly or reproducible. My *entire* point was that *discussion* of this issue is worthless compared to numbers and data. I see no need to hear 300+ people tell everyone else their *opinion* on what they *think* is better. Seeing some actual data, though, should be definitely encouraged. 1) get commit access to the repository and start a branch in there. Merging may not be too hard, I don't really know. However CVS commit access is not something that is given lightly. It would vice versa also mean that you would have commit access to my stuff, which I might not like. Release Engineering has its own space for officially-released and in-progress media. Your stuff wouldn't really fall under that category, so there's no need for you to have commit access to the repository. Release Engineering holds final say on all changes and they need to go through Release Engineering for testing before they will be accepted. This is how all of our changes work and it's worked pretty well for us. 2) file bugs with patches attached. But maybe you just want to forget about releases until 2007.1 comes along once 2007.0 is finished. You are correct. Release Engineering is not concerned with the interim state of the tree, and therefore has no need for constantly updating the spec files. We focus our attention on the release snapshots and make changes based on said snapshot, not on the current state of the tree. We all have better things we would like to do than constantly update spec files. Now, if you're talking about working with Release Engineering during release times, that would be grand, but anything off-cycle wouldn't be of much interest for us. Also, remember that there's really no point in refreshing media on a constant basis. I could see refreshing it after a new kernel version goes stable, and that's about it. Anything else seems like a terrible waste of time and resources for minimal gain. In most cases, your CD wouldn't change at all from day to day. For QA purposes, I run builds year-round. I just don't release them because I don't test them thoroughly. 3) fork the code or convert the repository into a repo of my own. Even if I choose to use the same kind of repo (CVS in this case), then how hard will merging be? Again, this goes both ways. You don't merge. You would file a bug with the changes and we would either accept or deny the changes on a case-by-case basis. I hope I missed something here, but of the three the third looks the most appealing and likely with me forking into darcs probably. I don't think this issue would be here if the code were in a distributed SCM, but maybe by the time 2007.1 is due I will have amassed enough interesting changes that it is easier for you to then just clone my distributed repo ;P. Again, it is *very* unlikely. If you look at the changes in the minimal CD set between releases, you will see that it is extremely minimal, if changes are even made. We simply don't change things that work. The only changes that really go in are bug fixes. Are you saying that you're going to be tracking all of the release bugs and fixing only those? Are you planning on adding features? The former would be helpful to Release Engineering, the latter would not be nearly as useful to us unless they were absolutely compelling. So can we please discuss what distributed SCM is best for the tree or likely to be in the future and what hard data obtained with what tests should be gathered to rank SCMs and what feature differences there are and how much we should care about them? I don't get why you discuss a distributed SCM, then proceed to talk about minimal CD + releases stuff which has nothing to do with the main tree. We keep our spec files in CVS, but it isn't the same repository as the tree. If you're talking about changing the tree, then yes, you should be filing bugs and getting them fixed in the tree. I'm honestly not sure what exactly it is that you're trying to accomplish. Some additional explanation would be great. Again, if you want to see the tree converted to something else, you need to show compelling reasons and data *why* it should be done. Discussing it doesn't really show those things and lends itself to giving only beliefs, political or personal, about given SCM software. I honestly don't care what anybody *thinks* about any particular SCM. I am interested in the facts and numbers. I don't have much preference myself other than that I already know CVS/SVN. If we were to make a change, even to SVN, I'd like to see some well-thought-out reasons why and some numbers to back it up. -- Chris Gianelloni Release Engineering Strategic Lead
Re: [gentoo-dev] unsuscribe
Juan Pablo Olivera wrote: Try this: [EMAIL PROTECTED] That will work better for you. Well, after you confirm it anyway. ;-) Dale :-) :-) -- www.myspace.com/-remove-me-dalek1967 Copy n paste then remove the -remove-me- part. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Flourish Conference Reminder
On Sun, 2007-04-01 at 16:32 -0500, Samir Faci wrote: Sorry guys, I didn't think this would be considered spam, I was actually hoping some of the gentoo dev, if any are in the area would be interesting in participating and representing gentoo in the conference. Well, you should probably try contacting Gentoo's Events team at [EMAIL PROTECTED] or their PR team at [EMAIL PROTECTED] rather than sending a bulk email to a development list. I also think the large bold text probably put a few people off. I know it made me want to stab out my eyes and I quickly skipped past the message without even reading it or giving it a second thought. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [soc] Python bindings for Paludis
Mike Kelly wrote: Alec Warner wrote: The fact that Gentoo can continue with the codebase is irrelevant. I think moreso the fact that a particular Package Manager would be the 'Gentoo Package Manager' means in my mind that Gentoo is responsible for said Package Manager. If someone were to slip evil code into said Package Manager and Gentoo released it; that would be bad. Note that with Portage, Gentoo could pull svn access for any individuals who commit such code. Gentoo have no gaurantee of that with an externally managed Manager as Gentoo has no control over the source repositories. If, by your comment above, Gentoo should maintain it's own branch of said package manager to insulate itself from issues such as the security issue defined above; well I think that may be one way to address the problem presented by Seemant. Come on, that's a bogus argument. By that logic, we should be maintaining our own branches of, say, sys-apps/shadow, since we don't control the upstream CVS repository. I think something that's installed in the base system set would also be perceived as something that Gentoo is responsible for, since we ship it in our stage tarballs, the basic building blocks of a Gentoo system. Except we aren't the authors of sys-apps/shadow. sys-apps/shadow is not a Gentoo project. I think there is a difference. Take the issue with the ubuntu installer that left the root password in a log in /var. Who was responsible? Ubuntu. Why? Because it's their installer, their project. We don't endorse things like sys-apps/shadow; we just happen to use it. If we say 'Package X is the official manager', then to me that implies endorsement. A package manager is a solid part of Gentoo. Source based package management is a huge part of what separates us from all other distributions, I think that has some meaning, if not to you than to many of our users. If there was such a security problem with the official manager, who is responsible? Gentoo. Even if it's not really 'our' project. Because it's our manager. Not any other distros, but ours. -Alec -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: SCM choices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: On Sat, 2007-03-31 at 11:52 +0200, Marijn Schouten (hkBst) wrote: So in light of all that I don't think it is wasteful to restart this discussion. I do. Want to bring it back up? Go perform some tests and report back with some data if you feel prior efforts weren't done properly or reproducible. My *entire* point was that *discussion* of this issue is worthless compared to numbers and data. I see no need to hear 300+ people tell everyone else their *opinion* on what they *think* is better. Seeing some actual data, though, should be definitely encouraged. Again, if you want to see the tree converted to something else, you need to show compelling reasons and data *why* it should be done. Discussing it doesn't really show those things and lends itself to giving only beliefs, political or personal, about given SCM software. I honestly don't care what anybody *thinks* about any particular SCM. I am interested in the facts and numbers. I don't have much preference myself other than that I already know CVS/SVN. If we were to make a change, even to SVN, I'd like to see some well-thought-out reasons why and some numbers to back it up. I just don't think it is obvious what tests should be performed. Furthermore the difference between the different systems is not just performance, but also features. So we need to discuss what standards any candidate SCM should measure up to. I thought the shortcomings in features of CVS in comparison with SVN were understood. Given in turn SVN's shortcomings in comparison to distributed SCMs and the abundance and maturity of them it seems to me that the only decision to be made is what to switch to. I don't get why you discuss a distributed SCM, then proceed to talk about minimal CD + releases stuff which has nothing to do with the main tree. Just an example to demonstrate how non-distributed SCM impose artificial restrictions. You wanted to be convinced, right? I realize the specifics of the example, specifically the expected small extent of divergence, make this a bad example in practice. But think about the theory. But let me try again. Suppose you are developing an ebuild or are cooperating in developing an ebuild or set of ebuilds with eclasses such as happens now in overlays. Such overlays could just be branches in the same repository with easy merging between branches which preserves history. All with one tool. It would also empower people who don't have push access to the tree or to a specific overlay or to any overlay, by making it possible for them to do everything people with push access do except pushing, instead of also making it very hard to use the same SCM. - From some discussion on irc I learned that lack of tree and history slicing are two concerns of git's readyness. I hope to do some tests on the tree slicing soon. I also learned that darcs does not support enough architectures, most importantly mips. Therefore I'd like to know what architectures need to be supported by a candidate SCM. Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGEo81p/VmCx0OL2wRApQxAKCh+ZB64BnDId+ZLPDh2k3xxIoQFgCgsLTJ pFc/u9hEFshBUAIhXlvGgLk= =j+xm -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: SCM choices
On Tue, 03 Apr 2007 19:30:29 +0200 Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote: Therefore I'd like to know what architectures need to be supported by a candidate SCM. Oh that's an easy one. All arches that Gentoo supports. Also it needs to support FreeBSD :) Thanks Roy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: SCM choices
On Tue, 2007-04-03 at 19:30 +0200, Marijn Schouten (hkBst) wrote: I just don't think it is obvious what tests should be performed. Furthermore the difference between the different systems is not just performance, but also features. So we need to discuss what standards any candidate SCM should measure up to. No, we really don't. First off, let's look at things we know we need. This is pretty much the CVS feature set. Next, look at things we want. Does any SCM provide things we want? Now, I'm not going to reiterate all the junk people have said they want, since it's all archived for prosperity. Next, start comparing the things we *require* and the things we *want* in each SCM. Some good metrics people have already been using are server-side disk space, client-side disk space, bandwidth, time for checkout, time for commit, time for update... Also, remember that the needs of the few definitely doesn't outweigh the needs of the many. If 99.9% of the developer pool are doing only checkout/update/commit cycles, then having a 50% drop in performance or a 700% increase in disk usage only to gain features that don't affect the 99.9% make a migration no longer worth it. This is what I mean by using numbers to back up your ideas. I thought the shortcomings in features of CVS in comparison with SVN were understood. Given in turn SVN's shortcomings in comparison to distributed SCMs and the abundance and maturity of them it seems to me that the only decision to be made is what to switch to. What shortcomings, exactly? This is something that you have to quantify. CVS does $x CVS does not do $y I simply have not seen much of anything that would be useful to a large enough section of our developer pool to be worth the problems of a migration. About the only thing I see is svn cp to preserve history. I see lots of reasons for it in non-tree repositories, but little in the tree, which already has branches and tags disabled, among other things. I don't get why you discuss a distributed SCM, then proceed to talk about minimal CD + releases stuff which has nothing to do with the main tree. Just an example to demonstrate how non-distributed SCM impose artificial restrictions. You wanted to be convinced, right? I realize the specifics of the example, specifically the expected small extent of divergence, make this a bad example in practice. But think about the theory. OK. You weren't able to successfully demonstrate anything to me, then. I saw nothing in your mail that showed me why what you described would be a problem, especially considering the examples you used. But let me try again. Suppose you are developing an ebuild or are cooperating in developing an ebuild or set of ebuilds with eclasses such as happens now in overlays. Such overlays could just be branches in the same repository with easy merging between branches which preserves history. All with one tool. I guess I've just never had the need to do anything of the sort. I'm perfectly capable of using revision bumps and other methodologies already in use in the main tree in my overlays. Why do we need two sets of practices? Why do we need to modify the main tree to fit the model of the much smaller and less utilized overlays? It would also empower people who don't have push access to the tree or to a specific overlay or to any overlay, by making it possible for them to do everything people with push access do except pushing, instead of also making it very hard to use the same SCM. Like what? Qualify your statements. I don't use other SCM software, like many of our developers/users. If you're going to try to tell me that I can't do something I don't want to do, or don't even know is possible, you won't convince me without compelling examples. My point is that instead of discussing all of this yet again, you get together some features you think are required and why, as well as some performance metrics, as I stated above, and try approaching this from a more technical front and less of an emotional one. Like I said, I don't care which SCM you like. You shouldn't care which one I like. There's no way we could ever please everyone, so why even bother to switch? - From some discussion on irc I learned that lack of tree and history slicing are two concerns of git's readyness. I hope to do some tests on the tree slicing soon. Excellent. This was something that wasn't available before, so if you're wanting to test it with a newer git that does this well, then that is something we can look at as something that has changed. I also learned that darcs does not support enough architectures, most importantly mips. Therefore I'd like to know what architectures need to be supported by a candidate SCM. Ideally, all of them. I would consider dropping support for an architecture we support currently a strong reason to never consider that SCM. If I cannot commit from the machine I'm doing a KEYWORD
[gentoo-dev] Re: SCM choices
Chris Gianelloni [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 03 Apr 2007 14:54:26 -0400: Now, I'm not going to reiterate all the junk people have said they want, since it's all archived for prosperity. Now /that/ was worth the read. Interesting eggcorn[1] there. =8^) FWIW, Google lists 27 hits for archived for prosperity, 11,400 hits for archived for posterity. You've made my day, thanks! =8^) [1] http://en.wiktionary.org/wiki/eggcorn -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@gentoo.org mailing list
