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

Michał Górny posted on Tue, 25 Jul 2017 10:05:06 +0200 as excerpted: > ==Backwards Compatibility== > Most of the new policy will apply to the commits following its approval. > Backwards compatibility is not relevant there. s/Backwards/Backward/ (both header and body) "Backwards" is a

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

On Thu, Jul 27, 2017 at 6:41 PM, Rich Freeman wrote: > > When in the last 16 years was this 2 year period of running stable? > The general state of QA has varied quite a bit over that time. > I would say 3 or 4 years ago, roughly. > running unstable systemd has been Running

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

On Thu, Jul 27, 2017 at 7:12 PM, Denis Dupeyron wrote: > > Here's a data point you may, or may not, find relevant. in 16 years of using > Gentoo exclusively, the only one time I used stable on one machine for about > 2 years it ended up being much more of a pain than unstable.

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

Michał Górny posted on Tue, 25 Jul 2017 10:05:06 +0200 as excerpted: > ===Commit messages=== [...] > Historically, Gentoo has been using a few tags starting with X- > . However, this practice was abandoned once it has been pointed > out that git does not enforce any standard set of tags, and

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

On Mon, Jul 24, 2017 at 4:22 PM, Sergei Trofimovich wrote: > TL;DR;TL;DR: > [...] Here's a data point you may, or may not, find relevant. in 16 years of using Gentoo exclusively, the only one time I used stable on one machine for about 2 years it ended up being much more of a

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

Michał Górny posted on Tue, 25 Jul 2017 10:05:06 +0200 as excerpted: > ===Splitting commits=== > Git commits are lightweight, and the developers are encouraged to split > their commits to improve readability and the ability of reverting > specific sub-changes. When choosing how to split the

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

Michał Górny posted on Tue, 25 Jul 2017 10:05:06 +0200 as excerpted: > ==Specification== > ===Branching model=== > The main branch of the Gentoo repository is the master > branch. All Gentoo developers push their work straight to the master > branch, provided that the commits meet the minimal

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

Michał Górny posted on Tue, 25 Jul 2017 10:05:06 +0200 as excerpted: > ==Motivation== > Although the main Gentoo repository is using git for two years already, > developers still lack official documentation on how to use git > consistently. Most of the developers learn spoken standards from

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

On 07/27/2017 04:11 PM, Michał Górny wrote: >> Right, so github automatically closes pull requests when encountering >> Closes, that doesn't indicate that Closes can't be used for other >> platforms to do similar things, or closing things manually if provided >> through other channels. The current

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

On czw, 2017-07-27 at 16:08 +0200, Kristian Fiskerstrand wrote: > On 07/27/2017 03:58 PM, Michał Górny wrote: > > > > > > ** Closes: > > > > > > https://github.com/gentoo/gentoo/pull/ > > > > > ki>; — to automatically close a GitHub pull request, > > > > > > > > > > Is this a generic tag for

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

On 07/27/2017 03:58 PM, Michał Górny wrote: > ** Closes: https://github.com/gentoo/gentoo/pull/ ki>; — to automatically close a GitHub pull request, Is this a generic tag for any pull request of any platform? >>> No. As I've told multiple times already, there are *no* generic

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

On czw, 2017-07-27 at 15:54 +0200, Kristian Fiskerstrand wrote: > On 07/27/2017 03:52 PM, Michał Górny wrote: > > On śro, 2017-07-26 at 19:17 +0200, Kristian Fiskerstrand wrote: > > > On 07/25/2017 10:05 AM, Michał Górny wrote: > > > > ** Fixes: https://bugs.gentoo.org/NN;;; > > > > — > > > >

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

On 07/27/2017 03:52 PM, Michał Górny wrote: > On śro, 2017-07-26 at 19:17 +0200, Kristian Fiskerstrand wrote: >> On 07/25/2017 10:05 AM, Michał Górny wrote: >>> ** Fixes: https://bugs.gentoo.org/NN;; — >>> to indicate a fixed bug, >> >> At this point fixes is overloading >>> ** Fixes:

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

On śro, 2017-07-26 at 19:17 +0200, Kristian Fiskerstrand wrote: > On 07/25/2017 10:05 AM, Michał Górny wrote: > > ** Fixes: https://bugs.gentoo.org/NN;; — > > to indicate a fixed bug, > > At this point fixes is overloading > > ** Fixes: commit-id (commit message) — to indicate fixing a > >

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

On śro, 2017-07-26 at 19:05 +0200, Kristian Fiskerstrand wrote: > On 07/25/2017 02:28 PM, Michael Palimaka wrote: > > Does a bug # really need to always be in the summary line? It can eat > > valuable characters and tags which are pretty popular are equally valid IMO. > > I would prefer the

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

On 07/26/2017 07:20 PM, Rich Freeman wrote: > I was thinking that it would make far more sense to use "Bug" for > Gentoo bugs, and use something like "Reference" or "Remote-Bug" for > non-Gentoo bugs. 99% of the time commits will reference a Gentoo bug. I like the idea of Reference for URL

Re: [gentoo-dev] sys-boot/plymouth needs major fixes/maintainer

El mié, 26-07-2017 a las 13:46 +, Lucas Ramage escribió: > I am not yet an official developer but I am interested in assisting in > maintaining this. > Then, please take a look on: https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers In summary, you will need to open a bug asking

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

On 07/26/2017 10:05 AM, Kristian Fiskerstrand wrote: > On 07/25/2017 02:28 PM, Michael Palimaka wrote: >> Does a bug # really need to always be in the summary line? It can eat >> valuable characters and tags which are pretty popular are equally valid IMO. > > I would prefer the summary to be