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.
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
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]>