| 1 |
Jose Luis Rivero <yoswink@g.o> said: |
| 2 |
> Mark Loeser wrote: |
| 3 |
>> Removing Stable Ebuilds |
| 4 |
>> If an ebuild meets the time criteria above, and there are no technical |
| 5 |
>> issues |
| 6 |
>> preventing stabilization, then the maintainer MAY choose to delete an |
| 7 |
>> older |
| 8 |
>> version even if it is the most recent stable version for a particular |
| 9 |
>> arch. |
| 10 |
> |
| 11 |
> Mark, I think you are looking at the problem only with the ebuild |
| 12 |
> maintainer hat put on. We have other players in our business, being one of |
| 13 |
> them the users. This policy would bring too many problems to them so .. |
| 14 |
> nono by my side. |
| 15 |
|
| 16 |
I purposely did this. I like the proposal, but I also know that it has |
| 17 |
a lot of problems. It was better than sending something out asking what |
| 18 |
people think though. |
| 19 |
|
| 20 |
> I would prefer to analyze the causes of the slacker arch (manpower, |
| 21 |
> hardware, etc) and if we are not able to solve the problem by any way |
| 22 |
> (asking for new devs, buying hardware, etc) go for mark it as experimental |
| 23 |
> and drop all stable keywords. |
| 24 |
|
| 25 |
This is one way to resolve it. We need to establish how an arch gets |
| 26 |
pushed to "experimental" and how maintainers need to deal with that |
| 27 |
though. An example is removing the only version of a package that works |
| 28 |
on that specific arch, is this a problem if the arch is declared to be |
| 29 |
experimental? |
| 30 |
|
| 31 |
If this is the path we want to go down, lets set up some rules for how |
| 32 |
to handle experimental archs and what it means to go from |
| 33 |
stable->experimental and experimental->stable. |
| 34 |
|
| 35 |
-- |
| 36 |
Mark Loeser |
| 37 |
email - halcy0n AT gentoo DOT org |
| 38 |
email - mark AT halcy0n DOT com |
| 39 |
web - http://www.halcy0n.com |
Archives