Rich Freeman posted on Mon, 31 Jul 2017 20:55:05 -0400 as excerpted:
> On Mon, Jul 31, 2017 at 8:24 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>> Rich Freeman posted on Mon, 31 Jul 2017 11:11:24 -0400 as excerpted:
>>
>>> On Mon, Jul 31, 2017 at 10:52 AM, Alec Warner
>>> wrote:
On Mon, Jul 31, 2017 at 8:24 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Rich Freeman posted on Mon, 31 Jul 2017 11:11:24 -0400 as excerpted:
>
>> On Mon, Jul 31, 2017 at 10:52 AM, Alec Warner
>> wrote:
>>>
>>>
>>> Sorry, to be clear the conclusion I was hoping to draw is that
Rich Freeman posted on Mon, 31 Jul 2017 11:11:24 -0400 as excerpted:
> On Mon, Jul 31, 2017 at 10:52 AM, Alec Warner
> wrote:
>>
>>
>> Sorry, to be clear the conclusion I was hoping to draw is that one has
>> 2 repos instead of 1.
>>
>> 1) Rolling.
>> 2) Stable.
>>
>> Rolling
On Fri, Jul 28, 2017 at 05:56:25PM -0400, William L. Thomson Jr. wrote
> If upstream does a new release, fixes bugs. Gentoo marks a previous
> release stable. It is stabilizing a package with issues fixed upstream.
> That does not make sense. Gentoo issues maybe good, but not upstreams.
>
> I
On Fri, 28 Jul 2017 21:45:57 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> William L. Thomson Jr. posted on Fri, 28 Jul 2017 16:10:42 -0400 as
> excerpted:
>
> > It seems odd that upstream will release a package. Just for
> > downstream to consider it not stable. Did it get messed up during
William L. Thomson Jr. posted on Fri, 28 Jul 2017 16:10:42 -0400 as
excerpted:
> It seems odd that upstream will release a package. Just for downstream
> to consider it not stable. Did it get messed up during packaging? Did it
> get messed up by the distro? The whole lag thing does not make sense
On Tue, 2017-07-25 at 11:03 +0200, Agostino Sarubbo wrote:
>
> 1) Don't file keywordreq, since noone work on them. File directly
> stablereq.
This does not make sense to me.
If we want to go this route we should probably state a policy instead
that new dependencies for already keyworded
On 07/25/2017 06:22 AM, Rich Freeman wrote:
> On Tue, Jul 25, 2017 at 9:10 AM, Michael Palimaka
> wrote:
>>
>> The 30 day waiting period is useful for smoking out major upstream bugs,
>> but can't replace stabilisation integration testing. For example,
>> package foobar
On Tue, Jul 25, 2017 at 3:45 PM, Markus Meier wrote:
> On Tue, 25 Jul 2017 11:03:30 +0200
> Agostino Sarubbo wrote:
>
>> On Monday 24 July 2017 22:22:23 Sergei Trofimovich wrote:
>> > 1. lack of automation
>> I'd summarize the techical steps into:
>> 1) get
On Tue, 25 Jul 2017 11:03:30 +0200
Agostino Sarubbo wrote:
> On Monday 24 July 2017 22:22:23 Sergei Trofimovich wrote:
> > 1. lack of automation
> I'd summarize the techical steps into:
> 1) get the list of packages
> 2) test
> 3) commit to git
> 4) write on bugzilla
>
> 1 is
Michael Palimaka wrote:
> The 30 day waiting period is useful for smoking out major upstream bugs,
> but can't replace stabilisation integration testing. For example,
> package foobar may build fine in ~arch but fails in stable because it
> needs a newer libbaz.
So that's either because of an
On wto, 2017-07-25 at 22:59 +1000, Michael Palimaka wrote:
> On 07/25/2017 07:22 AM, Sergei Trofimovich wrote:
> > 2. Q: How to make arch testing faster and easier?
> >
> >A: - KEYWORDREQ/STABLEREQ bugs not marked as "runtime testing
> > required" will be automatically tested and
El mar, 25-07-2017 a las 23:10 +1000, Michael Palimaka escribió:
> On 07/25/2017 05:22 PM, Dirkjan Ochtman wrote:
> > First, the assumption in our processes seems to be that many or
> > important bugs will be due to architecture-specific differences, and I
> > wonder if that assumption really
El mar, 25-07-2017 a las 22:59 +1000, Michael Palimaka escribió:
> On 07/25/2017 07:22 AM, Sergei Trofimovich wrote:
> > 2. Q: How to make arch testing faster and easier?
> >
> > A: - KEYWORDREQ/STABLEREQ bugs not marked as "runtime testing
> > required" will be automatically tested
On Tue, Jul 25, 2017 at 9:10 AM, Michael Palimaka wrote:
>
> The 30 day waiting period is useful for smoking out major upstream bugs,
> but can't replace stabilisation integration testing. For example,
> package foobar may build fine in ~arch but fails in stable because it
On 07/25/2017 05:22 PM, Dirkjan Ochtman wrote:
> First, the assumption in our processes seems to be that many or
> important bugs will be due to architecture-specific differences, and I
> wonder if that assumption really holds up. Do arch testers for a smaller
> arch often find problems that were
On 07/25/2017 07:22 AM, Sergei Trofimovich wrote:
> 2. Q: How to make arch testing faster and easier?
>
>A: - KEYWORDREQ/STABLEREQ bugs not marked as "runtime testing
> required" will be automatically tested and keyworded.
>
> [handwave] automated tinderbox setup would help a
Hello Sergei,
thanks to bring into the topic which nowadays is a common point of discussion
:)
On Monday 24 July 2017 22:22:23 Sergei Trofimovich wrote:
> 1. lack of automation
I'd summarize the techical steps into:
1) get the list of packages
2) test
3) commit to git
4) write on bugzilla
1
On Tue, 2017-07-25 at 04:34 +, Duncan wrote:
>
> Automating stabilization and automated keyword dropping on timeouts
> seems
> the only other practical choice, as unfortunately, "stale" is what
> we
> have today in practice, if not in name.
Looking at https://repology.org/statistics stable
Rich Freeman posted on Mon, 24 Jul 2017 19:52:40 -0400 as excerpted:
> On Mon, Jul 24, 2017 at 7:22 PM, Peter Stuge wrote:
>>
>> I hold a perhaps radical view: I would like to simply remove stable.
>>
>> I continue to feel that maintaining two worlds (stable+unstable)
>> carries
El lun, 24-07-2017 a las 22:22 +0100, Sergei Trofimovich escribió:
> 4. Q: How to push more packages into STABLE?
>
> A: File automatic STABLEREQ bugs more aggressively if no known bugs
> exist for a package version. The rough workflow is the following:
>
> - Grab a list of
21 matches
Mail list logo