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
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
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
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
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
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
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.
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)
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
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
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
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
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
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
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
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
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?
17 matches
Mail list logo
