> 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, a
> On Mon, 2 May 2016, Göktürk Yüksek wrote:
> -descriptions. Slot operators are not allowed inside ,
> +descriptions. Slot operators are not preferred inside ,
A "slot operator" (like :* or :=) is not what is meant here, but
a "slot dependency". These terms are defined in PMS:
https
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 ca
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 app
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 the
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
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 th
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
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 mai
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 accepting my retireme
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 days only to merge one c
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 retiremen
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 t
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 opposed
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 entire tree?
I can see how
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 avoided and
>we all are
>>> on the same
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 index when you made th
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 thi
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 think that's a bit excess
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, and asked
"What is t
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 etc,
>>
>> 4. announce to the list a date/ti
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 hack
>>>
>>> 3. test the merge for any confli
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 Żołnowski
Yes, this is e
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
until ; do ; done
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 l
-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
>> , +descriptions. Slot operators are not preferred
>> inside ,
>
> A "slot operator" (like :* or :=) is not
-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 specifi
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 a space-separated
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 the log graph after a
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, then the fact they re-si
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
b/ebuild-writing/variables/text.xm
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 emp
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 s
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 fine from my perspecti
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 actually look less messy.
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 liste
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 C
-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
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
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 p
40 matches
Mail list logo
