Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

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

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

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

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

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

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

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'

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

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,

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

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

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

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

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

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,

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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.

Re: [gentoo-dev] New eclass: opam.eclass

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

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

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 > >

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

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

Re: [gentoo-dev] New eclass: opam.eclass

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

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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

Re: [gentoo-dev] Re: [RFC pre-GLEP] Gentoo Git Workflow

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

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

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.

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

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

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

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. >

Re: [gentoo-dev] New eclass: opam.eclass

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 [[

[gentoo-dev] Re: [RFC pre-GLEP] Gentoo Git Workflow

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.

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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]

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

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

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

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

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

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

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

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

Re: [gentoo-dev] New eclass: opam.eclass

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}" ] ;

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

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

[gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

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:

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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: > > -

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

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 would have to start maintaining my own stable lists to determine what would be

Re: [gentoo-dev] vim-syntax USE flag

On Mon, 2017-07-24 at 12:10 +0200, Ulrich Mueller wrote: > > Similarly, if we get rid of the vim-syntax flag, should we phase out > the emacs USE flag, too? I would say no because in almost all cases the emacs code needs to be compiled and that requires emacs to be present. As far as I