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 yo
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
Matti Bickel wrote:
> Tobias Scherbaum <[EMAIL PROTECTED]> wrote:
> > 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. Poli
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
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 w
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 har
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.
Ho
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.
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
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? Inste
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
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
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 sta
Mark Loeser wrote:
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
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
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, 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 th
17 matches
Mail list logo
