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
32 matches
Mail list logo
