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 packages
On wto, 2017-07-25 at 18:46 -0400, Rich Freeman wrote:
> On Tue, Jul 25, 2017 at 6:30 PM, Michał Górny wrote:
> > On wto, 2017-07-25 at 18:26 -0400, Rich Freeman wrote:
> > > On Tue, Jul 25, 2017 at 4:29 PM, Mike Gilbert wrote:
> > > > On Tue, Jul 25, 2017 at 12:12 PM, Michael Orlitzky
> > > >
On Tue, Jul 25, 2017 at 6:30 PM, Michał Górny wrote:
> On wto, 2017-07-25 at 18:26 -0400, Rich Freeman wrote:
>> On Tue, Jul 25, 2017 at 4:29 PM, Mike Gilbert wrote:
>> > On Tue, Jul 25, 2017 at 12:12 PM, Michael Orlitzky wrote:
>> > > On 07/25/2017 09:23 AM, Michał Górny wrote:
>> > > >
>> > >
On wto, 2017-07-25 at 18:26 -0400, Rich Freeman wrote:
> On Tue, Jul 25, 2017 at 4:29 PM, Mike Gilbert wrote:
> > On Tue, Jul 25, 2017 at 12:12 PM, Michael Orlitzky wrote:
> > > On 07/25/2017 09:23 AM, Michał Górny wrote:
> > > >
> > > > How is that relevant? Revision bumps are merely a tool to
On Tue, Jul 25, 2017 at 4:29 PM, Mike Gilbert wrote:
> On Tue, Jul 25, 2017 at 12:12 PM, Michael Orlitzky wrote:
>> On 07/25/2017 09:23 AM, Michał Górny wrote:
>>>
>>> How is that relevant? Revision bumps are merely a tool to encourage
>>> 'automatic' rebuilds of packages during @world upgrade. I
On wto, 2017-07-25 at 16:31 -0400, Michael Orlitzky wrote:
> On 07/25/2017 04:29 PM, Mike Gilbert wrote:
> >
> > I don't feel I should be obligated by policy to support this use case.
> > One revbump per push seems sufficiently safe for 99.9% of users.
> >
> > If you want to do more revbumps, you
On 07/25/2017 04:29 PM, Mike Gilbert wrote:
>
> I don't feel I should be obligated by policy to support this use case.
> One revbump per push seems sufficiently safe for 99.9% of users.
>
> If you want to do more revbumps, you are free to do so.
>
Can I also delete packages and break the tree s
On Tue, Jul 25, 2017 at 12:12 PM, Michael Orlitzky wrote:
> On 07/25/2017 09:23 AM, Michał Górny wrote:
>>
>> How is that relevant? Revision bumps are merely a tool to encourage
>> 'automatic' rebuilds of packages during @world upgrade. I can't think of
>> a single use case where somebody would ac
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 may build fine in ~arch bu
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 the list of packages
>> 2) test
>> 3) c
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 done by getatoms
On 07/25/2017 09:23 AM, Michał Górny wrote:
>
> How is that relevant? Revision bumps are merely a tool to encourage
> 'automatic' rebuilds of packages during @world upgrade. I can't think of
> a single use case where somebody would actually think it sane to
> checkout one commit after another, and
On Tue, Jul 25, 2017 at 10:13 AM, Michał Górny wrote:
>
> I feel like this is going towards 'anybody can do keywording /
> stabilization'. I'd rather not go this route right now, and just let
> arch teams recruit people as they see fit.
>
I think this depends on the arch team.
Back in the early
On pon, 2017-07-24 at 17:20 +0200, Alexis Ballier wrote:
> # Copyright 1999-2017 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
>
> # @ECLASS: opam.eclass
> # @MAINTAINER:
> # Gentoo ML Project
> # @AUTHOR:
> # Alexis Ballier
> # @BLURB: Provides functions
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 ebui
Hi,
Before I start replying to specific bits, I think it would be reasonable
to outline the flow of a keywording/stabilization bug. I would split it
into 4 steps:
S1. Someone (anyone) files a bug requesting it.
S2. Someone (maintainer or OP) prepares a complete list of packages
(including depend
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 keywo
On wto, 2017-07-25 at 09:26 -0400, Rich Freeman wrote:
> On Tue, Jul 25, 2017 at 7:52 AM, Michał Górny wrote:
> >
> > Except that there is no machines using it. In all contexts, using full URL
> > for machine readability is better as it works with all software out of the
> > box.
> >
>
> Unti
On wto, 2017-07-25 at 08:54 -0400, Joshua Kinard wrote:
> On 07/25/2017 04:05, Michał Górny wrote:
> > Hi, everyone.
> >
> > There have been multiple attempts at grasping this but none so far
> > resulted in something official and indisputable. At the same time, we
> > end having to point our user
On wto, 2017-07-25 at 12:48 +, Peter Stuge wrote:
> Good work on the refactoring!
>
> Alexis Ballier wrote:
> > > > if [ -d "${ED}/usr/share/doc/${PF}/${PN}" ] ; then
> > >
> > > It’s always been recommended to me that we should use the [[ … ]]
> > > form.
> >
> > Doesn't make much
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 holds
On wto, 2017-07-25 at 22:28 +1000, Michael Palimaka wrote:
> On 07/25/2017 06:05 PM, Michał Górny wrote:
> > Hi, everyone.
> >
> > There have been multiple attempts at grasping this but none so far
> > resulted in something official and indisputable. At the same time, we
> > end having to point ou
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 and
On Tue, Jul 25, 2017 at 7:52 AM, Michał Górny wrote:
>
> Except that there is no machines using it. In all contexts, using full URL
> for machine readability is better as it works with all software out of the
> box.
>
Until the domain name of the bugzilla server changes/etc. Even if we
migrate
El mar, 25-07-2017 a las 15:19 +0200, Michał Górny escribió:
> On wto, 2017-07-25 at 14:15 +0200, Pacho Ramos wrote:
> > El mar, 25-07-2017 a las 13:54 +0200, Michał Górny escribió:
> > > Dnia 25 lipca 2017 11:18:21 CEST, Pacho Ramos
> > > napisał(a):
> > > > El mar, 25-07-2017 a las 08:18 +0200,
On wto, 2017-07-25 at 08:26 -0400, Michael Orlitzky wrote:
> On 07/25/2017 07:52 AM, Michał Górny wrote:
> >
> > I have no clue what you mean. I'm just saying that if you push 10
> > changes in 10 commits, you don't have to go straight to -r10 in a
> > single push.
> >
>
> Exactly. Do that inste
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
> needs a newer libbaz.
On wto, 2017-07-25 at 14:15 +0200, Pacho Ramos wrote:
> El mar, 25-07-2017 a las 13:54 +0200, Michał Górny escribió:
> > Dnia 25 lipca 2017 11:18:21 CEST, Pacho Ramos napisał(a):
> > > El mar, 25-07-2017 a las 08:18 +0200, Hans de Graaff escribió:
> > > > On Mon, 2017-07-24 at 23:22 +, Peter S
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 n
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
On 07/25/2017 04:05, Michał Górny wrote:
> Hi, everyone.
>
> There have been multiple attempts at grasping this but none so far
> resulted in something official and indisputable. At the same time, we
> end having to point our users at semi-official guides which change
> in unpredictable ways.
>
>
Good work on the refactoring!
Alexis Ballier wrote:
> > > if [ -d "${ED}/usr/share/doc/${PF}/${PN}" ] ; then
> >
> > It’s always been recommended to me that we should use the [[ … ]]
> > form.
>
> Doesn't make much difference here
Some; you need neither quote nor {} in expansions within [[
On 07/25/2017 06:05 PM, Michał Górny wrote:
> Hi, everyone.
>
> There have been multiple attempts at grasping this but none so far
> resulted in something official and indisputable. At the same time, we
> end having to point our users at semi-official guides which change
> in unpredictable ways.
>
On 07/25/2017 07:52 AM, Michał Górny wrote:
>
> I have no clue what you mean. I'm just saying that if you push 10
> changes in 10 commits, you don't have to go straight to -r10 in a
> single push.
>
Exactly. Do that instead of hoping that no one checks out your
intermediate commits. There's no l
El mar, 25-07-2017 a las 13:54 +0200, Michał Górny escribió:
> Dnia 25 lipca 2017 11:18:21 CEST, Pacho Ramos napisał(a):
> > El mar, 25-07-2017 a las 08:18 +0200, Hans de Graaff escribió:
> > > On Mon, 2017-07-24 at 23:22 +, Peter Stuge wrote:
> > > >
> > > > I hold a perhaps radical view: I
Dnia 25 lipca 2017 11:18:21 CEST, Pacho Ramos napisał(a):
>El mar, 25-07-2017 a las 08:18 +0200, Hans de Graaff escribió:
>> On Mon, 2017-07-24 at 23:22 +, Peter Stuge wrote:
>> >
>> > I hold a perhaps radical view: I would like to simply remove
>stable.
>> >
>> > [snip]
>> >
>> > I conside
Dnia 25 lipca 2017 13:25:38 CEST, Michael Orlitzky napisał(a):
>On 07/25/2017 04:05 AM, Michał Górny wrote:
>>
>> Here's the current draft:
>> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git
>>
>
>It's mostly fine, but there are two changes I disagree with:
>
>> When doing one or more changes
Hi everyone,
> Here's the current draft:
> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git
>
> The basic idea is that the GLEP provides basic guidelines for using git,
> and then we write a proper manual on top of it (right now, all the pages
> about it end up as a mix of requirements and a par
Dnia 25 lipca 2017 12:59:21 CEST, Tobias Klausmann
napisał(a):
>Hi!
>
>On Tue, 25 Jul 2017, Michał Górny wrote:
>> The summary line is included in the short logs (git log --
>> oneline, gitweb, GitHub, mail subject) and therefore should
>> provide a short yet accurate description of the change.
On Tue, Jul 25, 2017 at 2:18 AM, Hans de Graaff wrote:
>
> On Mon, 2017-07-24 at 23:22 +, Peter Stuge wrote:
>
> > More troubleshooting and fixing "hard" problems, less routine work.
>
> Except that some of that routine work is actually what I enjoy doing in
> Gentoo. I already get plenty of t
On 07/25/2017 04:05 AM, Michał Górny wrote:
>
> Here's the current draft:
> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git
>
It's mostly fine, but there are two changes I disagree with:
> When doing one or more changes that require a revision bump, bump the
> revision in the commit including
Hi!
On Tue, 25 Jul 2017, Michał Górny wrote:
> The summary line is included in the short logs (git log --
> oneline, gitweb, GitHub, mail subject) and therefore should
> provide a short yet accurate description of the change. The summary line
> starts with a logical unit name, followed by a colon
El mar, 25-07-2017 a las 08:18 +0200, Hans de Graaff escribió:
> On Mon, 2017-07-24 at 23:22 +, Peter Stuge wrote:
> >
> > I hold a perhaps radical view: I would like to simply remove stable.
> >
> > [snip]
> >
> > I consider dev time a precious resource.
>
> If we were to drop stable I wou
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 is
On Tue, Jul 25, 2017 at 10:05 AM, Michał Górny wrote:
> What do you think about it? Is there anything else that needs being
> covered?
>
Looks good to me. Thanks for writing it up!
Cheers,
Dirkjan
On Mon, 24 Jul 2017 18:11:39 -0400
"Aaron W. Swenson" wrote:
> On 2017-07-24 17:20, Alexis Ballier wrote:
> > Hey,
> >
> > Here is an eclass that would allow me to factor quite a bit of
> > redundant code.
> >
> > …
> > if [ -d "${ED}/usr/share/doc/${PF}/${PN}" ] ; then
>
> It’s always b
On Tue, Jul 25, 2017 at 10:05:06AM +0200, Michał Górny wrote:
Hi, everyone.
There have been multiple attempts at grasping this but none so far
resulted in something official and indisputable. At the same time, we
end having to point our users at semi-official guides which change
in unpredictable
Hi, everyone.
There have been multiple attempts at grasping this but none so far
resulted in something official and indisputable. At the same time, we
end having to point our users at semi-official guides which change
in unpredictable ways.
Here's the current draft:
https://wiki.gentoo.org/wiki/U
On Mon, 24 Jul 2017 23:22:44 +
Peter Stuge wrote:
> Thank you for working on this.
>
> Sergei Trofimovich wrote:
> > Can this proposal make a difference and make gentoo better and
> > easier to work with?
> >
> > Does it try to attack the right thing?
> >
> > Does it completely miss the po
On Mon, Jul 24, 2017 at 11:22 PM, Sergei Trofimovich
wrote:
> TL;DR;TL;DR:
>
>
> This email seeks for one step towards less toil tied to gentoo's
> keywording/stabilization process. I've CCed a few groups who
> might be interested in making this area better:
>
> - gentoo-dev@ as it a
50 matches
Mail list logo
