On Thu, 14 Dec 2017 16:04:17 -0600
R0b0t1 wrote:
> Can you be specific? Human memory is biased towards negative
> experiences. If it's hard to actually describe the multitude of issues
> that mixed systems cause then it is very likely mixed systems do not
> cause many issues.
We have mixed syste
13.12.2017 21:20, Lucas Ramage пишет:
> What about running a stable chroot? Are there any tools that can be
> used to automate this process?
Try gentoo-chrootiez[1], it is written by our fellow gentoo developer -
slyfox. And it is damn simple to use.
[1] - https://github.com/trofi/gentoo-chroot
On Thu, Dec 14, 2017 at 7:25 PM, M. J. Everitt wrote:
> On 15/12/17 01:17, R0b0t1 wrote (excerpted):
>> I'm not trying to be confrontational, but asserting an opinion is
>> correct without explaining why that it is so isn't really conducive to
>> arriving at the truth. I understand not wanting to
On 12/12/2017 01:24 PM, Rich Freeman wrote:
>
> As far as I'm aware the standing policy already exists that
> maintainers can stabilize their own packages on amd64.
https://bugs.gentoo.org/510198
is this thing on
On Wed, 13 Dec 2017 15:55:59 -0500
Lucas Ramage wrote:
> I see, well I can setup buildbot to do that. Is there some place in
> particular that I should send my test results?
>
> On Wed, Dec 13, 2017 at 1:28 PM, Aaron W. Swenson
> wrote:
>
> > On 2017-12-13 13:20, Lucas Ramage wrote:
> > > >
On 15/12/17 01:17, R0b0t1 wrote (excerpted):
> I'm not trying to be confrontational, but asserting an opinion is
> correct without explaining why that it is so isn't really conducive to
> arriving at the truth. I understand not wanting to answer if I am
> completely clueless, and would like to apol
On Thu, Dec 14, 2017 at 4:04 PM, R0b0t1 wrote:
> On Thu, Dec 14, 2017 at 2:32 PM, Kristian Fiskerstrand
> wrote:
>> On 12/14/2017 09:21 PM, R0b0t1 wrote:
>>> It seems like lagging stability is due to a lack of resources. I do
>>> not know a single person who would be able to run only stable
>>>
On Thu, Dec 14, 2017 at 2:32 PM, Kristian Fiskerstrand wrote:
> On 12/14/2017 09:21 PM, R0b0t1 wrote:
>> It seems like lagging stability is due to a lack of resources. I do
>> not know a single person who would be able to run only stable
>> packages.
>
> I run stable only on most of my systems.
>
On 2017-12-14 21:53, Alec Warner wrote:
> I'm skeptical the keywords for most packages matter, particularly on
> common arches. Remember this is usually software that upstream
> already tested and released; so most of the bugs would be ebuild /
> Gentoo related.
That's why I prefer Debian's SID ->
On 2017-12-14 20:45, William Hubbs wrote:
> I tend to like this better. Let's try to move away from filing stable
> requests for new versions of packages once an old version is stable and
> have a way to block newer versions from going stable. Maybe buildbot
> could check to see if there is a bug o
On Thu, Dec 14, 2017 at 3:34 PM, Kristian Fiskerstrand
wrote:
> On 12/14/2017 01:01 PM, Rich Freeman wrote:
> > In the beginning the system would be opt-in. Then once we have
> > confidence that it is working well the flag could potentially be made
> > opt-out.
>
> The only place I imagine this
On 12/14/2017 01:01 PM, Rich Freeman wrote:
> In the beginning the system would be opt-in. Then once we have
> confidence that it is working well the flag could potentially be made
> opt-out.
The only place I imagine this being a good idea is for the kernel, given
the strict no break of userland
On 12/14/2017 09:21 PM, R0b0t1 wrote:
> It seems like lagging stability is due to a lack of resources. I do
> not know a single person who would be able to run only stable
> packages.
I run stable only on most of my systems.
> They seem to move too slowly, and people switch to unstable
> packages
On Thu, Dec 14, 2017 at 2:13 PM, Thomas Deutschmann wrote:
> On 2017-12-14 21:06, R0b0t1 wrote:
>> In response to the concerns about stability: If I run a lot of unstable
>> packages, would that preclude my system from being able to help?
>
> Yes. Only clean stable systems are eligible for arch te
On 2017-12-14 21:06, R0b0t1 wrote:
> In response to the concerns about stability: If I run a lot of unstable
> packages, would that preclude my system from being able to help?
Yes. Only clean stable systems are eligible for arch testing. That's the
whole idea of arch testing... ;)
Remember that m
On Wed, Dec 13, 2017 at 2:55 PM, Lucas Ramage
wrote:
> I see, well I can setup buildbot to do that. Is there some place in
> particular that I should send my test results?
>
Is this part of the point of a Tinderbox? The only problem I can see is
that the configurations being tested can be extrem
On Wed, Dec 13, 2017 at 09:58:05PM +0100, Thomas Deutschmann wrote:
*snip*
> b) Because not all devs care about stable Gentoo, I would recommend
> auto-stabilization: I.e. if a package is in the repository for x days
> build bot would try to build the package and mark the package stable if
> ever
Dear Thomas and everyone else interested!
Before re-inventing the wheel, you might take a closer look at this Google
summer of code project in 2016:
https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2016/Ideas/Continuous_Stabilization
I do not know how far the author got but it might be a good
On Thu, Dec 14, 2017 at 7:07 AM, Aaron W. Swenson wrote:
> On 2017-12-14 13:58, Kent Fredric wrote:
>> On Wed, 13 Dec 2017 21:58:05 +0100
>> Slightly modified suggestion:
>>
>> Add a flag called "autostabilize" with [unset], [y], [n]
>>
>> Default is 'unset', and if found unset after a given time,
On 2017-12-14 13:58, Kent Fredric wrote:
> On Wed, 13 Dec 2017 21:58:05 +0100
> Slightly modified suggestion:
>
> Add a flag called "autostabilize" with [unset], [y], [n]
>
> Default is 'unset', and if found unset after a given time, it flips to
> y and the stable bot gets queued up.
>
> If its
On Thu, Dec 14, 2017 at 5:39 AM, Thomas Deutschmann wrote:
>
> But well, for the beginning we don't need the perfect solution. We can
> start with an easy mode and blacklist most packages. So devs interested
> can remove their packages from blacklist. And like said, build bot would
> still handle
On 2017-12-14 01:58, Kent Fredric wrote:
> On Wed, 13 Dec 2017 21:58:05 +0100
> Thomas Deutschmann wrote:
>
>> b) Because not all devs care about stable Gentoo, I would recommend
>> auto-stabilization: I.e. if a package is in the repository for x days
>> build bot would try to build the package a
On Wed, 13 Dec 2017 21:58:05 +0100
Thomas Deutschmann wrote:
> b) Because not all devs care about stable Gentoo, I would recommend
> auto-stabilization: I.e. if a package is in the repository for x days
> build bot would try to build the package and mark the package stable
> if everything passes.
On 2017-12-13 18:51, William Hubbs wrote:
> In theory, this is correct. However, when maintainers don't stabilize
> packages and no one else does either, our stable tree suffers.
I agree but we have to pay attention that we don't stabilize packages at
all costs because otherwise they would never g
I see, well I can setup buildbot to do that. Is there some place in
particular that I should send my test results?
On Wed, Dec 13, 2017 at 1:28 PM, Aaron W. Swenson
wrote:
> On 2017-12-13 13:20, Lucas Ramage wrote:
> > > In my discussions with other developers, I've found that this is the
> >
On 2017-12-13 13:20, Lucas Ramage wrote:
> > In my discussions with other developers, I've found that this is the
> >
> biggest concern. Most devs are runnning ~amd64, so they don't feel that
> >
> they can mark things stable.
>
> W
> hat about running a stable chroot? Are there any tools
> In my discussions with other developers, I've found that this is the
>
biggest concern. Most devs are runnning ~amd64, so they don't feel that
>
they can mark things stable.
W
hat about running a stable chroot? Are there any tools that can be used
to automate this process?
On Wed, Dec
On Wed, Dec 13, 2017 at 01:22:04PM +0100, Thomas Deutschmann wrote:
> On 2017-12-12 19:24, Rich Freeman wrote:
> > As far as I'm aware the standing policy already exists that
> > maintainers can stabilize their own packages on amd64.
>
> That's right but keep in mind that nevertheless you need a s
On 2017-12-12 19:24, Rich Freeman wrote:
> As far as I'm aware the standing policy already exists that
> maintainers can stabilize their own packages on amd64.
That's right but keep in mind that nevertheless you need a stable
system. Marking a package stable because it works on your ~arch box you
On Tue, Dec 12, 2017 at 12:24 PM, Rich Freeman wrote:
> On Tue, Dec 12, 2017 at 1:15 PM, Michał Górny wrote:
>>
>> It seems that we've started lacking arch testers for AMD64 architecture.
>> At this moment, there are already 159 bugs in amd64 backlog, and there
>> is no noticeable progress. New s
On 12/12/2017 19:24, Rich Freeman wrote:
> On Tue, Dec 12, 2017 at 1:15 PM, Michał Górny wrote:
>> It seems that we've started lacking arch testers for AMD64 architecture.
>> At this moment, there are already 159 bugs in amd64 backlog, and there
>> is no noticeable progress. New stabilization re
On Tue, Dec 12, 2017 at 1:15 PM, Michał Górny wrote:
>
> It seems that we've started lacking arch testers for AMD64 architecture.
> At this moment, there are already 159 bugs in amd64 backlog, and there
> is no noticeable progress. New stabilization requests are usually
> handled much faster by x8
Hi, everyone.
It seems that we've started lacking arch testers for AMD64 architecture.
At this moment, there are already 159 bugs in amd64 backlog, and there
is no noticeable progress. New stabilization requests are usually
handled much faster by x86, sparc and hppa teams!
If you have a stable AM
33 matches
Mail list logo
