On Sun, Nov 27, 2016 at 4:07 AM, Rich Freeman wrote:
> On Sun, Nov 27, 2016 at 5:56 AM, Raymond Jennings
> wrote:
> > On Tue, Nov 22, 2016 at 12:06 AM, Alice Ferrazzi
> wrote:
> >>
> >> What about maintainers that are away without writing it in their
> >> maintainer bug ?
> >> After how many da
Hi Daniel,
On Sat, Nov 19, 2016 at 12:55:09AM -0800, Daniel Campbell wrote:
> Agreed. For most of my packages, I really don't mind since we're all
> working on Gentoo together, but it'd be super helpful if I was simply
> notified in the event that a package I maintain has gotten a security
> bump,
On Sun, Nov 27, 2016 at 5:56 AM, Raymond Jennings wrote:
> On Tue, Nov 22, 2016 at 12:06 AM, Alice Ferrazzi wrote:
>>
>> What about maintainers that are away without writing it in their
>> maintainer bug ?
>> After how many days of no replay can be fair to touch their package ?
>
> If a developer
On Tue, Nov 22, 2016 at 12:06 AM, Alice Ferrazzi wrote:
> What about maintainers that are away without writing it in their
> maintainer bug ?
> After how many days of no replay can be fair to touch their package ?
I think we already have dev-away.
If a maintainer marks themselves as devaway, m
On Fri, Nov 25, 2016 at 11:47:35PM -0800, Daniel Campbell wrote:
> On 11/22/2016 12:06 AM, Alice Ferrazzi wrote:
> > On Sat, Nov 19, 2016 at 12:55:09AM -0800, Daniel Campbell wrote:
> >> On 11/17/2016 01:07 PM, Robin H. Johnson wrote:
> >>> On Thu, Nov 17, 2016 at 03:05:41PM +0100, Kristian Fiskers
On 11/22/2016 12:06 AM, Alice Ferrazzi wrote:
> On Sat, Nov 19, 2016 at 12:55:09AM -0800, Daniel Campbell wrote:
>> On 11/17/2016 01:07 PM, Robin H. Johnson wrote:
>>> On Thu, Nov 17, 2016 at 03:05:41PM +0100, Kristian Fiskerstrand wrote:
> Isn't it implied that any stabilisation is approved by
On Sat, Nov 19, 2016 at 12:55:09AM -0800, Daniel Campbell wrote:
> On 11/17/2016 01:07 PM, Robin H. Johnson wrote:
> > On Thu, Nov 17, 2016 at 03:05:41PM +0100, Kristian Fiskerstrand wrote:
> >>> Isn't it implied that any stabilisation is approved by the maintainer?
> >>> Has it ever been acceptabl
On 19/11/16 19:04, Michał Górny wrote:
> Could we maybe include some place (metadata.xml?) to state what is
> the best way to test a package? I'm thinking it could include things
> like:
>
> - whether the test of the package are reliable,
>
> - whether runtime testing is required and what kind of
On 11/17/2016 01:07 PM, Robin H. Johnson wrote:
> On Thu, Nov 17, 2016 at 03:05:41PM +0100, Kristian Fiskerstrand wrote:
>>> Isn't it implied that any stabilisation is approved by the maintainer?
>>> Has it ever been acceptable to go around stabilising random packages?
>>>
>>
>> Explicit > Implicit
Dear Duncan,
maybe you already know the project at http://orca.varstack.com/
Otherwise I would like to advise the following link to you
to answer the question of how to test different USE flag
combinations:
https://github.com/pallavagarwal07/SummerOfCode16/blob/997078ebbf1aa86ba17fa53e400e4c99d7d6
On Fri, 18 Nov 2016 00:13:35 +1100
Michael Palimaka wrote:
> What is the *real* risk that kde-apps/kcalc builds against stable
> dev-libs/gmp but then starts producing funny numbers at runtime?
>
> Let's put it another way - assume we're stabilising a new version of
> dev-libs/gmp instead. Shoul
On Thu, Nov 17, 2016 at 03:05:41PM +0100, Kristian Fiskerstrand wrote:
> > Isn't it implied that any stabilisation is approved by the maintainer?
> > Has it ever been acceptable to go around stabilising random packages?
> >
>
> Explicit > Implicit when we're updating things anyways.
>
> There ar
Michael Palimaka posted on Fri, 18 Nov 2016 02:35:26 +1100 as excerpted:
> On 18/11/16 01:58, William Hubbs wrote:
>> On Thu, Nov 17, 2016 at 06:16:27PM +1100, Michael Palimaka wrote:
>>> USE flags
>>>
>>> While it is preferable to test every USE flag combination, this is not
>>> always
On Thu, Nov 17, 2016 at 8:13 AM, Michael Palimaka wrote:
>
> Just to be clear, I'm not advocating banning runtime testing. I just
> think that, considering the state of the stable tree, we should consider
> very careful in which situations we actually gain value from it. That's
> for another threa
On 18/11/16 01:58, William Hubbs wrote:
> On Thu, Nov 17, 2016 at 06:16:27PM +1100, Michael Palimaka wrote:
>> USE flags
>>
>> While it is preferable to test every USE flag combination, this is not
>> always possible or appropriate. The package may have a large number of
>> USE flags, a l
On 11/17/2016 02:47 PM, Michael Palimaka wrote:
> On 18/11/16 00:26, Kristian Fiskerstrand wrote:
>> Strictly speaking GLEP 40 forbids it still, although some arch teams
>> have made announcements to approve it, see e.g [1,2]. I wouldn't be
>> surprised if one of the results of the stable WG is an
On 18/11/16 00:26, Kristian Fiskerstrand wrote:
> Strictly speaking GLEP 40 forbids it still, although some arch teams
> have made announcements to approve it, see e.g [1,2]. I wouldn't be
> surprised if one of the results of the stable WG is an updated GLEP 40
> that (new GLEP replacing existing)
On 17/11/16 23:49, Michael Orlitzky wrote:
> On 11/17/2016 02:16 AM, Michael Palimaka wrote:
>>
>> # strict - have portage react strongly to conditions that have the
>> potential to be dangerous
>> ...
>> FEATURES="collision-protect ipc-sandbox network-sandbox sandbox
>> split-log split-elog strict
On 17/11/16 22:56, Rich Freeman wrote:
> On Thu, Nov 17, 2016 at 4:37 AM, Michael Palimaka
> wrote:
>> On 17/11/16 20:16, Rich Freeman wrote:
>>> On Thu, Nov 17, 2016 at 2:16 AM, Michael Palimaka
>>> wrote:
* A leaf package such as {{package|kde-apps/kcalc}} may not require any
runtim
On Thu, Nov 17, 2016 at 4:37 AM, Michael Palimaka wrote:
> On 17/11/16 20:16, Rich Freeman wrote:
>> On Thu, Nov 17, 2016 at 2:16 AM, Michael Palimaka
>> wrote:
>>> * A leaf package such as {{package|kde-apps/kcalc}} may not require any
>>> runtime testing at all
>>
>> I'm not really a big fan o
On 17/11/16 20:16, Rich Freeman wrote:
> On Thu, Nov 17, 2016 at 2:16 AM, Michael Palimaka
> wrote:
>>
>> In cases where all USE flags combinations are not being tested, it is
>> still recommended to test:
>> * with all USE flags enabled
>> * with all USE flags disabled
>> * the default USE flag
21 matches
Mail list logo
