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

[Matthew Marchese]

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 putting them
under our official releases at [1] and [2].  I think all the bugs are
out and those stages are pretty tight.  The next step is for me to
advertise them at [3].

Great- thank you !!!

And for whoever wants to advertise:


On request (what it "just works" without systemd???), here's the more
symmetric selection of posters:

http://dev.gentoo.org/~dilfridge/poster/gentoo-abducted_A0_choice_2.pdf
http://dev.gentoo.org/~dilfridge/poster/gentoo-abducted_A0_choice_3.pdf

:)

- -- 


Andreas K. Huettel
Gentoo Linux developer
dilfri...@gentoo.org
http://www.akhuettel.de/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJXLjl/XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB
NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnkaZ0QANEEM6P6XmsS2FAWnDzdH0lI
FxZv+mVOp8iFjG5qALG2CCDZjHv26R0RqQgvWirs12vuX28gRonB07PzvjieQsus
YcNkNeBxGi8cgoYuEJnN6ROMdJGYq71ZhFZ6QX+5XolDUyuwYIr03aBuAnKDFxLE
oXBcmh1N45qCah3pQzEh6sbYuBDTvgUwTSHaD6XgWsd5Ln4FWmjyJ3c3EOY3wwEA
rdO52of9IJxeuj+6TE4+W5A5V0An0JO/jc8tXzpp7mAKWIFavd9HBQXIUhT9CaOP
du29a3RaM+DeIgSb+eFjED/H1Qo8Bq+QRN3f3RbedUr60F7F1YLtBaG45SRhF1Mi
qUKV2y9YZ7NBZzoCdVOEqDVamGVkY+Z2HACdM6nWscwh9misPWXLXZwAqJE3Dlpo
LHGykFukDZv/6CuX0WhUwPK2doEv7YD1DZ/qTB2WMAVC7N8rQfDMEtrnCMK7Bx42
cU+1aoVKtcQF8Cf6AcH4ijF21+ORxGRxtYpiCy4cQCOxw+hc2d9JyBsQPIBI9pKQ
P4SFT3qcg9+CsY3XYdGFggGwP2dwRhp8AzA69LDdkSa7ObHv1r9gZQgNduCAcjTh
fAJkdFtDd4kRtR5JfNfFwnle6ztnAlCoDNto2edphhlZY6QOnaPjkaKlyb44J894
gGIHyjoXz+5TYzrHO1Xe
=gYyU
-END PGP SIGNATURE-


Looks good. Nice work, fellas.

I'll do some testing of my own on those stage tarballs so that I can 
write some docs, unless you'd like to write them, blueness. This should 
ease the path on the systemd "Handbook extension" idea I've been 
throwing around.

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

[Ciaran McCreesh]

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

[Robin H. Johnson]

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2016-05-08 23:59 UTC.

Removals:
app-dicts/myspell-de-alt 20160506-00:05 ulmb8bae86
dev-java/java-config-wrapper 20160502-20:39 chewi  0a822e4
dev-lang/niecza  20160502-06:22 patrickbc7d78b
dev-lang/niecza-bin  20160502-06:22 patrickbc7d78b
dev-libs/ptypes  20160505-21:09 soap   e655a96
games-simulation/planets 20160503-06:11 mr_bones_  c4f996d
kde-misc/kte-collaborative   20160506-16:52 kensington 77ab130
net-libs/libqinfinity20160506-16:53 kensington e009e46

Additions:
app-dicts/myspell-de_190120160506-00:05 ulmb8bae86
app-editors/kakoune  20160505-18:14 idella4fbffc0e
app-misc/mosquitto   20160506-13:23 wraeth a5b7325
app-text/fbpdf   20160507-12:41 slyfox 778f699
dev-ml/js-build-tools20160501-17:02 aballier   7b876a3
dev-perl/Devel-Leak  20160502-18:03 dilfridge  3b5c4bc
dev-python/nnpy  20160503-09:54 aballier   fdca527
dev-python/pyrqlite  20160502-07:35 zmedico6bd2a4d
dev-python/sqlalchemy-rqlite 20160502-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/savagewheels20160403-00:25 monsieurp  ef86f45

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
net-libs/libqinfinity,removed,kensington,20160506-16:53,e009e46
kde-misc/kte-collaborative,removed,kensington,20160506-16:52,77ab130
app-dicts/myspell-de-alt,removed,ulm,20160506-00:05,b8bae86
dev-libs/ptypes,removed,soap,20160505-21:09,e655a96
games-simulation/planets,removed,mr_bones_,20160503-06:11,c4f996d
dev-java/java-config-wrapper,removed,chewi,20160502-20:39,0a822e4
dev-lang/niecza-bin,removed,patrick,20160502-06:22,bc7d78b
dev-lang/niecza,removed,patrick,20160502-06:22,bc7d78b
Added Packages:
dev-util/abi-dumper,added,floppym,20160508-17:01,6f7df16
dev-util/vtable-dumper,added,floppym,20160508-16:50,eb21a13
app-text/fbpdf,added,slyfox,20160507-12:41,778f699
app-misc/mosquitto,added,wraeth,20160506-13:23,a5b7325
dev-util/serialtalk,added,idella4,20160505-21:53,a6f9a96
app-editors/kakoune,added,idella4,20160505-18:14,fbffc0e
app-dicts/myspell-de_1901,added,ulm,20160506-00:05,b8bae86
dev-util/electron,added,monsieurp,20160405-16:29,1b29990
games-arcade/savagewheels,added,monsieurp,20160403-00:25,ef86f45
dev-python/nnpy,added,aballier,20160503-09:54,fdca527
dev-ml/js-build-tools,added,aballier,20160501-17:02,7b876a3
dev-perl/Devel-Leak,added,dilfridge,20160502-18:03,3b5c4bc
dev-python/sqlalchemy-rqlite,added,zmedico,20160502-09:26,8abfc83
dev-python/pyrqlite,added,zmedico,20160502-07:35,6bd2a4d

Done.

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

[Andrew Udvare]

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 Chromium, is there supposed to be a plugin listed in
> chrome://plugins after installation? Supposedly I enabled native
> messaging for the plugin but nothing for LastPass is listed at
> chrome://plugins.
> 
> Andrew
> 
Actually I think I got it. Once you do everything correctly, and you go to

chrome://extensions/?options=hdokiejnpimakedhajhdlcegeplioahd (LastPass
extension options)

under 'Advanced', you will not see a link to install the binary
component anymore.

Andrew



signature.asc
Description: OpenPGP digital signature

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

[Andrew Udvare]

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 listed in
chrome://plugins after installation? Supposedly I enabled native
messaging for the plugin but nothing for LastPass is listed at
chrome://plugins.

Andrew



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] On banning merge commits

[Daniel Campbell]

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.
>>
>> Thanks,
>> -- Amadeusz Żołnowski
> 
> 
> Yes, this is exactly the type of merge commits that should be allowed.
> 
> Not the one or two user PR commits that might be based on a weeks old
> tree, that a developer merges without rebasing.  It is these merge
> commits which have caused all the grief we've experienced over merge
> commits.
> 
> Merge commits should be used wisely and for larger branch merges like
> the kde, gnome team's development overlay merges to the main tree or
> similar larger one off project's like the one above.  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.
> 
I think you touched on the key phrase we should be taking from the
conversation: 'merges without rebasing'. Devs are encouraged -- if not
required -- to push commits after rebasing, to ensure we're pushing to
the latest HEAD and not something that's stale. If we hold merges to the
same standard, would the problems that some have with merge commits
disappear?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

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

[Robin H. Johnson]

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 perspective, but somebody else should review
it.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead, Foundation Trustee
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

[gentoo-dev] Re: On banning merge commits

[Duncan]

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 single package that for some reason shouldn't be rebased.
> I imagine that they'll be a small portion of commits as a result.
> However, for the situations where they're appropriate they make a lot of
> sense.
> 
> This was some of Duncan's point, but I will comment that we'll never
> have as clean a history as the kernel simply because we don't have a
> release-based workflow with the work cascading up various trees.  The
> kernel is almost an ideal case for a merge-based workflow.  I imagine
> that half of Gentoo's commit volume is random revbumps and keyword
> changes and that is just going to be noise no matter what.  If we were
> release-based we could do that stuff in its own branch and merge it all
> in at once, but that just isn't us.

Recognized and agree.  Thanks.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: On banning merge commits

[Duncan]

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 emphasizing by calling it out in a 
quote as I'm doing here. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[Mike Gilbert]

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.xml
index ef15347..6ba6379 100644
--- a/ebuild-writing/variables/text.xml
+++ b/ebuild-writing/variables/text.xml
@@ -100,8 +100,9 @@ them.
   
 ROOT
 
-  Path to the root directory. When not using ${D},
-  always prepend ${ROOT} to the path.
+  The absolute path to the root directory into which the package is to be 
merged.
+  Use this when refering to installed files in pkg_* functions.
+  Never use this in src_* functions.
 
   
   
-- 
2.8.2

Re: [gentoo-dev] On banning merge commits

[Kent Fredric]

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-sign it with their
own signature
( and changing the commits "Committed by" in the process ) pretty much
means the chain of custody is preserved.

That is, the fact the original signature is lost is immaterial,
because we only need it as a signature that /somebody/ actually is
responsible for the commit, and the person performing the rebase takes
the essential responsibility in the process.

The original author metadata is however, not lost in this process,
only commit metadata changes. ( And the signature is commit metadata,
not author metadata )

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] On banning merge commits

[Alexis Ballier]

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 while and should be banned altogether from
> reaching the central repository.

They don't clutter the log graph at all, if you admit it is a graph and
not a chain :)

 
> As of now, no policy is in place yet to keep developers from pushing
> merge commits.


I was under the impression that merging is needed in order to preserve
commit signatures when e.g. merging someone else's work.

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

[James Le Cuirot]

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 list,
> right? It might be time to split that into another function. It looks
> a lot less insane when it's,
> 
>   if [[ $(l10n_sort_spaces "${PLOCALES}") != ${current%[[:space:]]} ]]
> 
> Then the  function would just be
> 
>   # @FUNCTION: l10n_sort_spaces
>   # @DESCRIPTION:
>   # Takes a space-separated list of strings as an argument and sorts
>   # them. The output is again space-separated. This is accomplished
>   # by first replacing the spaces with newlines so that "sort" can
>   # be used, and then collecting the output back onto one line.
>   function l10n_sort_spaces() {
> tr -s "[:space:]" "\n" <<< "${1}" | sort | xargs echo
>   }
> 
> You should also document why you're doing that nearby, since like you
> said, the eclass assumes that PLOCALES is sorted. Someone will wonder
> why you're doing it again.

I feel an extra function for something we're only doing once is a bit
redundant. I was happy to add a short explanation though so I did that.
Merged it now.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpH4R76seazb.pgp
Description: OpenPGP digital signature

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

[Göktürk Yüksek]

-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 specified formally 
>> in https://wiki.gentoo.org/wiki/GLEP:34;> -GLEP 
>> 34, and the character set must be UTF-8 as specified
>> -by https://wiki.gentoo.org/wiki/GLEP:31;>GLEP
>> -31. A typical example: +GLEP 34. A typical example:
> 
> The reference to GLEP 34 should be replaced by GLEP 68 which 
> supersedes it.
> 
I'll remove the reference altogether since GLEP 68 is mentioned at the
beginning of the Syntax section and the table clearly lists
 in there.

> Ulrich
> 

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJXL1ulAAoJEIT4AuXAiM4zeeUH/jrBuiIKDveFMtKwa55RD7Z9
o4JixDmN1vIU2nHppjAaJE8O8IhSTKStt2fWrpQoUsTlCRYrjVjcD9SUuF4hpdCN
hFoLizYXaPc1rAnPOciwLeJuvPutFZfi6/pwWJcZ1u3yJwa+A5hyVCpye4c1fiJ0
QtZSGRhrfVHmhKkprXIwwKRefjh7X8HwGCJS/VyVGYLonfgd8hPWJLRD2iEQOEHG
2JQCYQqGwPPQogLy9E0WmzUPCBt8j/Ifh29y9tpz92FjfEpwFkLa4a2TkbgictPG
r0u6xMk5MbgRZtoywUQVUC0+i8ryTidR4AVw3kgfsfmfN2hMR8FY8hPKl5oO8AU=
=41M0
-END PGP SIGNATURE-

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

[Göktürk Yüksek]

-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 what is meant here, but a
> "slot dependency". These terms are defined in PMS: 
> https://projects.gentoo.org/pms/6/pms.html#x1-860008.2.6.3
> 
Thanks for the clarification in terminology, I'll update accordingly.

> Also I think that the previous wording was more accurate here. Slot
> dependencies are not allowed inside .
> 
Thanks for pointing out. I was a bit confused when I first read in the
GLEP: "it is recommended to move the slot specifiers out of 
element." The specification clearly says "must contain a valid
qualified package name" however. Will revert back to the original.

> Ulrich
> 

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJXL1s/AAoJEIT4AuXAiM4z6eEIAOey+sMcvU58U+NTmJjS9RpB
cAkvLLCGOOda3jr9Aceoa1eFX6rSAume7TbT3XfjrywgHoApmUVJPkBtAl+a4WK/
ll+BZ2uk9Ao5mqqX2S93UappSUqrbEMqQXFwT9YBoRM/2w1Tcd4YVcyuUaQXkwOM
wvhCTgX6kKn+9GXNKkO2lf1KL7xBVyHS/WpMvrEaClH91exllPEGHM1k9Rj2Fd0C
yDCLICQ+UW5KkKEVc/E6drVYmtmW1YR7jL2sMXQmHfbPS/8F1egg6bk1hNSHWxNh
sH/1gizrRN+ofIrTYic0G4z8Np/vCNcS6OwGaS/Rz8klGc9tzQEyhoUXPTISMxQ=
=iKO+
-END PGP SIGNATURE-

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

[Michael Orlitzky]

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 looks a
lot less insane when it's,

  if [[ $(l10n_sort_spaces "${PLOCALES}") != ${current%[[:space:]]} ]]

Then the  function would just be

  # @FUNCTION: l10n_sort_spaces
  # @DESCRIPTION:
  # Takes a space-separated list of strings as an argument and sorts
  # them. The output is again space-separated. This is accomplished
  # by first replacing the spaces with newlines so that "sort" can
  # be used, and then collecting the output back onto one line.
  function l10n_sort_spaces() {
tr -s "[:space:]" "\n" <<< "${1}" | sort | xargs echo
  }

You should also document why you're doing that nearby, since like you
said, the eclass assumes that PLOCALES is sorted. Someone will wonder
why you're doing it again.

Re: [gentoo-dev] On banning merge commits

[Jeroen Roovers]

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

is not already as optimal as you could get?


 jer

Re: [gentoo-dev] On banning merge commits

[Brian Dolbec]

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 exactly the type of merge commits that should be allowed.

Not the one or two user PR commits that might be based on a weeks old
tree, that a developer merges without rebasing.  It is these merge
commits which have caused all the grief we've experienced over merge
commits.

Merge commits should be used wisely and for larger branch merges like
the kde, gnome team's development overlay merges to the main tree or
similar larger one off project's like the one above.  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.
-- 
Brian Dolbec 



pgpSUtzSFxJgr.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] On banning merge commits

[Anthony G. Basile]

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 conflicts etc,
>>>
>>> 4. announce to the list a date/time to merge
>>>
>>> 5. if okay, ermge
>>
>> It would make much sense for this series to be visible on Master as a
>> "add Perl 5.24 to tree" commit, because all the changes are inherently
>> interdependent,
>> and it would make little sense to rewind to a specific point within
>> that series and use it as a portage tree.
>>
>> But that's not significant enough to warrant a lot of formal fluffing around.
>>
>> It for sure would be best if that 100 commit range was rebased before
>> merging, but it should still be a non-fast-forward merge just to keep
>> the history logical.
>>
> 
> ++
> 
> merges shouldn't just be used for random pull-requests.  However, when
> you're touching multiple packages/etc they should be considered.  

i was actually thinking of sec-policy where i remember writing a script
back in the CVS days that did some 200 commits, one after another.  i
was migrating some work for Swift from an overlay to the main tree.


They
> should also be considered if for some reason you had a bazillion
> commits to a single package that for some reason shouldn't be rebased.

a bazillion commits to a category that almost no one touches and except
one person or team, like sec-policy or dev-perl etc.

so again, i'm against an outright banning of merge commits, but we need
to restrict them to reasonable cases, "reasonable" being judged by the
community.

> I imagine that they'll be a small portion of commits as a result.
> However, for the situations where they're appropriate they make a lot
> of sense.
> 
> This was some of Duncan's point, but I will comment that we'll never
> have as clean a history as the kernel simply because we don't have a
> release-based workflow with the work cascading up various trees.  The
> kernel is almost an ideal case for a merge-based workflow.  I imagine
> that half of Gentoo's commit volume is random revbumps and keyword
> changes and that is just going to be noise no matter what.  If we were
> release-based we could do that stuff in its own branch and merge it
> all in at once, but that just isn't us.
> 
> --
> Rich
> 


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] On banning merge commits

[Rich Freeman]

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/time to merge
>>
>> 5. if okay, ermge
>
> It would make much sense for this series to be visible on Master as a
> "add Perl 5.24 to tree" commit, because all the changes are inherently
> interdependent,
> and it would make little sense to rewind to a specific point within
> that series and use it as a portage tree.
>
> But that's not significant enough to warrant a lot of formal fluffing around.
>
> It for sure would be best if that 100 commit range was rebased before
> merging, but it should still be a non-fast-forward merge just to keep
> the history logical.
>

++

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 single package that for some reason shouldn't be rebased.
I imagine that they'll be a small portion of commits as a result.
However, for the situations where they're appropriate they make a lot
of sense.

This was some of Duncan's point, but I will comment that we'll never
have as clean a history as the kernel simply because we don't have a
release-based workflow with the work cascading up various trees.  The
kernel is almost an ideal case for a merge-based workflow.  I imagine
that half of Gentoo's commit volume is random revbumps and keyword
changes and that is just going to be noise no matter what.  If we were
release-based we could do that stuff in its own branch and merge it
all in at once, but that just isn't us.

--
Rich

Re: [gentoo-dev] On banning merge commits

[Dirkjan Ochtman]

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 the correct course of action?", which to me does not at all
read as only being about formal enforcement.

> It's rather the common Gentoo reboot in which for Nth time you propose the 
> same thing, pretend that all previous opposition didn't happen and hope 
> people will be tired enough to let you have what you want.

Apparently the previous times it was discussed there was no
satisfactory resolution, or the topic (or understanding thereof) has
advanced since then. Perhaps we should GLEPs more to document such
discussions, so that we don't have to repeat them all the time.

> My response is also a common Gentoo response to bad ideas, and it shouldn't 
> come as a surprise to anyone.

Well, even if it's common, I think it's much worse than Patrice's
initial email. If you think something is a bad idea, lay out why you
think so. If you don't want to repeat yourself, write it up in an
email list or blog post that you can link to after the fact. Your
response of posing a threat of quitting is not productive at all, and
seems kind of childish to me.

Cheers,

Dirkjan

Re: [gentoo-dev] On banning merge commits

[Kent Fredric]

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 excessive myself. I dislike merges, but I don't
hate them *quite* that much to justify such formality.

Because IMO, its not about forbidding merges, its about making sure
the use of merges is appropriate and effective.

For instance, stabilizing ~100 ebuilds in response to a single stable
request, it would make logical sense to group all those stabilizations
so that they appear on the left side as a single atomic change, while
still existing as a series on the right side of the branch for
historical accuracy
and for other practical reasons ( like simplified commit reverts )

Pretty much *anything* that does "bulk changes for single purpose" is
a good candidate for a merge.

For instance, there's ~100 commits sitting around somewhere in a
repository for introducing Perl 5.24 to the tree, which requires a
commit for each and every entry in virtual/perl-*

It would make much sense for this series to be visible on Master as a
"add Perl 5.24 to tree" commit, because all the changes are inherently
interdependent,
and it would make little sense to rewind to a specific point within
that series and use it as a portage tree.

But that's not significant enough to warrant a lot of formal fluffing around.

It for sure would be best if that 100 commit range was rebased before
merging, but it should still be a non-fast-forward merge just to keep
the history logical.



-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] On banning merge commits

[Anthony G. Basile]

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 this topic.
>>
> 
> * 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.
> 
> * So, in an ideal world we would use merges wisely and sparingly.

Correct.  I don't support outright banning merge commits, but they
should be reviewed carefully, like we do with other big commits to the
tree.  So maybe proceed as follows:

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

> 
> * In the real world, we risk less and also lose less if we ban and 
> technically 
> prevent them.
> 
> * The only alternative would be to come up with criteria for merges and 
> actually enforce them (meaning, if you mess up the tree more than twice you 
> lose your push access. Hello QA.).
> 


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] On banning merge commits

[Kent Fredric]

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 the commit.
>
>>
>> * The only alternative would be to come up with criteria for merges and
>> actually enforce them (meaning, if you mess up the tree more than twice you
>> lose your push access. Hello QA.).
>>
>
> Here is the other only alternative: use rebase commits when they're
> most appropriate, and use merge commits when they're most appropriate,
> and publish easy-to-understand guidelines for when each is the case.
> I don't really see a need for hard rules unless we think devs can
> actually comply with them.  Do we really want somebody to lose their
> commit access because they pushed a string of rebased commits that
> might have been more appropriate as a single merge commit?
>
> Both types of commits have their place.  I think that bans are better
> used for bad attitude than for mistakes.  I don't think you need a
> 100% rigid rule to enforce a ban either - this isn't a court of law
> (and I think many of the failings of courts of law result from the
> rigid application of rules, but that is a different matter).

I'd probably say any case where you have to resolve a conflict in the
merge commit is a clear indicator that the right branch needed
rebasing prior to merging, either way.

mostly, because it means some change on the right side becomes
transiently dependent on a change on the left side, and its obscured
by the resolution mid-merge.

( And such conflicts tend not to be even obvious that they've existed
when traversing a history with merge commits, because "merge diffs"
get suppressed by default ).

And its usually not clear what the "Solution" is when you're simply
comparing 2 heads.

With a rebase, you know exactly what the expected change is at the
commit that makes the change, and the rebase lets you see what the
existing state was at the time of applying the change.

Merges without conflicts however are much less contentious.

In short, if you get a merge conflict, then somebody needs to pay more
attention to what happened on one side of the changes, and one side of
that equation should be rebased to avoid that conflict.


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] On banning merge commits

[Michał Górny]

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 page on this topic.
>>
>> You start by accepting my retirement.
>
>Hey Michał,
>
>Patrice is just opening up a discussion on a mailing list. Clearly
>there are opposing viewpoints on whether we should use merge commits
>and/or how often. Making vague threats without any rationale/reasoning
>about why you would dislike any change in this direction is completely
>unproductive for the Gentoo community. I would be very interested in
>what your proposed way forward is, and why.

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.

It's rather the common Gentoo reboot in which for Nth time you propose the same 
thing, pretend that all previous opposition didn't happen and hope people will 
be tired enough to let you have what you want.

My response is also a common Gentoo response to bad ideas, and it shouldn't 
come as a surprise to anyone.

-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] On banning merge commits

[Rich Freeman]

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

>
> * The only alternative would be to come up with criteria for merges and
> actually enforce them (meaning, if you mess up the tree more than twice you
> lose your push access. Hello QA.).
>

Here is the other only alternative: use rebase commits when they're
most appropriate, and use merge commits when they're most appropriate,
and publish easy-to-understand guidelines for when each is the case.
I don't really see a need for hard rules unless we think devs can
actually comply with them.  Do we really want somebody to lose their
commit access because they pushed a string of rebased commits that
might have been more appropriate as a single merge commit?

Both types of commits have their place.  I think that bans are better
used for bad attitude than for mistakes.  I don't think you need a
100% rigid rule to enforce a ban either - this isn't a court of law
(and I think many of the failings of courts of law result from the
rigid application of rules, but that is a different matter).

-- 
Rich

Re: [gentoo-dev] On banning merge commits

[Andreas K. Hüttel]

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 to merge commits in principle, and see a few cases where 
they have advantages.

* Git has the provisions for nonlinear history, and just not liking spaghetti 
is no sufficient reason to castrate the entire version control system.

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

* So, in an ideal world we would use merges wisely and sparingly.

* In the real world, we risk less and also lose less if we ban and technically 
prevent them.

* The only alternative would be to come up with criteria for merges and 
actually enforce them (meaning, if you mess up the tree more than twice you 
lose your push access. Hello QA.).

-- 
Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-dev] On banning merge commits

[M. J. Everitt]

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 topic.
>> You start by accepting my retirement.
> I think you should take a vacation for a while... Preferably somewhere 
> tropical, with no internet access and lots of beach... 
>
+5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] On banning merge commits

[Andreas K. Hüttel]

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

I think you should take a vacation for a while... Preferably somewhere 
tropical, with no internet access and lots of beach... 

-- 
Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/

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

[Dirkjan Ochtman]

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 commit" tend to
> harm this, and I think that's the essential irritation.

This makes sense to me.

Personally, I think rebases are easy in the vast majority of the cases
(specificially for our gentoo tree, where actual conflicts are often
unlikely). However, for long-running branches (either in time, which I
think doesn't happen that often, or in work), making an explicit merge
could still make sense.

(I guess this is slightly different than somehow limiting the length
of the left-sized twig.)

Cheers,

Dirkjan

Re: [gentoo-dev] On banning merge commits

[Dirkjan Ochtman]

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

Hey Michał,

Patrice is just opening up a discussion on a mailing list. Clearly
there are opposing viewpoints on whether we should use merge commits
and/or how often. Making vague threats without any rationale/reasoning
about why you would dislike any change in this direction is completely
unproductive for the Gentoo community. I would be very interested in
what your proposed way forward is, and why.

Cheers,

Dirkjan

[gentoo-dev] Re: On banning merge commits

[Duncan]

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 main tree, why did we bother switching to git in
>> the first place?  That was available on cvs, or if we wanted more
>> features, subversion, etc.
> 
> I think the annoyance is more having two histories, where on one side,
> you've got the high-traffic gentoo work flow happening, and then  you
> have a merge commit 
> 
> And that merge commit may have only a single commit on it, and its
> parent is god-knows how many days old.
> 
> So the "graph" looks *massive* when it is really only a single commit
> and its merge commit.
> 
> I think the most productive thing here is not to ban "merge commits" as
> such, but ban merge commits where the "merge base" ( that is, the common
> ancestor of the left and right parents of the merge commit ) leaves a
> significant number of commits on the "left" side of the equation. [...]

> "Long histories that go for days only to merge one commit" tend to harm
> this, and I think that's the essential irritation.

OK, that I can agree with. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] On banning merge commits

[Amadeusz Żołnowski]

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

[Daniel Campbell]

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 things harder to bisect?  Harder to determine what came before what?
> Harder to do future development?  Harder because it is unfamiliar
> compared to the cvs workflow?
> 
> Or just "messier" when you look at the graph of the tree?
> 
> What is the _real_ reason that you don't like merges?
> 
> thanks,
> 
> greg k-h
> 

I don't have a strong -- or even clear -- opinion on the matter, but I
could imagine it being a bother to see a bunch of "merge commit" commit
messages in `git log` and not really have much to go on as far as "who
submitted this, who approved it, what does it fix, etc". As far as I
know, there's only the committer information and any GPG-signing that
may have accompanied it, as we do in Gentoo. If I have any details
wrong, please clarify.

I've heard about a way to "redo" history in a git repository as well,
especially before pushing. Could that be a way to mitigate merge
commits, so they are more informative and conform to our commit message
convention?

Sincerely,

a neutral party
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

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

[Kent Fredric]

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 available on cvs, or if we wanted more features,
> subversion, etc.


I think the annoyance is more having two histories, where on one side,
you've got the high-traffic
gentoo work flow happening, and then  you have a merge commit 

And that merge commit may have only a single commit on it, and its
parent is god-knows how many days old.

So the "graph" looks *massive* when it is really only a single commit
and its merge commit.

I think the most productive thing here is not to ban "merge commits"
as such, but ban merge commits where the "merge base" ( that is, the
common ancestor of the left and right parents of the merge commit )
leaves a significant number of commits on the "left" side of the
equation.

Personally, I could live with "0 commits on left", because that would
give a bunching effect.

The "Real History" would still be linear if you followed only the
right parents, but you'd get a simplified view with grouping if you
followed only the left parents.

However, a limit of say, 10 commits on left, I could also live with.

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 commit" tend to
harm this, and I think that's the essential irritation.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] On banning merge commits

[Andrew Savchenko]

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
> log graph after a while and should be banned altogether from reaching the
> central repository.

No, not all of us.
 
> As of now, no policy is in place yet to keep developers from pushing merge
> commits.
> 
> 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.

Sometimes merge commits are desired. But they should be used
wisely. Of course if used randomly and without thought they may
become disaster.

I see nothing wrong if developer makes series of large non-trivial
changes in a separate branch and then merges this branch with
current head after good testing. Another case is when some user
submits a long branch of patches and developer merges it from
external repository (with proper testing of course).

If one have problems reading logs with merge commits, use gitk
or similar tools. I had the same hate relationship towards
non-linear workflow after switching from cvs and svn to git, but
with time comes the understanding that git workflow is the right
way to go, it just takes time to get accustomed to it.

Best regards,
Andrew Savchenko


pgpZgqH1JgnEP.pgp
Description: PGP signature

[gentoo-dev] Re: On banning merge commits

[Duncan]

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 appropriate quote nesting, either. 

>   Original Message
> From: Michał Górny Sent: Sunday, May 8, 2016 13:09 To: Patrice Clement
> Reply To: gentoo-dev@lists.gentoo.org Cc: gentoo-dev@lists.gentoo.org
> Subject: Re: [gentoo-dev] On banning merge commits
> 
> 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 log graph after a while and should be banned altogether from
>> reaching the central repository.
>> 
>> As of now, no policy is in place yet to keep developers from pushing
>> merge commits.
>> 
>> 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 retirement.

Agreed with mgorny here.

In fact, I'd suggest banning *non-*merge push-commits.  It's forcing the 
rebases that is really bad design, removing useful information from the 
log graph, etc.

The reason gentoo's git logs are such a mess now is that they're mostly 
flat.  Initial commits are normally one atomic issue per initial commit, 
good, but then instead of naturally grouping them by subject with a well 
commented merge commit, as is done for example with the mainline kernel 
tree, they're unnaturally forced into a flat list by rebases instead of 
the more natural merges, horribly *bad*!

Of course that loses all the rich information that the merges carry, 
including, when merges are done right, grouping individual atomic commits 
by general task/project, and appropriate merge comments outlining what 
was actually merged.

With the kernel I can git log --graph ORIG_HEAD.. and by default search 
only for merges into the mainline/lefthand master branch.  That gives me 
a very good overview of what subsystems were merged, and for the ones 
that interest me, I can read the merge commit comment and have a good 
idea what was merged from that subsystem.  For the ones that are more 
interesting, I can drill down into the merge and read individual commit 
comments.  If even that isn't enough, I can easily git show  
using the commit ID from the log, and get the full diff.

Try doing that with gentoo.  It doesn't work because everything's flat; 
there's too few merge commits.  For instance, I've no interested in arm, 
and with the kernel git log, I can skip the majority of arm-affecting-
only commits by just skipping the merge commits as soon as I see it's 
from the arm tree, while with the gentoo git log, all those arm 
stabilizations appear as hundreds of individual flat commits on the main 
branch, instead of a small handful of merge-commits, with merge-commit 
comments such as "arm stabilizations for app-foo/bar and deps".

So on gentoo, what I end up doing instead is seeing what packages want to 
update, and only searching the git log for the interesting ones.  Works 
well enough for that, but I've effectively no overview of what's going on 
in general as I do for the kernel tree, as I miss all the interesting 
commits that didn't happen to show up as package update candidates spit 
out by portage, even in areas I'd otherwise track rather heavily, like 
kde, where I track the kde overlay git log, but miss the gentoo repo side 
due to the problems created by lack of appropriate merge commits as 
explained above.


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 available on cvs, or if we wanted more features, 
subversion, etc.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] On banning merge commits

[Greg KH]

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 came before what?
Harder to do future development?  Harder because it is unfamiliar
compared to the cvs workflow?

Or just "messier" when you look at the graph of the tree?

What is the _real_ reason that you don't like merges?

thanks,

greg k-h

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

[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 what is meant here, but
a "slot dependency". These terms are defined in PMS:
https://projects.gentoo.org/pms/6/pms.html#x1-860008.2.6.3

Also I think that the previous wording was more accurate here.
Slot dependencies are not allowed inside .

Ulrich


pgp3PB6JFaNPM.pgp
Description: PGP signature

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

[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 specified
>  formally in https://wiki.gentoo.org/wiki/GLEP:34;>
> -GLEP 34, and the character set must be UTF-8 as specified
> -by https://wiki.gentoo.org/wiki/GLEP:31;>GLEP
> -31. A typical example:
> +GLEP 34. A typical example:

The reference to GLEP 34 should be replaced by GLEP 68 which
supersedes it.

Ulrich


pgpDRr_grtRJr.pgp
Description: PGP signature