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

On Wed, Jul 26, 2017 at 07:05:47PM +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

Re: [gentoo-portage-dev] [PATCH] make.globals: Enable FEATURES=multilib-strict by default

On śro, 2017-07-26 at 11:29 -0700, Zac Medico wrote: > On Wed, Jul 26, 2017 at 10:11 AM, Michał Górny wrote: > > On śro, 2017-07-26 at 09:58 -0700, Zac Medico wrote: > > > On Wed, Jul 26, 2017 at 12:20 AM, Michał Górny wrote: > > > > Enable the

Re: [gentoo-portage-dev] [PATCH] make.globals: Enable FEATURES=multilib-strict by default

On Wed, Jul 26, 2017 at 10:11 AM, Michał Górny wrote: > On śro, 2017-07-26 at 09:58 -0700, Zac Medico wrote: >> On Wed, Jul 26, 2017 at 12:20 AM, Michał Górny wrote: >> > Enable the multilib-strict feature necessary for Portage to detect >> > ebuilds not

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

On 07/26/2017 07:20 PM, Rich Freeman wrote: > Also, I suggest using either URLs or bug numbers, but not both. > Otherwise you end up having to copy the URL over, then copy the ID > only and paste it in the summary. That is an extra step. I wouldn't have bug ID in summary at all unless it

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

On Wed, Jul 26, 2017 at 1:04 PM, Kristian Fiskerstrand wrote: > On 07/26/2017 11:21 AM, Ulrich Mueller wrote: >> The same applies to #123456 in the summary line, though. I don't see a >> good reason for using a URL after the "Bug:" keyword as long as bare >> numbers are used

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

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 > previous commit This use should be forbidden. > ** Bug:

Re: [gentoo-portage-dev] [PATCH] make.globals: Enable FEATURES=multilib-strict by default

On śro, 2017-07-26 at 09:58 -0700, Zac Medico wrote: > On Wed, Jul 26, 2017 at 12:20 AM, Michał Górny wrote: > > Enable the multilib-strict feature necessary for Portage to detect > > ebuilds not respecting libdir for libraries. Since those issues were > > reliably fixed over

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

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 informative without having bug ID at all. Summary should describe

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

On 07/26/2017 11:21 AM, Ulrich Mueller wrote: > The same applies to #123456 in the summary line, though. I don't see a > good reason for using a URL after the "Bug:" keyword as long as bare > numbers are used elsewhere. For Bug you'd often refer to upstream reports or other distros, so you need

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

On 07/25/2017 01:25 PM, Michael Orlitzky wrote: > There are two main advantages over having the bug number in the summary. > Space is at a premium in the summary, as Tobias pointed out, and the > > Gentoo-Bug: whatever > > format is trivially machine-readable, whereas sticking it somewhere

Re: [gentoo-portage-dev] [PATCH] make.globals: Enable FEATURES=multilib-strict by default

On Wed, Jul 26, 2017 at 12:20 AM, Michał Górny wrote: > Enable the multilib-strict feature necessary for Portage to detect > ebuilds not respecting libdir for libraries. Since those issues were > reliably fixed over the years and we're nearing the removal of 'lib' > symlink, I

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

I am not yet an official developer but I am interested in assisting in maintaining this. On Wed, Jul 26, 2017, 6:04 AM Mart Raudsepp wrote: > Ühel kenal päeval, K, 26.07.2017 kell 11:56, kirjutas Pacho Ramos: > > sys-boot/plymouth is orphan for a long time. Its old 0.8.x

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

On 7/25/2017 4:05 AM, 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. >

[gentoo-dev] Lastrites: dev-lang/gnat-gcc, x11-apps/spotlighter, dev-scheme/stalin...

# Pacho Ramos (26 Jul 2017) # Severely broken with lots of unresolved bugs, outdated, needs a dedicated # maintainer (#402157). Removal in a month. dev-lang/gnat-gcc virtual/gnat # Pacho Ramos (26 Jul 2017) # Upstream dead, cannot be bumped, buggy (#468128).

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

Ühel kenal päeval, K, 26.07.2017 kell 11:56, kirjutas Pacho Ramos: > sys-boot/plymouth is orphan for a long time. Its old 0.8.x versions > where having > important bugs that were fixed in 0.9.x, but 0.9 is also plenty of > issues. Then, > either this is adopted by someone able to handle all that

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

sys-boot/plymouth is orphan for a long time. Its old 0.8.x versions where having important bugs that were fixed in 0.9.x, but 0.9 is also plenty of issues. Then, either this is adopted by someone able to handle all that issues or we will need to finally treeclean (and drop its support for

[gentoo-dev] sys-kernel/openvz-sources needs a dedicated maintainer

Currently is maintained needed, and going ahead and bumping it when we notice how outdated and vulnerable to security issues is not enough. This needs a dedicated maintainer taking care of bumping when needed. Hence, feel free to get it if you want to still keep it alive. Thanks

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

> On Tue, 25 Jul 2017, Michał Górny wrote: > On wto, 2017-07-25 at 09:26 -0400, Rich Freeman wrote: >> There would also be less variation. Bug: 123456 is pretty >> unambiguous as a reference. When you start having http vs https and >> maybe a few different ways of creating a URL to a bug it

[gentoo-portage-dev] [PATCH] make.globals: Enable FEATURES=multilib-strict by default

Enable the multilib-strict feature necessary for Portage to detect ebuilds not respecting libdir for libraries. Since those issues were reliably fixed over the years and we're nearing the removal of 'lib' symlink, I think we can safely enable it by default for our users without risking many