Re: [gentoo-dev] amd64 and x32 systemd stages should be ready

On 5/7/2016 11:52 AM, Andreas K. Huettel wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Samstag, 7. Mai 2016, 19:47:55 schrieb Andreas K. Huettel: Am Samstag, 7. Mai 2016, 17:09:50 schrieb Anthony G. Basile: Hi everyone, I've been pushing out systemd stage3s for amd64 and x86 and

Re: [gentoo-dev] News Item: LastPass package migration

On Sun, 8 May 2016 01:25:58 -0400 Göktürk Yüksek wrote: > Display-If-Installed: app-admin/lastpass Every version, forever, even for new installs made next year? -- Ciaran McCreesh

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2016-05-08 23:59 UTC

-09:26 zmedico8abfc83 dev-util/abi-dumper 20160508-17:01 floppym6f7df16 dev-util/electron20160405-16:29 monsieurp 1b29990 dev-util/serialtalk 20160505-21:53 idella4a6f9a96 dev-util/vtable-dumper 20160508-16:50 floppymeb21a13 games-arcade

Re: [gentoo-dev] News Item: LastPass package migration

On 08/05/16 16:56, Andrew Udvare wrote: > On 07/05/16 22:25, Göktürk Yüksek wrote: >> Users of Chrome/Chromium and Opera browsers need to switch to >> app-admin/lastpass-binary-features and follow the instructions >> displayed on the screen after the installation to complete the process. >> > For

Re: [gentoo-dev] News Item: LastPass package migration

On 07/05/16 22:25, Göktürk Yüksek wrote: > Users of Chrome/Chromium and Opera browsers need to switch to > app-admin/lastpass-binary-features and follow the instructions > displayed on the screen after the installation to complete the process. > For Chromium, is there supposed to be a plugin

Re: [gentoo-dev] On banning merge commits

On 05/08/2016 05:53 AM, Brian Dolbec wrote: > On Sun, 08 May 2016 11:06:09 +0100 > Amadeusz Żołnowski wrote: > >> I am working at the moment on debundling ejabberd. It will come with >> ~30 packages and I will do "git merge --no-ff ejabberd-debundled" >> because it will

Re: [gentoo-dev] News Item: LastPass package migration

On Sun, May 08, 2016 at 01:25:58AM -0400, Göktürk Yüksek wrote: > Title: LastPass package migration > Author: Robin H. Johnson I proxy the commits for you, so you should be listed as well (multiple author tags are permitted in the spec), and ahead of my name. Otherwise it's

[gentoo-dev] Re: On banning merge commits

Rich Freeman posted on Sun, 08 May 2016 08:34:37 -0400 as excerpted: > merges shouldn't just be used for random pull-requests. However, when > you're touching multiple packages/etc they should be considered. They > should also be considered if for some reason you had a bazillion commits > to a

[gentoo-dev] Re: On banning merge commits

Rich Freeman posted on Sun, 08 May 2016 07:57:17 -0400 as excerpted: > I think that bans are better used for bad attitude than for mistakes. [Stepping back from the immediate discussion at hand...] The above is wisdom, arguably, quotable sig-level wisdom! Certainly wisdom enough to be worth

[gentoo-dev] [PATCH] ebuild-writing/variables: better describe ROOT

The current description of ROOT makes no sense and just confuses people. The new description is paraphrased from PMS. --- ebuild-writing/variables/text.xml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/ebuild-writing/variables/text.xml

Re: [gentoo-dev] On banning merge commits

On 9 May 2016 at 05:03, Alexis Ballier wrote: > I was under the impression that merging is needed in order to preserve > commit signatures when e.g. merging someone else's work. Correct, but if the person applying the commits to tree is in fact reviewing them as they go,

Re: [gentoo-dev] On banning merge commits

On Sun, 8 May 2016 01:52:22 +0200 Patrice Clement wrote: > After yet another discussion about git in the #gentoo-dev channel > tonight, the topic of merge commits came up for the umpteenth time. > > We all seem to agree merge commits are really bad design, add clutter > to

Re: [gentoo-dev] [PATCH] l10n.eclass: Sort and normalize PLOCALES in l10n_find_plocales_change

On Sun, 8 May 2016 11:20:34 -0400 Michael Orlitzky wrote: > On 05/07/2016 04:13 PM, James Le Cuirot wrote: > > > > + if [[ $(tr -s "[:space:]" "\n" <<< "${PLOCALES}" | sort | > > xargs echo) != ${current%[[:space:]]} ]] ; then > > The stuff on the left-hand side just sorts

[gentoo-dev] Re: [PATCH v1 4/5] ebuild-writing/misc-files/metadata: move the GLEP 31 reference to the top

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ulrich Mueller: >> On Mon, 2 May 2016, Göktürk Yüksek wrote: > >> @@ -602,9 +603,7 @@ part of the QA reports. For categories, >> metadata.xml specifies a long description (in English and >> optionally in other languages). The format is

[gentoo-dev] Re: [PATCH v1 5/5] ebuild-writing/misc-files/metadata: add an example for slots and subslots

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Ulrich Mueller: >> On Mon, 2 May 2016, Göktürk Yüksek wrote: > >> -descriptions. Slot operators are not allowed inside >> pkg, +descriptions. Slot operators are not preferred >> inside pkg, > > A "slot operator" (like :* or :=) is not

Re: [gentoo-dev] [PATCH] l10n.eclass: Sort and normalize PLOCALES in l10n_find_plocales_change

On 05/07/2016 04:13 PM, James Le Cuirot wrote: > > + if [[ $(tr -s "[:space:]" "\n" <<< "${PLOCALES}" | sort | xargs echo) > != ${current%[[:space:]]} ]] ; then The stuff on the left-hand side just sorts a space-separated list, right? It might be time to split that into another function. It

Re: [gentoo-dev] On banning merge commits

On Sun, 8 May 2016 05:53:42 -0700 Brian Dolbec wrote: > It is these > larger commit branches that are much more difficult to "git pull > --rebase && git push --signed" successfully without some other pushes > in between causing a rejected non-fast forward push. You mean doing

Re: [gentoo-dev] On banning merge commits

On Sun, 08 May 2016 11:06:09 +0100 Amadeusz Żołnowski wrote: > I am working at the moment on debundling ejabberd. It will come with > ~30 packages and I will do "git merge --no-ff ejabberd-debundled" > because it will actually look less messy. > > Thanks, > -- Amadeusz

Re: [gentoo-dev] On banning merge commits

On 5/8/16 8:34 AM, Rich Freeman wrote: > On Sun, May 8, 2016 at 8:18 AM, Kent Fredric wrote: >> On 9 May 2016 at 00:09, Anthony G. Basile wrote: >>> 1. announce to gentoo-dev@ the intention to start a branch intending to >>> merge >>> >>> 2. hack hack

Re: [gentoo-dev] On banning merge commits

On Sun, May 8, 2016 at 8:18 AM, Kent Fredric wrote: > On 9 May 2016 at 00:09, Anthony G. Basile wrote: >> 1. announce to gentoo-dev@ the intention to start a branch intending to >> merge >> >> 2. hack hack hack >> >> 3. test the merge for any conflicts

Re: [gentoo-dev] On banning merge commits

On Sun, May 8, 2016 at 2:00 PM, Michał Górny wrote: > No, he didn't. He stated an imaginary fact ('we all seem to agree...'), and > asked how to *enforce* that formally. That's not how you request differing > opinions. He used "seem to" to state that it was his perspective,

Re: [gentoo-dev] On banning merge commits

On 9 May 2016 at 00:09, Anthony G. Basile wrote: > 1. announce to gentoo-dev@ the intention to start a branch intending to > merge > > 2. hack hack hack > > 3. test the merge for any conflicts etc, > > 4. announce to the list a date/time to merge > > 5. if okay, ermge I

Re: [gentoo-dev] On banning merge commits

On 5/8/16 7:25 AM, Andreas K. Hüttel wrote: > Am Sonntag, 8. Mai 2016, 01:52:22 schrieb Patrice Clement: >> >> What is the correct course of action? I would very much like it to be >> worded in a document (GLEP and/or Wiki page) so that confusion is avoided >> and we all are on the same page on

Re: [gentoo-dev] On banning merge commits

On 8 May 2016 at 23:57, Rich Freeman wrote: > How does a merge make it any easier/harder to mess up the entire tree? > I can see how they can make the history easier/harder to read but in > the end I believe the content of the tree itself ends up being > whatever was in the

Re: [gentoo-dev] On banning merge commits

Dnia 8 maja 2016 12:30:15 CEST, Dirkjan Ochtman napisał(a): >On Sun, May 8, 2016 at 7:09 AM, Michał Górny wrote: >>> What is the correct course of action? I would very much like it to >be worded in >>> a document (GLEP and/or Wiki page) so that confusion is

Re: [gentoo-dev] On banning merge commits

On Sun, May 8, 2016 at 7:25 AM, Andreas K. Hüttel wrote: > > * However... as the past months have shown, when using merges it is much > easier to accidentally mess up the entire tree than using rebases alone. > How does a merge make it any easier/harder to mess up the

Re: [gentoo-dev] On banning merge commits

Am Sonntag, 8. Mai 2016, 01:52:22 schrieb Patrice Clement: > > What is the correct course of action? I would very much like it to be > worded in a document (GLEP and/or Wiki page) so that confusion is avoided > and we all are on the same page on this topic. > OK here's my 2ct: * I'm not

Re: [gentoo-dev] On banning merge commits

On 08/05/16 12:13, Andreas K. Hüttel wrote: > Am Sonntag, 8. Mai 2016, 07:09:31 schrieb Michał Górny: >>> What is the correct course of action? I would very much like it to be >>> worded in a document (GLEP and/or Wiki page) so that confusion is >>> avoided and we all are on the same page on this

Re: [gentoo-dev] On banning merge commits

Am Sonntag, 8. Mai 2016, 07:09:31 schrieb Michał Górny: > > What is the correct course of action? I would very much like it to be > > worded in a document (GLEP and/or Wiki page) so that confusion is > > avoided and we all are on the same page on this topic. > > You start by accepting my

Re: [gentoo-dev] Re: On banning merge commits

On Sun, May 8, 2016 at 11:25 AM, Kent Fredric wrote: > The essential idea being to minimise the amount of congnitive effort a > human has when trying to explore the history and understand what > "actually happened" from a master perspective. > > "Long histories that go for

Re: [gentoo-dev] On banning merge commits

On Sun, May 8, 2016 at 7:09 AM, Michał Górny wrote: >> What is the correct course of action? I would very much like it to be worded >> in >> a document (GLEP and/or Wiki page) so that confusion is avoided and we all >> are >> on the same page on this topic. > > You start by

[gentoo-dev] Re: On banning merge commits

Kent Fredric posted on Sun, 08 May 2016 21:25:38 +1200 as excerpted: > On 8 May 2016 at 20:58, Duncan <1i5t5.dun...@cox.net> wrote: >> Or to put it a different way, if we're not going to use git's rich >> distributed branch development and tracking, forcing everything to >> single chain on the

Re: [gentoo-dev] On banning merge commits

I am working at the moment on debundling ejabberd. It will come with ~30 packages and I will do "git merge --no-ff ejabberd-debundled" because it will actually look less messy. Thanks, -- Amadeusz Żołnowski signature.asc Description: PGP signature

Re: [gentoo-dev] On banning merge commits

On 05/08/2016 01:21 AM, Greg KH wrote: > On Sun, May 08, 2016 at 01:44:43PM +0800, cbergst...@pathscale.com wrote: >> Don't be crazy - I know many developer groups which dislike merge >> commits. That nonlinear work flow is just a mess long term. > > Really? What "mess" does it cause? > > Are

Re: [gentoo-dev] Re: On banning merge commits

On 8 May 2016 at 20:58, Duncan <1i5t5.dun...@cox.net> wrote: > Or to put it a different way, if we're not going to use git's rich > distributed branch development and tracking, forcing everything to single > chain on the main tree, why did we bother switching to git in the first > place? That was

Re: [gentoo-dev] On banning merge commits

Hi all, On Sun, 8 May 2016 01:52:22 +0200 Patrice Clement wrote: > Hi gents > > After yet another discussion about git in the #gentoo-dev channel tonight, the > topic of merge commits came up for the umpteenth time. > > We all seem to agree merge commits are really bad design, add clutter to

[gentoo-dev] Re: On banning merge commits

cbergstrom posted on Sun, 08 May 2016 13:44:43 +0800 as excerpted: > Don't be crazy - I know many developer groups which dislike merge > commits. That nonlinear work flow is just a mess long term. Said by someone who apparently can't figure out reasonable quote then reply-in-context, or even

Re: [gentoo-dev] On banning merge commits

On Sun, May 08, 2016 at 01:44:43PM +0800, cbergst...@pathscale.com wrote: > Don't be crazy - I know many developer groups which dislike merge > commits. That nonlinear work flow is just a mess long term. Really? What "mess" does it cause? Are things harder to bisect? Harder to determine what

[gentoo-dev] Re: [PATCH v1 5/5] ebuild-writing/misc-files/metadata: add an example for slots and subslots

> On Mon, 2 May 2016, Göktürk Yüksek wrote: > -descriptions. Slot operators are not allowed inside pkg, > +descriptions. Slot operators are not preferred inside pkg, A "slot operator" (like :* or :=) is not what is meant here, but a "slot dependency". These terms are defined in PMS:

[gentoo-dev] Re: [PATCH v1 4/5] ebuild-writing/misc-files/metadata: move the GLEP 31 reference to the top

> On Mon, 2 May 2016, Göktürk Yüksek wrote: > @@ -602,9 +603,7 @@ part of the QA reports. > For categories, metadata.xml specifies a long description (in > English and optionally in other languages). The format is specified > formally in https://wiki.gentoo.org/wiki/GLEP:34;> > -GLEP 34,