Re: [gentoo-dev] Proposal for how to handle stable ebuilds
Why it's so hard not to delete ebuilds from the tree? Also it was already discussed that if maintainer wishes he/she could drop some keywords from old ebuild, e.g. if you have more recent version of package stabilized on arch, just drop arch keyword from the old ebuild. В Пнд, 10/11/2008 в 20:21 -0500, Richard Freeman пишет: I guess the question is whether package maintainers should be forced to maintain packages that are outdated by a significant period of time. Suppose something breaks a package that is 3 versions behind stable on all archs but one (where it is the current stable). Should the package maintainer be required to fix it, rather than just delete it? I suspect that the maintainer would be more likely to just leave it broken, which doesn't exactly leave things better-off for the end users. The package maintainer just should add depend on stabilization bug and leave resolution of the issue to arch team. Package maintainer already fixed things on his end so he has nothing to do... -- Peter.
Re: [gentoo-dev] Proposal for how to handle stable ebuilds
Mark Loeser wrote: Jose Luis Rivero [EMAIL PROTECTED] said: Mark, I think you are looking at the problem only with the ebuild maintainer hat put on. We have other players in our business, being one of them the users. This policy would bring too many problems to them so .. nono by my side. I purposely did this. I like the proposal, but I also know that it has a lot of problems. It was better than sending something out asking what people think though. Indeed. I would prefer to analyze the causes of the slacker arch (manpower, hardware, etc) and if we are not able to solve the problem by any way (asking for new devs, buying hardware, etc) go for mark it as experimental and drop all stable keywords. This is one way to resolve it. We need to establish how an arch gets pushed to experimental and how maintainers need to deal with that though. An example is removing the only version of a package that works on that specific arch, is this a problem if the arch is declared to be experimental? If this is the path we want to go down, lets set up some rules for how to handle experimental archs and what it means to go from stable-experimental and experimental-stable. Now we are thinking the same, brother. Clear procedures and rules for moving an arch to experimental and what keyword policy applies to experimental. Also, what is needed to allow an experimental arch to start its stable branch and be sure we are not going to be moving from experimental - stable every month. If someone want to start thinking more seriously about this, count me in. -- Jose Luis Rivero [EMAIL PROTECTED] Gentoo/Alpha Gentoo/Doc
Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds
On Tue, 2008-11-11 at 17:26 +, Duncan wrote: Jeroen Roovers [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 11 Nov 2008 17:24:50 +0100: Words like production, critical and important can be applied as easily to the state of a company's or nation's system as to a single person's. Yes, but it's a relative thing. They obviously do what they can with the resources they have (are willing to dedicate). We do the same. A user's single system will absolutely be important to him, no doubt about it, but if he doesn't believe it worth superhuman feats or prioritizing to ensure it's safety, neither should we. I think I understand what you mean here, but it's not what you wrote as best as I can tell. As a developer, I believe it is my responsibility to work a bit harder just so that the users don't have to resort to 'superhuman feats' to keep their systems running. I do agree that no matter what we provide, all users (including ourselves) will have to expend some effort to take advantage of it. No, we don't go around purposefully breaking things, but both he and we have limits to our resources and certain priorities in their allocation, and if he's not placing undue priority on the safety of his machine, why is it even a question if we will? The presumption should be actions within the bounds of rational reality and prioritization of resources for both users and their distribution, us. No more, no less. IOW, I'd have agreed if the point was that it's a machine that's useful to the user and that he doesn't want broken, and we should behave accordingly, but the triple emphasis of important, production, critical, seemed a bit undue for the lengths to which an ordinary user goes or the priority he reveals by his own actions. And if his actions reveal a SERIOUS priority in the area, than he's already covered by definition. That's all I was saying. Regards, Ferris -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds
On Tue, 11 Nov 2008 16:06:02 + (UTC) Duncan [EMAIL PROTECTED] wrote: If it's a production, critical, important system, then what is one doing installing updates on it directly without verifying them on a generally identical test system first? Now you're ridiculing the idea of having a production/ critical/ important system. Most of our users probably use a single Gentoo machine (I see many cases where users have multiple machines, but only one running Gentoo, or have one machine running several operating systems), and for them an important system is one that they cannot readily replace. Words like production, critical and important can be applied as easily to the state of a company's or nation's system as to a single person's. The stable branch has never been about commercial systems and their stringent requirements[1] - it's all about this level of quality that has users up in arms about one package blocking another or one package requiring half the system to be rebuilt at a rate of no more than once a year[2]. Kind regards, jer [1] We've had calls for an über-stable project in the past that would lock down versions and backport patches for enterprise systems. [2] I.e. when we break the promise of [3]. ]3] http://www.gentoo.org/main/en/philosophy.xml
[gentoo-dev] Re: Proposal for how to handle stable ebuilds
Jeroen Roovers [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 11 Nov 2008 19:12:41 +0100: You did it again in the IOW quotation above explaining it as a triple emphasis instead of what it was intended to denote, namely as a few possible examples of the meaning of stability. In that case, I misread, as I interpreted the triple as emphasis, not alternatives. If it was intended as alternatives, then yes, it makes sense. Thanks. I wasn't seeing the alternatives view at all (obviously). -- 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
Re: [gentoo-dev] Proposal for how to handle stable ebuilds
Richard Freeman wrote: Jose Luis Rivero wrote: I would prefer to analyze the causes of the slacker arch (manpower, hardware, etc) and if we are not able to solve the problem by any way (asking for new devs, buying hardware, etc) go for mark it as experimental and drop all stable keywords. How is that better? Instead of dropping one stable package you'd end up dropping all of them. A user could accept ~arch and get the same behavior without any need to mark every other package in the tree unstable. Accept ~arch for the random package which has lost the stable keyword a random day? And next week .. which is going to be the next? The key is the concept 'stable' and what you hope of it. A long/middle-term solution for arches with very few resources instead of generating problems to users seems a much better approach to me. An arch could put a note to that effect in their installation handbook. The user could then choose between a very narrow core of stable packages or a wider universe of experimental ones. Mixing software branches is very easy in the Gentoo world but it has some problems. Are you going to install in your stable (production, critial, important,...) system a combination of packages not tested before? Because the arch teams or the maintainers are not going to test every posible combination of core stable + universe of experimental packages. This is why branches exists. I guess the question is whether package maintainers should be forced to maintain packages that are outdated by a significant period of time. Suppose something breaks a package that is 3 versions behind stable on all archs but one (where it is the current stable). Should the package maintainer be required to fix it, rather than just delete it? Maintainer has done all he can do, this means: that is broken, this version fix the problem, go for it. Maintainer's job finishes here, now it's the problem of your favorite arch team. I suspect that the maintainer would be more likely to just leave it broken, which doesn't exactly leave things better-off for the end users. It's a different approach (maybe with the same bad results) but different anyway. Leave the bug there, point the user to the bug and maybe you can gain a new dev or an arch tester. While the proposal made here is to throw random keyword problems to users by policy (which in the case of amd64 some months ago would have created a complete disaster). I'm sure the maintainers of qt/baselayout/coreutils/etc will exercise discretion on removing stable versions of these packages. However, for some obscure utility that next-to-nobody uses, does it really hurt to move from stable back to unstable if the arch maintainers can't keep up? Special cases and special plans are allowed, what we are discussing here is a general and accepted policy. I guess it comes down to the driving issues. How big a problem are stale packages (with the recent movement of a few platforms to experimental, is this an already-solved problem?)? How big of a problem do arch teams see keeping up with 30-days as (or maybe 60/90)? What are the practical (rather than theoretical) ramifications? An interesting discussion. Ask our council to listen all parts: maintainers, current arch teams, the experience of mips, etc. and try to make a good choice. Thanks Richard. -- Jose Luis Rivero [EMAIL PROTECTED] Gentoo/Alpha Gentoo/Do
Re: [gentoo-dev] Proposal for how to handle stable ebuilds
On Tue, 2008-11-11 at 11:18 +0100, Jose Luis Rivero wrote: Richard Freeman wrote: Jose Luis Rivero wrote: I would prefer to analyze the causes of the slacker arch (manpower, hardware, etc) and if we are not able to solve the problem by any way (asking for new devs, buying hardware, etc) go for mark it as experimental and drop all stable keywords. How is that better? Instead of dropping one stable package you'd end up dropping all of them. A user could accept ~arch and get the same behavior without any need to mark every other package in the tree unstable. Accept ~arch for the random package which has lost the stable keyword a random day? And next week .. which is going to be the next? The key is the concept 'stable' and what you hope of it. A long/middle-term solution for arches with very few resources instead of generating problems to users seems a much better approach to me. An arch could put a note to that effect in their installation handbook. The user could then choose between a very narrow core of stable packages or a wider universe of experimental ones. Mixing software branches is very easy in the Gentoo world but it has some problems. Are you going to install in your stable (production, critial, important,...) system a combination of packages not tested before? Because the arch teams or the maintainers are not going to test every posible combination of core stable + universe of experimental packages. This is why branches exists. I guess the question is whether package maintainers should be forced to maintain packages that are outdated by a significant period of time. Suppose something breaks a package that is 3 versions behind stable on all archs but one (where it is the current stable). Should the package maintainer be required to fix it, rather than just delete it? Maintainer has done all he can do, this means: that is broken, this version fix the problem, go for it. Maintainer's job finishes here, now it's the problem of your favorite arch team. I suspect that the maintainer would be more likely to just leave it broken, which doesn't exactly leave things better-off for the end users. It's a different approach (maybe with the same bad results) but different anyway. Leave the bug there, point the user to the bug and maybe you can gain a new dev or an arch tester. While the proposal made here is to throw random keyword problems to users by policy (which in the case of amd64 some months ago would have created a complete disaster). I'm sure the maintainers of qt/baselayout/coreutils/etc will exercise discretion on removing stable versions of these packages. However, for some obscure utility that next-to-nobody uses, does it really hurt to move from stable back to unstable if the arch maintainers can't keep up? Special cases and special plans are allowed, what we are discussing here is a general and accepted policy. I guess it comes down to the driving issues. How big a problem are stale packages (with the recent movement of a few platforms to experimental, is this an already-solved problem?)? How big of a problem do arch teams see keeping up with 30-days as (or maybe 60/90)? What are the practical (rather than theoretical) ramifications? An interesting discussion. Ask our council to listen all parts: maintainers, current arch teams, the experience of mips, etc. and try to make a good choice. Thanks Richard. -- Jose Luis Rivero [EMAIL PROTECTED] Gentoo/Alpha Gentoo/Do Very interesting discussion. Let me take a more or less random post and toss in a slight variation. As you might know, I am an arch maintainer (sparc) and I don't think we are a slacker architecture. However, I have placed an indefinite hold on a stabalization request from the bug-that-must-not-be-named, because in my opinion this package given the current state of everything should not go stable on sparc (more QA issues than functional ones). How, I wonder, would the variations here handle such a situation? I don't think this situation is unique because arch developers are sometimes going to have a different concept of stable than the package developers do. If this does not make sense, is off topic, or irrelevant feel free to ignore it. Regards, Ferris -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Proposal for how to handle stable ebuilds
Jose Luis Rivero [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 11 Nov 2008 11:18:34 +0100: Mixing software branches is very easy in the Gentoo world but it has some problems. Are you going to install in your stable (production, critial, important,...) system a combination of packages not tested before? Your general post I agree with, but this part... If it's a production, critical, important system, then what is one doing installing updates on it directly without verifying them on a generally identical test system first? Either it's not actually so important in the grand scheme of things after all, or one will certainly find out eventually just how critical said machine is when it goes down due to live testing on a production critical machine. Of course, that doesn't excuse a distribution doing its best to ensure that doesn't happen, but no distribution is perfect. -- 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] An official Gentoo wiki
So, gentoo-wiki.com went down for a awhile and took something away from our users something that is useful. Its back now, but I think we should consider having our own official wiki that our users can contribute to. We already have something very similar to this on the forums, and this would just give the correct tool to put their documentation on. I already know some people are going to hate this idea and say that the documentation could be wrong, etc, so lets look at how others have handled this situation. It seems that Ubuntu has their own official documentation section and a community section where users can contribute to. We can put a nice big warning saying that the user documentation may have some errors, and that any such errors should not be directed at the maintainers of the package or the GDP. What are others feelings on this? What issues do you see with having a wiki? Do you see anyway to resolve the issue you see with us having a wiki? -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com pgpR4907laveX.pgp Description: PGP signature
Re: [gentoo-dev] An official Gentoo wiki
Mark Loeser wrote: What are others feelings on this? What issues do you see with having a wiki? Do you see anyway to resolve the issue you see with us having a wiki? +1! I have set up several wikis for work projects and used many others to great benefit. Even those (on my work projects) who were skeptical at first warmed to the idea and quickly became dependent on such tools. As for Wikipedia, there is always the fear that the info will be incorrect, but time has shown that wikis tend to be very accurate and get corrected quickly when not. -Joe
Re: [gentoo-dev] An official Gentoo wiki
Mark Loeser wrote: So, gentoo-wiki.com went down for a awhile and took something away from our users something that is useful. Its back now, but I think we should consider having our own official wiki that our users can contribute to. We already have something very similar to this on the forums, and this would just give the correct tool to put their documentation on. I already know some people are going to hate this idea and say that the documentation could be wrong, etc, so lets look at how others have handled this situation. It seems that Ubuntu has their own official documentation section and a community section where users can contribute to. We can put a nice big warning saying that the user documentation may have some errors, and that any such errors should not be directed at the maintainers of the package or the GDP. What are others feelings on this? What issues do you see with having a wiki? Do you see anyway to resolve the issue you see with us having a wiki? I've asked my fellow GDP members to weigh in on this issue on our ML; the discussion is already in-progress here: http://archives.gentoo.org/gentoo-doc/msg_dd4f573fc6384108fdf14dfa27030906.xml Or, if you like it gmane-style: http://thread.gmane.org/gmane.linux.gentoo.documentation/2903 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] An official Gentoo wiki
On Tue, 11 Nov 2008 18:45:32 -0500 Mark Loeser [EMAIL PROTECTED] wrote: So, gentoo-wiki.com went down for a awhile and took something away from our users something that is useful. Its back now, but I think we should consider having our own official wiki that our users can contribute to. We already have something very similar to this on the forums, and this would just give the correct tool to put their documentation on. I already know some people are going to hate this idea and say that the documentation could be wrong, etc, so lets look at how others have handled this situation. It seems that Ubuntu has their own official documentation section and a community section where users can contribute to. We can put a nice big warning saying that the user documentation may have some errors, and that any such errors should not be directed at the maintainers of the package or the GDP. What are others feelings on this? What issues do you see with having a wiki? Do you see anyway to resolve the issue you see with us having a wiki? I'm for it. I think the positives --- more communications paths, community building, providing something our users want --- outweigh the negatives (entries might be incorrect or irrelevant or whatever). I think it's understood that contributions might contain errors, but the can be corrected. I don't know about Ubuntu's community section, but I do find Wikipedia very useful even though I know it might be wrong. :) -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com Regards, Ferris -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re: [gentoo-dev] An official Gentoo wiki
Mark Loeser wrote: So, gentoo-wiki.com went down for a awhile and took something away from our users something that is useful. Its back now, but I think we should consider having our own official wiki that our users can contribute to. We already have something very similar to this on the forums, and this would just give the correct tool to put their documentation on. I already know some people are going to hate this idea and say that the documentation could be wrong, etc, so lets look at how others have handled this situation. [snip] IMHO, the old gentoo-wiki (don't know if the new one will address it) does let you down when pages are out of date. The solution I like is the wikipedia idea: There is a tag for marking pages as outdated / inaccurate, and if a page has the outdated tag for too long it's removed / archived. Much like treecleaning! -- Iain Buchanan iaindb at netspace dot net dot au You know you're using the computer too much when: refer to traffic lights as routers. -- C J Pro
Re: [gentoo-dev] An official Gentoo wiki
On Tue, 11 Nov 2008 18:45:32 -0500 Mark Loeser [EMAIL PROTECTED] wrote: What are others feelings on this? What issues do you see with having a wiki? Do you see anyway to resolve the issue you see with us having a wiki? What will policy on articles that are horribly dangerous or outright wrong? Is Gentoo prepared to block or warn about articles that recommend stupid things? If a warning is used, what will be used to distinguish between a generic wiki, not necessarily checked by sane people and a article known to be horrible? The problem with wikis is that enough of them contain enough good information that people assume that all of them are entirely correct. Even if warnings are used, the assumption is often well I was warned about another article too and that turned out OK so I can ignore the warning. And whilst it might be OK for some people to say well, we warned you, so tough luck, it makes life very difficult for developers who end up having to deal with hordes of users with broken systems... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] An official Gentoo wiki
Hi, Ciaran McCreesh wrote: On Tue, 11 Nov 2008 18:45:32 -0500 Mark Loeser[EMAIL PROTECTED] wrote: What are others feelings on this? What issues do you see with having a wiki? Do you see anyway to resolve the issue you see with us having a wiki? What will policy on articles that are horribly dangerous or outright wrong? see my previous email - wikipedia looks like they're writing a robot to deal with Articles that need attention[1]. We could do the same, there's nothing stopping us from deleting really bad pages. (archives are always available for someone who wants to revive and improve them). There's also the huge amount of Cleanup tags[2] which I really like (the principle, not the huge amount). We could tailor this however we wanted. Is Gentoo prepared to block or warn about articles that recommend stupid things? I think we definitely should. Someone needs to discover that the article does so first! If a warning is used, what will be used to distinguish between a generic wiki, not necessarily checked by sane people and a article known to be horrible? Cleanup tags! One for each. Nice notice written at the top of the article saying exactly what you've said. The problem with wikis is that enough of them contain enough good information that people assume that all of them are entirely correct. sure, but isn't that similar to, say, a forum? Even if warnings are used, the assumption is often well I was warned about another article too and that turned out OK so I can ignore the warning. sure, some users are idiots :) Better idiot proofing doesn't protect you - it only creates better idiots. (I don't have a reference for this one). And whilst it might be OK for some people to say well, we warned you, so tough luck, it makes life very difficult for developers who end up having to deal with hordes of users with broken systems... I agree tough luck might be a response by some, so the user will go to the next person to help. I don't think this would necessarily fall back to developers. Just like forums, mailing lists and the current wiki, there is good and bad advice. From my experience on the gentoo-user list, bad advice generally gets noticed and corrected reasonably quickly. Even big stuffups (oops I unmerged python) are helped. There is a good culture on the user list which still calls an idiot an idiot. The common one being people using ~ARCH on a remote production box, then complaining it broke for a ~ related reason, adding that they have no physical access (it happens often enough). The usual response is you shouldn't have done it, you were warned, here's how to fix it. I see no problem with this. it makes life very difficult for developers who end up having to deal with hordes of users with broken systems... The only place where I could see specific developer loading, is users who take their problems as a result of following bad advice to bugzilla. I wouldn't expect the hordes would go there first... Anyway, the wiki exists with all it's bad advice already. Making it official would only improve it and hence reduce developer loading, IMHO. [1] http://en.wikipedia.org/wiki/Wikipedia:Pages_needing_attention [2] http://en.wikipedia.org/wiki/Wikipedia:Cleanup_resources cya, -- Iain Buchanan iaindb at netspace dot net dot au Only great masters of style can succeed in being obtuse. -- Oscar Wilde
Re: [gentoo-dev] An official Gentoo wiki
Mark Loeser wrote: So, gentoo-wiki.com went down for a awhile and took something away from our users something that is useful. Its back now, but I think we should consider having our own official wiki that our users can contribute to. We already have something very similar to this on the forums, and this would just give the correct tool to put their documentation on. I already know some people are going to hate this idea and say that the documentation could be wrong, etc, so lets look at how others have handled this situation. It seems that Ubuntu has their own official documentation section and a community section where users can contribute to. We can put a nice big warning saying that the user documentation may have some errors, and that any such errors should not be directed at the maintainers of the package or the GDP. What are others feelings on this? What issues do you see with having a wiki? Do you see anyway to resolve the issue you see with us having a wiki? I have been following gentoo-wiki's new procedures and rebuild process and I think they are on a good track right now. I am throwing this out there, can we ask Mike Valstar for a dump of all his stuff, slap it on gentoo hardware under a wiki.gentoo.org link? It could be a community building experience and offering the stability of gentoo hardware to a service like gentoo-wiki. Maybe also invite Mike to be the admin of said hardware, etc. Thoughts? (I don't know what a community wiki would require for infra hardware, maybe someone will chime in) 2 cents, Jeremy
Re: [gentoo-dev] An official Gentoo wiki
On Tue, Nov 11, 2008 at 08:39:41PM -0600, Jeremy Olexa wrote: I am throwing this out there, can we ask Mike Valstar for a dump of all his stuff, slap it on gentoo hardware under a wiki.gentoo.org link? It could be a community building experience and offering the stability of gentoo hardware to a service like gentoo-wiki. Maybe also invite Mike to be the admin of said hardware, etc. Thoughts? I'd like to answer this on two fronts. As infra, I did offer hosting to Mike Valstar shortly after their downtime started. However he turned me down as somebody else offered him much beefier hardware (overkill hardware in my personal opinion). An additional minor concern were the Google ads he runs, which might not be possible at some of our sponsors. My offer for remote backups for him still stands, and I have not received any response on it from Mike. Additionally, there are license concerns about their existing content, as it was originally one license, and was then blanket re-licensed (see the mails on the gentoo-doc list for more details). Any new Gentoo-run wiki could enforce our docs license of CC-Attribution/ShareALike from the start. -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpXHDc3y246w.pgp Description: PGP signature
