Re: [gentoo-dev] Proposal for how to handle stable ebuilds
On 19:08 Mon 17 Nov , Tobias Scherbaum wrote: That would people require to use common sense. The past has shown that people tend to have different views of what common sense might be in a given case. Therefore policy in that aspect needs to be as clear and understandable as possible to avoid unnecessary discussions. I'd rather say people need to figure out common sense so we don't need to document hundreds of pages of every tiny detail. It seems like the vast majority of people don't have a problem with figuring this stuff out. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpGiqkpi749i.pgp Description: PGP signature
Re: [gentoo-dev] Proposal for how to handle stable ebuilds
On 13:13 Mon 10 Nov , Mark Loeser wrote: Instead of addressing archs as being slackers or not, this addresses it as a more granular layer of looking at ebuilds. Thanks to Richard Freeman for the initial proposal that I based this off of. Please give me feedback on this proposal, if you think it sucks (preferably with an explanation why), or if you think it might work. I'm not convinced why this needs to happen, because there's no reasoning behind it here. There needs to be rationale for why this should happen with pros and cons. dang mentioned a few pros from the maintainer side, the arch team ones are pretty easy to come up with. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgppmEnIvSt8K.pgp Description: PGP signature
Re: [gentoo-dev] Proposal for how to handle stable ebuilds
Tobias Scherbaum [EMAIL PROTECTED] wrote: Mark Loeser wrote: Removing Stable Ebuilds If an ebuild meets the time criteria above, and there are no technical issues preventing stabilization, then the maintainer MAY choose to delete an older version even if it is the most recent stable version for a particular arch. What if this would break deps or it's a very common package for example belonging to the set of system packages? Then the maintainer moans and does nothing. I guess that's where the MAY part from above comes in. Policy should not be an excuse to stop thinking. And if i break a user system when i drop my stable keywords, IMHO i'm violating the 'work as pleasently and efficiently as possible' bit of our philosophy. It isn't that we have arch teams denying ebuilds their blessing because they're evil. Maybe they're overworked, maybe they even have a real life. Or maybe they have stated that your ebuild has QA issues (as Ferris did), which should be noted and fixed by the maintainer. So bottom-line: i'm very much in favour of your solution to question #1. And i'd like to stress the automatic bit. Yes, we can get access to tinderboxes. But last i looked, this involved tracking down the person responsible for it, asking for access and doing everything you need to get your package to compile. Well, i'm lazy, so i didn't do it. Automatic tinderbox testing would very much help in the process. Maybe someone can write a script so that once a maintainer opens/gives his OK to a stable bug, automatic testing could be started and the results posted back to the bug? After the timeframe (30 days? 60? I don't know, and it's not important at this point) maintainers could move to stable their package themself IF the automatic tests indicate success AND no arch member has spoken up. just my $0.02 -- Regards, Matti Bickel Signed/Encrypted email preferred (key 4849EC6C) pgpaOntcepuKy.pgp Description: PGP signature
Re: [gentoo-dev] Proposal for how to handle stable ebuilds
Mark Loeser wrote: Removing Stable Ebuilds If an ebuild meets the time criteria above, and there are no technical issues preventing stabilization, then the maintainer MAY choose to delete an older version even if it is the most recent stable version for a particular arch. What if this would break deps or it's a very common package for example belonging to the set of system packages? If we would opt for such a fixed timeframe for architectures teams to fix bugs I'd like to rate those bugs at least partially like security@ does - that would allow us to have different timeframes for stabilization depending on how much the package in questions is (expected to be) installed at our users' systems. In my opinion we would need to address two main concerns with this discussion: 1) What can we do to help understaffed architecture teams? What about using a tinderbox (yeah, i know - we have lots of tinderboxes already around) which automatically (re)builds stable-candidates and those of the candidates which a) includes a test phase and b) pass that test phase might be stabled by the maintainer/herd and not only the architecture team, for example? 2) When do we move an architecture back to ~arch? We would need to define a threshold of when an stable architecture has to enter a probation period (and who and what's going to start that process) and a timeframe after which either the architecture is moved back to ~arch or the architecture team has proven that it is able to maintain stable keywords (define who's going to decide this). Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
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] 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
Re: [gentoo-dev] Proposal for how to handle stable ebuilds
On Mon, 10 Nov 2008 13:13:34 -0500 Mark Loeser [EMAIL PROTECTED] wrote: Arch teams will normally have 30 days from the day a bug was filed, keyworded STABLEREQ, the arch was CCed, and the maintainer either filed the bug or commented that it was OK to stabilize (clock starts when all of these conditions are met). 30 days is a minimum, not a maximum. If an ebuild meets the time criteria above, and there are no technical issues preventing stabilization, then the maintainer MAY choose to delete an older version even if it is the most recent stable version for a particular arch. All this does is screw over users. The impact of a forced downgrade is far higher than the impact of leaving things in the tree for as long as is necessary. You are proposing giving maintainers carte blanche to screw over users and encouraging rather than reducing the kind of us vs them behaviour that a few package maintainers like to engage in where arch teams are treated as being in the way rather than there to help. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Proposal for how to handle stable ebuilds
On E, 2008-11-10 at 13:13 -0500, Mark Loeser wrote: Removing Stable Ebuilds If an ebuild meets the time criteria above, and there are no technical issues preventing stabilization, then the maintainer MAY choose to delete an older version even if it is the most recent stable version for a particular arch. Even if that is a package that other packages depend on? Lets say I want to delete an ancient version of gtk+, but arch ABC has that as the only stable ebuild, while the rest are ~ABC. Do I remove it, as I may, and break the whole stable tree of arch ABC, unkeyword hundreds of other packages, or I'm just allowed to remove it but should really apply a common sense as usual and you don't want to go into details in this document? -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Proposal for how to handle stable ebuilds
On Mon, Nov 10, 2008 at 12:23 PM, Mart Raudsepp [EMAIL PROTECTED] wrote: On E, 2008-11-10 at 13:13 -0500, Mark Loeser wrote: Removing Stable Ebuilds If an ebuild meets the time criteria above, and there are no technical issues preventing stabilization, then the maintainer MAY choose to delete an older version even if it is the most recent stable version for a particular arch. Even if that is a package that other packages depend on? Lets say I want to delete an ancient version of gtk+, but arch ABC has that as the only stable ebuild, while the rest are ~ABC. Do I remove it, as I may, and break the whole stable tree of arch ABC, unkeyword hundreds of other packages, or I'm just allowed to remove it but should really apply a common sense as usual and you don't want to go into details in this document? *MAY* choose - you don't *have* to do it - I'd prefer something along the lines of, may stablize it - if after a minimum of 30 days - maybe 90 days max - if the arch team hasn't had enough time to stablize it... when will they ever?
Re: [gentoo-dev] Proposal for how to handle stable ebuilds
Mark Loeser wrote: snip I really don't understand why it is better to break the stable trees of $ARCH instead of just making them all ~ARCH. (ie. ~mips, ~x86-fbsd, etc). If the $ARCH doesn't have the manpower to do stable reqs then they don't have the manpower to fix broken stable trees either or do security bugs. So, IMHO, this proposal doesn't solve anything. With the key problem being that the 'slacker' arches can't keep up with the stable reqs and hence a large number of stale ebuilds and stale bugs being kept around. -Jeremy
Re: [gentoo-dev] Proposal for how to handle stable ebuilds
El lun, 10-11-2008 a las 13:13 -0500, Mark Loeser escribió: Ebuild Stabilization Time Arch teams will normally have 30 days from the day a bug was filed, keyworded STABLEREQ, the arch was CCed, and the maintainer either filed the bug or commented that it was OK to stabilize (clock starts when all of these conditions are met). Removing Stable Ebuilds If an ebuild meets the time criteria above, and there are no technical issues preventing stabilization, then the maintainer MAY choose to delete an older version even if it is the most recent stable version for a particular arch. If an ebuild meets the time criteria above, but there is a technical issue preventing stabilization, and there are no outstanding security issues, then the maintainer MUST not remove the highest-versioned stable ebuild for any given arch without the approval of the arch team. Security issues are to be handled by the recommendations of the Security Team. If this proposal had been approved a year ago as is, amd64 stable keywords could have been dropped all over the place, making stable tree unsupported on amd64 de facto (guess how many users would have left Gentoo) and agravating our past workload problems. So the consequences of this policy being applied on a regular basis can be far worse than arches lagging behind. Regards, -- Santiago Moisés Mola Jabber: [EMAIL PROTECTED] | GPG: AAD203B5 signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: [gentoo-dev] Proposal for how to handle stable ebuilds
Mark Loeser wrote: Removing Stable Ebuilds If an ebuild meets the time criteria above, and there are no technical issues preventing stabilization, then the maintainer MAY choose to delete an older version even if it is the most recent stable version for a particular arch. 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 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. Thanks. -- Jose Luis Rivero [EMAIL PROTECTED] Gentoo/Alpha Gentoo/Doc
Re: [gentoo-dev] Proposal for how to handle stable ebuilds
Jose Luis Rivero [EMAIL PROTECTED] said: Mark Loeser wrote: Removing Stable Ebuilds If an ebuild meets the time criteria above, and there are no technical issues preventing stabilization, then the maintainer MAY choose to delete an older version even if it is the most recent stable version for a particular arch. 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. 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. -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com pgpS6lqfqSAGz.pgp Description: PGP signature
Re: [gentoo-dev] Proposal for how to handle stable ebuilds
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. 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. 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. 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? 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?
