Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Rich Freeman]

On Sun, Aug 23, 2015 at 8:01 AM, Andrew Savchenko  wrote:
>
> Any news on when git repo with historical commits will be
> available? Or am I missing something and it is already online?
>

I have no news on anything official but I've posted one at:
https://github.com/gentoo/gentoo-gitmig-20150809-draft

I'm not aware of any issues with it, but let me know if you see any.
With git-replace we can of course fix it as many times as we need to.

-- 
Rich

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Andrew Savchenko]

Hi,

On Thu, 2 Jul 2015 21:39:52 + Robin H. Johnson wrote:
> Hi all,
> 
> The Git migration is moving forward, and I'd like to announce a
> tentative schedule for that end.
> https://wiki.gentoo.org/wiki/Project:Infrastructure/Git_migration#Status
> 
> 2015/08/08 15:00 UTC - Freeze
> 2015/08/08 19:00 UTC - Git commits open for developers
> 2015/08/09 01:00 UTC - Rsync live again (with lagged changelog)
> 2015/08/11   - History repo available to graft
> 2015/08/12   - rsync mirrors carry up-to-date changelogs again

Any news on when git repo with historical commits will be
available? Or am I missing something and it is already online?

Having rsync mirrors with up-to-date ChangeLogs will be great too :)

Best regards,
Andrew Savchenko


pgpb83cXTjfMb.pgp
Description: PGP signature

Re: [gentoo-dev] Git Migration: go-live!

[Andrew Savchenko]

On Sun, 9 Aug 2015 21:04:35 + Robin H. Johnson wrote:
> On Sun, Aug 09, 2015 at 01:16:19PM +0300, Andrew Savchenko wrote:
> > > Out of curiosity, is it impossible to have a read only CVS server with
> > > the state at the time of the freeze?
> > Seconded here. Read-only CVS should not consume much resources, but
> > will facilitate migration.
> Read-only access to gentoo-x86 is restored (and write to the other CVS
> repos).
 
Thanks.

Best regards,
Andrew Savchenko


pgpBLYIMhwIpG.pgp
Description: PGP signature

Re: [gentoo-dev] Git Migration: go-live!

[Robin H. Johnson]

On Sun, Aug 09, 2015 at 01:16:19PM +0300, Andrew Savchenko wrote:
> > Out of curiosity, is it impossible to have a read only CVS server with
> > the state at the time of the freeze?
> Seconded here. Read-only CVS should not consume much resources, but
> will facilitate migration.
Read-only access to gentoo-x86 is restored (and write to the other CVS
repos).

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

Re: [gentoo-dev] Git Migration: go-live!

[Daniel Campbell (zlg)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/08/2015 10:36 PM, Robin H. Johnson wrote:
> On Sat, Aug 08, 2015 at 05:47:14PM +, Robin H. Johnson wrote:
>> On Thu, Jul 02, 2015 at 09:39:52PM +, Robin H. Johnson
>> wrote:
>>> 2015/08/08 15:00 UTC - Freeze 2015/08/08 19:00 UTC - Git
>>> commits open for developers
> This is going live in a few minutes. There was a lot of delays and
> snags that were hit. QA has a lot of reviewing to do of in-tree
> patches with long-standing CVS keyword damage. gkeys is also not
> sufficiently baked, so we're using some scripting for now instead
> [1].
> 
> The new setup DOES enforce that commits AND pushes are signed.
> 
> I'm only 90% sure that everything works, but I've spent almost the 
> entire day on it, and there's more to go tomorrow.
> 
> Other old CVS repos are still closed for the moment, they will
> re-open tomorrow.
> 
>>> 2015/08/09 01:00 UTC - Rsync live again (with lagged
>>> changelog) 2015/08/11   - History repo available to
>>> graft 2015/08/12   - rsync mirrors carry up-to-date
>>> changelogs again
> These parts are still pending.
> 
> Quick instructions: Set PORTAGE_GPG_KEY="0xLONG-GPG-KEY" in your
> make.conf $ git config user.signingkey 0xLONG-GPG-KEY $ git clone
> git+ssh://g...@git.gentoo.org/repo/gentoo.git $ vim ... $ repoman
> commit -m '...' [2] $ git push --signed
> 
> (some time later, when you have local unpushed commits you want to 
> rebase instead of merging) $ git pull --rebase -S $ vim ... $
> repoman commit -m '...' $ git push --signed
> 
> (some time later, when you have a local branch you want to merge) $
> git merge -S some-branch $ git push --signed
> 
> [1] The keys as they are in LDAP right now have been used. If you
> need to change your key, please ping infra as well, so I can update
> the temporary setup. $ ldapsearch 'gentooStatus=active'
> gpgfingerprint -Z -LLL \ |grep gpgfingerprint |cut -d: -f2- |tr -d
> ' '  \ |grep -v 'undefined'  | xargs gpg --recv
> 
> [2] If you commit directly with "git commit" you MUST pass -S (and
> ideally -s).
> 

I'd like to thank you and anyone else who's worked on the Git
migration. It's not a trivial undertaking and I look forward to
working on ebuilds with Git! The workflow wiki page is very helpful;
I've added it to my Watchlist so I can stay up to date on changes.

Thanks again for your efforts! If you'd like any assistance in setting
up hooks, I'd be glad to help.

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

iQIcBAEBCAAGBQJVx7H1AAoJEAEkDpRQOeFwYloQAIPXgVMhCvT6xLxPd6OVtOtU
pDHuRUS3aGXWowGnf4BFTvV3ILpca/qm/ExVe+As1B7atCkP3XeRYP4y0TB31Ol1
QQMNvIZ8XkItjbQg8QTg0EMqA45IKMV//4ZwVdsAjPq3686nLOtfjAREB6SwO3nS
5huXcJ2+D1wxKAAAORGwkNYIjKzwGd/BnbDWTyNR/pUekrd6nBo/du5v7vo5j00S
ORsc4JXjhoQ56KCvNDz4kkzcCiPE0equto7b/7ZL7Cb7hkV6d8u5YmwzQPGwzk4I
OztEF88xpOvDHsgVuV1UStOLX3trVmkUZElwIektw7+ZOZZ7IwLzPRGHUDronSR/
mO6gdxaPqUCfjMNsg7n54dJVUNhkPjCu/8IispfnfmFJ/xGdnznAizkW25zJH5Vx
+DVC8wac46/74SBmJlipRuMiMKAQu5kZP4szGFd/n4bYyQplnQ/7u+aX/IbMQoY+
JWWNHRZfjHYKjJcWA+sxYuWQp5RwcL//o07BR3zjjv7LOTEVwtnOApppV+E9bOyF
2OgTDPOhLao+D5Gm0b7T7nMT34DAw9Io2D7Nbo29YQFuXim6/6jPB9uJeSswan5J
uUUJQnJOElSiM85EUJm4ZjKXS0zHjNMoiyFTWi7C8eUu1eeJgCsTNqFb0/3vDOct
9OfweV2Hm2CY/G6Vwk00
=2eg6
-END PGP SIGNATURE-

Re: [gentoo-dev] Git Migration: go-live!

[Mike Gilbert]

On Sun, Aug 9, 2015 at 5:00 AM, Michael Weber  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 08/09/2015 07:36 AM, Robin H. Johnson wrote:
>> I'm only 90% sure that everything works, but I've spent almost the
>> entire day on it, and there's more to go tomorrow.
> Thanks a lot!
>
> use case: my cvs tree had uncommitted ebuild work (yes, you caught me
> actually doing something).
> now `cvs diff` no longer works, how can i track down my local changes?
> besides diffing against git tree, brain memory aka shell history and
> find -newer?

It seems you have one final use for my "cvs-status" script. That will
do an offline status check by comparing timestamps.

http://floppym.blogspot.com/2012/02/cvs-status-display-cvs-checkout-in-svn.html

Re: [gentoo-scm] Re: [gentoo-dev] Git Migration: go-live!

[Robin H. Johnson]

On Sun, Aug 09, 2015 at 09:10:30AM -0400, Rich Freeman wrote:
> We shouldn't do anything (besides adapting repoman to the $Id$ format)
> without some discussion first.  However...
> 
> Do we really need to have ANY keywords in our files?  Keyword
> expansion was just a PITA all-around with cvs.  Do we really need to
> embed them in our git files?
> 
> At least git doesn't expand them in the actual repository.
> 
> I'm not really a big fan of any kind of in-band signaling.  I guess
> the one advantage of this is that if you find a file OUTSIDE of a
> repository you know where it came from, but how important is that?
The expansion is ONLY for the rsync export, so that we can identify the
version of the file on a user's system.

When previously discussed, that was a strongly requested item, as
developers DO sometimes ask users to please test rev 1.xyz of an ebuild.

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

Re: [gentoo-core] [gentoo-dev] Git Migration: go-live!

[Andrew Savchenko]

On Sun, 9 Aug 2015 12:04:43 +0200 Francisco Blas Izquierdo Riera
(klondike) wrote:
> El 09/08/15 a las 12:02, Mike Frysinger escribió:
> > On 09 Aug 2015 11:31, Marc Schiffbauer wrote:
> >> * Michael Weber schrieb am 09.08.15 um 11:00 Uhr:
> >>> On 08/09/2015 07:36 AM, Robin H. Johnson wrote:
>  I'm only 90% sure that everything works, but I've spent almost the 
>  entire day on it, and there's more to go tomorrow.
> >>> Thanks a lot!
> >>>
> >>> use case: my cvs tree had uncommitted ebuild work (yes, you caught me
> >>> actually doing something).
> >>> now `cvs diff` no longer works, how can i track down my local changes?
> >>> besides diffing against git tree, brain memory aka shell history and
> >>> find -newer?
> >> I'd say: 
> >>
> >> - tar your *.ebuild and files/* stuff away
> >> - then "git clone" the new git repo.
> >> - untar your files in the new git repo
> >> - use "git diff"
> > there will be a ton of cvs keyword noise in there though.  need to run
> > a sed on the files to clear it out.
> >
> > it also will include noise where your local checkout was behind the latest
> > tree, so it'll only really work if you ran `cvs up` in the whole tree just
> > before it was shutdown.
> > -mike
> Out of curiosity, is it impossible to have a read only CVS server with
> the state at the time of the freeze?
 
Seconded here. Read-only CVS should not consume much resources, but
will facilitate migration.

Best regards,
Andrew Savchenko


pgpbFzgWffu5i.pgp
Description: PGP signature

Re: [gentoo-core] [gentoo-dev] Git Migration: go-live!

[Francisco Blas Izquierdo Riera (klondike)]

El 09/08/15 a las 12:02, Mike Frysinger escribió:
> On 09 Aug 2015 11:31, Marc Schiffbauer wrote:
>> * Michael Weber schrieb am 09.08.15 um 11:00 Uhr:
>>> On 08/09/2015 07:36 AM, Robin H. Johnson wrote:
 I'm only 90% sure that everything works, but I've spent almost the 
 entire day on it, and there's more to go tomorrow.
>>> Thanks a lot!
>>>
>>> use case: my cvs tree had uncommitted ebuild work (yes, you caught me
>>> actually doing something).
>>> now `cvs diff` no longer works, how can i track down my local changes?
>>> besides diffing against git tree, brain memory aka shell history and
>>> find -newer?
>> I'd say: 
>>
>> - tar your *.ebuild and files/* stuff away
>> - then "git clone" the new git repo.
>> - untar your files in the new git repo
>> - use "git diff"
> there will be a ton of cvs keyword noise in there though.  need to run
> a sed on the files to clear it out.
>
> it also will include noise where your local checkout was behind the latest
> tree, so it'll only really work if you ran `cvs up` in the whole tree just
> before it was shutdown.
> -mike
Out of curiosity, is it impossible to have a read only CVS server with
the state at the time of the freeze?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-core] [gentoo-dev] Git Migration: go-live!

[Mike Frysinger]

On 09 Aug 2015 11:31, Marc Schiffbauer wrote:
> * Michael Weber schrieb am 09.08.15 um 11:00 Uhr:
> > On 08/09/2015 07:36 AM, Robin H. Johnson wrote:
> > > I'm only 90% sure that everything works, but I've spent almost the 
> > > entire day on it, and there's more to go tomorrow.
> > Thanks a lot!
> > 
> > use case: my cvs tree had uncommitted ebuild work (yes, you caught me
> > actually doing something).
> > now `cvs diff` no longer works, how can i track down my local changes?
> > besides diffing against git tree, brain memory aka shell history and
> > find -newer?
> 
> I'd say: 
> 
> - tar your *.ebuild and files/* stuff away
> - then "git clone" the new git repo.
> - untar your files in the new git repo
> - use "git diff"

there will be a ton of cvs keyword noise in there though.  need to run
a sed on the files to clear it out.

it also will include noise where your local checkout was behind the latest
tree, so it'll only really work if you ran `cvs up` in the whole tree just
before it was shutdown.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-core] [gentoo-dev] Git Migration: go-live!

[Marc Schiffbauer]

* Michael Weber schrieb am 09.08.15 um 11:00 Uhr:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 08/09/2015 07:36 AM, Robin H. Johnson wrote:
> > I'm only 90% sure that everything works, but I've spent almost the 
> > entire day on it, and there's more to go tomorrow.
> Thanks a lot!
> 
> use case: my cvs tree had uncommitted ebuild work (yes, you caught me
> actually doing something).
> now `cvs diff` no longer works, how can i track down my local changes?
> besides diffing against git tree, brain memory aka shell history and
> find -newer?

I'd say: 

- tar your *.ebuild and files/* stuff away
- then "git clone" the new git repo.
- untar your files in the new git repo
- use "git diff"


-Marc


-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317
 3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-scm] Re: [gentoo-dev] Git Migration: go-live!

[Rich Freeman]

On Sun, Aug 9, 2015 at 8:43 AM, Mike Frysinger  wrote:
> On 09 Aug 2015 14:54, Alexey Shvetsov wrote:
>> Hi all!
>
> please don't top post
>
>> Current repoman complains about headers in ebuilds
>>
>> >>> Creating Manifest for /home/alexxy/Gentoo/gentoo/sys-cluster/open-mx
>>ebuild.badheader  1
>> sys-cluster/open-mx/open-mx-1.5.4.ebuild: Malformed CVS Header on
>> line: 3
>>
>> So may be its better to drop $Id: $ completely?
>
> it should look like:
> # $Id$
>

We shouldn't do anything (besides adapting repoman to the $Id$ format)
without some discussion first.  However...

Do we really need to have ANY keywords in our files?  Keyword
expansion was just a PITA all-around with cvs.  Do we really need to
embed them in our git files?

At least git doesn't expand them in the actual repository.

I'm not really a big fan of any kind of in-band signaling.  I guess
the one advantage of this is that if you find a file OUTSIDE of a
repository you know where it came from, but how important is that?

-- 
Rich

Re: [gentoo-scm] Re: [gentoo-dev] Git Migration: go-live!

[Alexey Shvetsov]

Mike Frysinger писал 09-08-2015 15:43:

On 09 Aug 2015 14:54, Alexey Shvetsov wrote:

Hi all!


please don't top post


Current repoman complains about headers in ebuilds

>>> Creating Manifest for /home/alexxy/Gentoo/gentoo/sys-cluster/open-mx
   ebuild.badheader  1
sys-cluster/open-mx/open-mx-1.5.4.ebuild: Malformed CVS Header on
line: 3

So may be its better to drop $Id: $ completely?


it should look like:
# $Id$

but even then, yes, we should just trim the line
-mike


Since repoman do comparison with header.txt which contains


alexxy@x240 ~/Gentoo/gentoo $ cat header.txt
# Copyright 1999-2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

So we can change last line to $Id$ or since it dont actualy needed we 
can simply drop it.


--
Best Regards,
Alexey 'Alexxy' Shvetsov
Best Regards,
Alexey 'Alexxy' Shvetsov, PhD
Department of Molecular and Radiation Biophysics
FSBI Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Leningrad region, Gatchina, Russia
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexx...@gmail.com
mailto:ale...@gentoo.org
mailto:ale...@omrb.pnpi.spb.ru

Re: [gentoo-scm] Re: [gentoo-dev] Git Migration: go-live!

[Mike Frysinger]

On 09 Aug 2015 14:54, Alexey Shvetsov wrote:
> Hi all!

please don't top post

> Current repoman complains about headers in ebuilds
> 
> >>> Creating Manifest for /home/alexxy/Gentoo/gentoo/sys-cluster/open-mx
>ebuild.badheader  1
> sys-cluster/open-mx/open-mx-1.5.4.ebuild: Malformed CVS Header on 
> line: 3
> 
> So may be its better to drop $Id: $ completely?

it should look like:
# $Id$

but even then, yes, we should just trim the line
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Git Migration: go-live!

[Alexey Shvetsov]

Hi all!

Current repoman complains about headers in ebuilds


Creating Manifest for /home/alexxy/Gentoo/gentoo/sys-cluster/open-mx

  ebuild.badheader  1
   sys-cluster/open-mx/open-mx-1.5.4.ebuild: Malformed CVS Header on 
line: 3


So may be its better to drop $Id: $ completely?

Robin H. Johnson писал 09-08-2015 08:36:

On Sat, Aug 08, 2015 at 05:47:14PM +, Robin H. Johnson wrote:

On Thu, Jul 02, 2015 at 09:39:52PM +, Robin H. Johnson wrote:
> 2015/08/08 15:00 UTC - Freeze
> 2015/08/08 19:00 UTC - Git commits open for developers
This is going live in a few minutes. There was a lot of delays and 
snags

that were hit. QA has a lot of reviewing to do of in-tree patches with
long-standing CVS keyword damage. gkeys is also not sufficiently baked,
so we're using some scripting for now instead [1].

The new setup DOES enforce that commits AND pushes are signed.

I'm only 90% sure that everything works, but I've spent almost the
entire day on it, and there's more to go tomorrow.

Other old CVS repos are still closed for the moment, they will re-open
tomorrow.


> 2015/08/09 01:00 UTC - Rsync live again (with lagged changelog)
> 2015/08/11   - History repo available to graft
> 2015/08/12   - rsync mirrors carry up-to-date changelogs again

These parts are still pending.

Quick instructions:
Set PORTAGE_GPG_KEY="0xLONG-GPG-KEY" in your make.conf
$ git config user.signingkey 0xLONG-GPG-KEY
$ git clone git+ssh://g...@git.gentoo.org/repo/gentoo.git
$ vim ...
$ repoman commit -m '...' [2]
$ git push --signed

(some time later, when you have local unpushed commits you want to
rebase instead of merging)
$ git pull --rebase -S
$ vim ...
$ repoman commit -m '...'
$ git push --signed

(some time later, when you have a local branch you want to merge)
$ git merge -S some-branch
$ git push --signed

[1]
The keys as they are in LDAP right now have been used. If you need to
change your key, please ping infra as well, so I can update the
temporary setup.
$ ldapsearch 'gentooStatus=active' gpgfingerprint -Z -LLL \
|grep gpgfingerprint |cut -d: -f2- |tr -d ' '  \
|grep -v 'undefined'  | xargs gpg --recv

[2]
If you commit directly with "git commit" you MUST pass -S (and ideally
-s).


--
Best Regards,
Alexey 'Alexxy' Shvetsov
Best Regards,
Alexey 'Alexxy' Shvetsov, PhD
Department of Molecular and Radiation Biophysics
FSBI Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Leningrad region, Gatchina, Russia
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexx...@gmail.com
mailto:ale...@gentoo.org
mailto:ale...@omrb.pnpi.spb.ru

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Mikle Kolyada]

08.08.2015 20:47, Robin H. Johnson пишет:
> On Thu, Jul 02, 2015 at 09:39:52PM +, Robin H. Johnson wrote:
>> 2015/08/08 15:00 UTC - Freeze
>> 2015/08/08 19:00 UTC - Git commits open for developers
>> 2015/08/09 01:00 UTC - Rsync live again (with lagged changelog)
>> 2015/08/11   - History repo available to graft
>> 2015/08/12   - rsync mirrors carry up-to-date changelogs again
>>
>> I've allocated time for an 8 hour freeze, but hope to be completed much
>> sooner than that.
> Starting late due to $reasons, freeze is now at 18:00 UTC (14 minutes
> from now).
>

Where and how should we add new developers these days to grant them
access to the portage tree?

Re: [gentoo-dev] Git Migration: go-live!

[Michael Weber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/09/2015 07:36 AM, Robin H. Johnson wrote:
> I'm only 90% sure that everything works, but I've spent almost the 
> entire day on it, and there's more to go tomorrow.
Thanks a lot!

use case: my cvs tree had uncommitted ebuild work (yes, you caught me
actually doing something).
now `cvs diff` no longer works, how can i track down my local changes?
besides diffing against git tree, brain memory aka shell history and
find -newer?

Michael

- -- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iL4EAREKAGYFAlXHFrxfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldDY3QjA4MzdGODg1NUMxMjIzNUQ0MDgxNzky
N0FERDBDNjJFRUYwOTAACgkQknrdDGLu8JBaSAD+MaDxkEjuQUfgbA4yJtnzFfim
il9V7HWdrouTgQ3Lnh8A/05Ilegavg/+zP9hf5BsMa5+kJVHOuAIFiB16/66AKfC
=njMM
-END PGP SIGNATURE-

Re: [gentoo-dev] Git Migration: go-live!

[Michał Górny]

Hi,

Great work! Semi-related question though...

Dnia 2015-08-09, o godz. 05:36:16
"Robin H. Johnson"  napisał(a):

> On Sat, Aug 08, 2015 at 05:47:14PM +, Robin H. Johnson wrote:
> [...]
> Quick instructions:
> Set PORTAGE_GPG_KEY="0xLONG-GPG-KEY" in your make.conf
> $ git config user.signingkey 0xLONG-GPG-KEY
> $ git clone git+ssh://g...@git.gentoo.org/repo/gentoo.git

I see you've finally decided on the 'repo/' prefix. Should I create
new dev, user and project overlays in 'repo/' namespace as well now?

-- 
Best regards,
Michał Górny



pgpTOIM_3joIM.pgp
Description: OpenPGP digital signature

[gentoo-dev] Git Migration: go-live!

[Robin H. Johnson]

On Sat, Aug 08, 2015 at 05:47:14PM +, Robin H. Johnson wrote:
> On Thu, Jul 02, 2015 at 09:39:52PM +, Robin H. Johnson wrote:
> > 2015/08/08 15:00 UTC - Freeze
> > 2015/08/08 19:00 UTC - Git commits open for developers
This is going live in a few minutes. There was a lot of delays and snags
that were hit. QA has a lot of reviewing to do of in-tree patches with
long-standing CVS keyword damage. gkeys is also not sufficiently baked,
so we're using some scripting for now instead [1].

The new setup DOES enforce that commits AND pushes are signed.

I'm only 90% sure that everything works, but I've spent almost the
entire day on it, and there's more to go tomorrow.

Other old CVS repos are still closed for the moment, they will re-open
tomorrow.

> > 2015/08/09 01:00 UTC - Rsync live again (with lagged changelog)
> > 2015/08/11   - History repo available to graft
> > 2015/08/12   - rsync mirrors carry up-to-date changelogs again
These parts are still pending.

Quick instructions:
Set PORTAGE_GPG_KEY="0xLONG-GPG-KEY" in your make.conf
$ git config user.signingkey 0xLONG-GPG-KEY
$ git clone git+ssh://g...@git.gentoo.org/repo/gentoo.git
$ vim ...
$ repoman commit -m '...' [2] 
$ git push --signed

(some time later, when you have local unpushed commits you want to
rebase instead of merging)
$ git pull --rebase -S
$ vim ...
$ repoman commit -m '...'
$ git push --signed

(some time later, when you have a local branch you want to merge)
$ git merge -S some-branch
$ git push --signed

[1]
The keys as they are in LDAP right now have been used. If you need to
change your key, please ping infra as well, so I can update the
temporary setup.
$ ldapsearch 'gentooStatus=active' gpgfingerprint -Z -LLL \
|grep gpgfingerprint |cut -d: -f2- |tr -d ' '  \
|grep -v 'undefined'  | xargs gpg --recv 

[2]
If you commit directly with "git commit" you MUST pass -S (and ideally
-s).

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

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Robin H. Johnson]

On Thu, Jul 02, 2015 at 09:39:52PM +, Robin H. Johnson wrote:
> 2015/08/08 15:00 UTC - Freeze
> 2015/08/08 19:00 UTC - Git commits open for developers
> 2015/08/09 01:00 UTC - Rsync live again (with lagged changelog)
> 2015/08/11   - History repo available to graft
> 2015/08/12   - rsync mirrors carry up-to-date changelogs again
> 
> I've allocated time for an 8 hour freeze, but hope to be completed much
> sooner than that.
Starting late due to $reasons, freeze is now at 18:00 UTC (14 minutes
from now).

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

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Tobias Klausmann]

Hi! 

On Thu, 09 Jul 2015, Rich Freeman wrote:
> On Thu, Jul 9, 2015 at 10:51 AM, Tobias Klausmann  wrote:
> > What I meant is when I get a stabilization bug for
> > cat-egory/foo-1.2.3 which depends on >=other-cat/bar-1.0.5. The
> > latter is amd64 but not alpha or ~alpha. And it, in turn, has yet
> > more deps in the same vein. Now I have several options:
> 
> If bar-1.0.5 isn't alpha or ~alpha, then foo-1.2.3 shouldn't be ~alpha
> either, and repoman should complain about this for any non-dev/exp
> arches.

What can I say? Apparently some devs file stabilization bugs
without checking these things. I run repoman full before
committing anything, so that's where the buck stops.

> If it isn't ~alpha to begin with, then it shouldn't be going
> stable on alpha.

Ack. Hence my mention of "keyword and soak."

I am confident that nobody here would argue that "casual
stabilization bugs" are okay and the arch teams should just suck
it up. But unfortunately, it still happens.

Regards,
Tobias

-- 
Sent from aboard the Culture ship
GCU (River Class) Displacement Activity

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Rich Freeman]

On Thu, Jul 9, 2015 at 2:56 PM, hasufell  wrote:
>
> I'm not sure if you followed my argumentation. I basically said that it
> is unrealistic to enforce a review-only workflow and that it should/can
> start within gentoo-internal projects. You are just repeating what I
> already said.
>
> My point was that I am not mixing up different issues as Andrew claimed,
> because a review workflow can be seen in a different context.
> And then, the repeated argument of "not enough manpower for review
> workflow" doesn't make a lot of sense. The problem is the mindest/culture.
>

To an extent I agree with you.  However, a workflow that works great
for a tight-knit group of 6 devs working on one set of packages that
were designed by upstream to work together might not work as well for
a set of 50 devs working on 300 packages that are completely
independent.  We should start with small teams, but I think it remains
to be seen if it ever grows to encompass most of the tree.

That said, it might grow to cover the core system components and that
might be good enough for most purposes.  Users might not notice if one
of the 15 reversi implementations in the tree breaks, but would prefer
that gcc, glibc, and qt be of a higher quality.

-- 
Rich

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[hasufell]

On 07/09/2015 01:47 PM, Rich Freeman wrote:
> On Thu, Jul 9, 2015 at 5:31 AM, hasufell  wrote:
>>
>> The quality problem is that we have too many developers. If you make
>> community contributions easier, sane and more reliable (due to code
>> review) then you solve several problems at once, because you need _less_
>> developers. Are you aware that we could potentially "pull" in hundreds
>> of contributors who chose to work on their personal overlay instead of
>> the gentoo tree? Are you aware that there are a lot of those people?
> 
> Yes and no.
> 
> I'll agree that with a review workflow we might only need one reviewer
> for every 10 contributors, or something like that.  If we have 100
> active devs today, in theory we could instead turn 20 of them into
> reviewers, and now we can support 2000 contributors.
> 
> There are some big assumptions with this kind of argument, though:
> 1.  We might find that we don't even have 20 devs interested in doing
> a substantial amount of review.
> 2.  The main repository is very diverse.  If 50% of our packages have
> only one person interested in maintaining them, then they get dropped
> since reviewers will ignore their contributions.  Or, they'll just
> rubber-stamp them which is adding valueless work.
> 
> So, a review system could make manpower either more of an issue or
> less of one.  I suspect that trying to force it would basically end up
> putting the entire distro on hold until most of the current devs quit,
> and a new crop signs up who is interested in using the new workflow,
> and then they're starting with zero experience.
> 
> I think a review model is best implemented by individual project
> teams.  They could use it to track changes in an overlay or branch in
> the main tree, and then move those into the main tree using whatever
> quality system seems best.  The team can figure out what is working
> best for it, and if over time a large number of devs feel that it is a
> good way to work we could then talk about doing it with the main tree.
> I still suspect we'll end up having problems with the 70% of packages
> that don't fall into a project though.
> 

I'm not sure if you followed my argumentation. I basically said that it
is unrealistic to enforce a review-only workflow and that it should/can
start within gentoo-internal projects. You are just repeating what I
already said.

My point was that I am not mixing up different issues as Andrew claimed,
because a review workflow can be seen in a different context.
And then, the repeated argument of "not enough manpower for review
workflow" doesn't make a lot of sense. The problem is the mindest/culture.

However, it makes sense to provide review workflow tools. And they have
been demanded quite a few times now I think, even from vapier afair.

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Ciaran McCreesh]

On Thu, 09 Jul 2015 00:11:34 -0500
Steev Klimaszewski  wrote:
> The only fear I have about CI, is that we turn into every other distro
> out there where "it builds, ship it!"

This would be an improvement over the current situation.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Rich Freeman]

On Thu, Jul 9, 2015 at 11:45 AM, Alec Warner  wrote:
>
> On Thu, Jul 9, 2015 at 4:47 AM, Rich Freeman  wrote:
>>
>> 
>
> So basically Gentoo Sunrise? :)
>
>> In any case, to some extent the review workflow already exists on the
>> proxy maintainer project.  There is no limit to the number of packages
>> they can maintain, or the number of reviewers they can have.

Answered and asked.  :)

-- 
Rich

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[wireless]

On 07/09/2015 10:45 AM, Alec Warner wrote:



On Thu, Jul 9, 2015 at 4:47 AM, Rich Freeman mailto:ri...@gentoo.org>> wrote:

On Thu, Jul 9, 2015 at 5:31 AM, hasufell mailto:hasuf...@gentoo.org>> wrote:
>
> The quality problem is that we have too many developers. If you make
> community contributions easier, sane and more reliable (due to code
> review) then you solve several problems at once, because you need _less_
> developers. Are you aware that we could potentially "pull" in hundreds
> of contributors who chose to work on their personal overlay instead of
> the gentoo tree? Are you aware that there are a lot of those people?

Yes and no.

I'll agree that with a review workflow we might only need one reviewer
for every 10 contributors, or something like that.  If we have 100
active devs today, in theory we could instead turn 20 of them into
reviewers, and now we can support 2000 contributors.

There are some big assumptions with this kind of argument, though:
1.  We might find that we don't even have 20 devs interested in doing
a substantial amount of review.
2.  The main repository is very diverse.  If 50% of our packages have
only one person interested in maintaining them, then they get dropped
since reviewers will ignore their contributions.  Or, they'll just
rubber-stamp them which is adding valueless work.

So, a review system could make manpower either more of an issue or
less of one.  I suspect that trying to force it would basically end up
putting the entire distro on hold until most of the current devs quit,
and a new crop signs up who is interested in using the new workflow,
and then they're starting with zero experience.

I think a review model is best implemented by individual project
teams.  They could use it to track changes in an overlay or branch in
the main tree, and then move those into the main tree using whatever
quality system seems best.  The team can figure out what is working
best for it, and if over time a large number of devs feel that it is a
good way to work we could then talk about doing it with the main tree.
I still suspect we'll end up having problems with the 70% of packages
that don't fall into a project though.


I think everybody is getting a bit heated over CI/Quality/automation, 
when clearly there is no good reason to get so heated. Let me explain. 
YES industry, commercial, research, FOSS and everybody is moving to some 
sort of paradigm where as much automation of code examination is 
streamline. Surely these efforts are a work in progress and as such will 
evolved over time. It does not mean the existing, wonderfully manual 
processes are being replaced, it just means that the simple, routine, 
(scriptable if you like) filters are automated. In fact those manual 
processes still need to occur, because the next generation of coders 
have to learn how things work in order to extent the paradigm.



Resources. Surely the major arches are at an advantage. But the current 
cluster offerings are soon going to render very powerful processing so 
even gargantuan, single threaded codes can be automated for CI, quality, 
security etc etc. Both a cross-compile and native compile strategy needs 
to experimented with. Those smaller arches will follow the bigger 
arches; so in that we should just let x86 and other such arches blaze 
the path for gentoo (in a non binding manner) while the various other 
arches (with more humble resources) figure out how to build clusters on 
these other arches. Lots of folks are clustering smalller arches to get 
big tasks back into the realm of viability.



The big benefit for those other (more constrained arches) is that folks 
that build embedded products on those arches will be very, very 
interested in work on how to build a cluster, specific to those (sub) 
arches for CI/quality/security. In fact mesos-distcc does not limit the 
various arch types. So I would think all arches would get on-board and 
just follow this paradigm in an easy, non-stressful manner. But the 
Gentoo leadership does have a responsibility to include those other 
arches in just how this occurs, during some extended transition period, 
so that these other arch's still fell like they are part of this 
extended gentoo family. Loosing those arches would be a horrible damage 
to gentoo's reputation, imho. That is our diversity in arches is 
something gentoo is widely know for and sets us apart, imho.




hth,
James

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Alec Warner]

On Thu, Jul 9, 2015 at 4:47 AM, Rich Freeman  wrote:

> On Thu, Jul 9, 2015 at 5:31 AM, hasufell  wrote:
> >
> > The quality problem is that we have too many developers. If you make
> > community contributions easier, sane and more reliable (due to code
> > review) then you solve several problems at once, because you need _less_
> > developers. Are you aware that we could potentially "pull" in hundreds
> > of contributors who chose to work on their personal overlay instead of
> > the gentoo tree? Are you aware that there are a lot of those people?
>
> Yes and no.
>
> I'll agree that with a review workflow we might only need one reviewer
> for every 10 contributors, or something like that.  If we have 100
> active devs today, in theory we could instead turn 20 of them into
> reviewers, and now we can support 2000 contributors.
>
> There are some big assumptions with this kind of argument, though:
> 1.  We might find that we don't even have 20 devs interested in doing
> a substantial amount of review.
> 2.  The main repository is very diverse.  If 50% of our packages have
> only one person interested in maintaining them, then they get dropped
> since reviewers will ignore their contributions.  Or, they'll just
> rubber-stamp them which is adding valueless work.
>
> So, a review system could make manpower either more of an issue or
> less of one.  I suspect that trying to force it would basically end up
> putting the entire distro on hold until most of the current devs quit,
> and a new crop signs up who is interested in using the new workflow,
> and then they're starting with zero experience.
>
> I think a review model is best implemented by individual project
> teams.  They could use it to track changes in an overlay or branch in
> the main tree, and then move those into the main tree using whatever
> quality system seems best.  The team can figure out what is working
> best for it, and if over time a large number of devs feel that it is a
> good way to work we could then talk about doing it with the main tree.
> I still suspect we'll end up having problems with the 70% of packages
> that don't fall into a project though.
>

So basically Gentoo Sunrise? :)

-A


>
> --
> Rich
>
>

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Rich Freeman]

On Thu, Jul 9, 2015 at 10:51 AM, Tobias Klausmann  wrote:
>
> What I meant is when I get a stabilization bug for
> cat-egory/foo-1.2.3 which depends on >=other-cat/bar-1.0.5. The
> latter is amd64 but not alpha or ~alpha. And it, in turn, has yet
> more deps in the same vein. Now I have several options:

If bar-1.0.5 isn't alpha or ~alpha, then foo-1.2.3 shouldn't be ~alpha
either, and repoman should complain about this for any non-dev/exp
arches.

If it isn't ~alpha to begin with, then it shouldn't be going stable on alpha.

I do agree that at the first bump that triggers the need to drop alpha
keywords (testing or stable) there should be a keyword request
submitted to the alpha team to get that sorted out.  They could choose
at that time to do the testing/keywording/etc to get foo-1.2.3 back
onto ~alpha so that it is ready to be stabilized at the right time (or
at least with less delay), or they could choose at that time to just
leave the keywords off in which case they aren't pestered about
stabilization.

-- 
Rich

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Tobias Klausmann]

Hi! 

On Thu, 09 Jul 2015, Steev Klimaszewski wrote:
> On Wed, 2015-07-08 at 21:11 +0200, Tobias Klausmann wrote:
> > The truly arch-dependent bugs are what wastes my time:
> > 
> > For example:
> > 
> > - dependencies not being keyworded for arch or ~arch but only
> >   amd64/~amd64
> > - dependencies not even building on ~arch, but on ~amd64
> > - package assuming availability of gcc/ghc/Python-X.Y when
> >   arch/~arch only has something for  > - my favourite: assuming udev is at version X for arch/~arch when
> >   it has been broken there for roughly twelve kernel versions due
> >   to udev/systemd upstream not caring. The information is one
> >   equery-y command line away, but no, let's file that bug.
> 
> That's a failing of the arch team or the committer then - or whomever
> keyworded the package without testing the dependencies.  That's why the
> keywording bugs happen when dependencies change - and yes, occasionally
> a dependency loses it's keywords and that may be where the issue comes
> from, I'm not sure.  This used to be watched very closely, but I believe
> the tool being used broke at some point.
> 
> What exactly do you mean, it's just one command line away but let's file
> the bug - yes a bug SHOULD be filed, so that the people know of the
> issue so it doesn't get repeated, over and over.  

What I meant is when I get a stabilization bug for
cat-egory/foo-1.2.3 which depends on >=other-cat/bar-1.0.5. The
latter is amd64 but not alpha or ~alpha. And it, in turn, has yet
more deps in the same vein. Now I have several options:

1/ Pull in all dependencies and test them. This may mean I have
   to let the deps soak in ~alpha for 30 days, leading the
   original dev to complain that the arches are slow.
2/ Try and figure out if I can mask a USE flag on foo-1.2.3 that
   avoids the dependency. If there isn't I can try and make one,
   which leads into another hell of dep chasing for revdeps of
   foo-1.2.3.
3/ Complain on the bug that the maintainer of foo-1.2.3 should
   figure out the deptrees before CCing arches.
4/ Opt out of stabilization for foo-1.2.3

If it turns out that bar-1.0.5 or one of its deps breaks a
completely unrelated package, I get to revert all of this until a
fix is found. And then do it all over again.

What instead should happen:

The maintainer of cat-egory/foo sees that 1.2.3 has a new dep,
which is >=other-cat/bar-1.0.5. A quick check with equery* shows
that it isn't stable/keyworded for alpha and hppa.

Thus, the maintainer files a bug for bar-1.0.5 to be stable on
alpha and hppa, possibly/ideally checking with bar's maintainer.
The stabilization for foo-1.2.3 on amd64 can continue, just don't
CC alpha and hppa yet.

Once bar-1.0.5 is stable (or alpha/hppa have opted out), CC them
on the foo-1.2.3 bug.

*(An alternative is to add all the keywords you want and run
  repoman full. Just don't accidentally commit that edit.)

The bad case (ignoring the non-amd64 deptree) is not the
majority, but it's a very frustrating and time consuming
experience for archtesters. Often, the deptrees for the minor
archs are broken in subtly different ways, resulting in the time
wasting to be multiplied.

Option #3 above I have shied away from, since it would feel sort
of aggressive, pedantic and picky when that is not really in my
nature. If everyone is okay(ish) with it, I'll start doing it.

> > Having every arch team chase the deps for every package is very,
> > very frustrating, since it is so trivial a problem. We need a
> > tool that answers the question: "I want to mov cat/pkg-1.2.3 to
> > stable for arches a, b and c, what do I need?" for _every
> > package_. Some groups seem to have tooling for this, but it is
> > far from easily (obviously?) available, so every team gets to
> > re-discover dependency hell. Ruby is especially bad since
> > FEATURES=test make the depgraph explode (and sometimes circular).
> 
> The only fear I have about CI, is that we turn into every other distro
> out there where "it builds, ship it!" - I know I prefer to have our arm
> team actually test the packages more than just doing FEATURES=test
> (assuming the tests aren't broken on arm) emerge, although I know there
> are some people on the team who feel that it's too much to actually test
> all of the arm boards. For a long time, certain binary distros were
> compiling anything and everything, and if it built for other arches it
> was available.  Even if there was no way it would possibly work on that
> arch.  

We're already partway down that road of IC,SI. For Alpha, it's
not because we don't want to, but rather because we know that if
we do it 100% properly, we will quickly fall even further behind.
I guess we do speculative testing: If it compiles+tests, great.
If the package actually breaks, a user will surely tell us.


Yes, CI is nice to have if you have the hardware to do it. But if
parts of our workflow start depending on it, we will quickly lose
the minor archs.

Regards,
Tobias

-- 
prom_

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Rich Freeman]

On Thu, Jul 9, 2015 at 8:25 AM, Peter Stuge  wrote:
> Rich Freeman wrote:
>> I suspect that trying to force it would basically end up putting
>> the entire distro on hold until most of the current devs quit,
>
> I think you're right. I also think those developers should quit right
> here and now. I don't think they will.
>

The thing is that if a bunch of devs want to create a review-only
Gentoo fork they can just do it.  The result would be about the same.
Trying to force it on Gentoo would just result in most of the Gentoo
devs changing the name and proceeding basically as it is, and Gentoo
would just become another XFree86.

The way you change an FOSS project is to influence the current
contributions, or to make contributions of your own.  Trying to order
people around doesn't really change anything in the end.

Hence my suggestion to try something like this out in a project where
there is interest.  Build from success, and win people over.  In the
end the "hard" power of a body like the Council is just the power to
halt progress, not create it.  That power should be focused on
situations where the "progress" is self-destructive.  Obviously a body
like the Council also has "soft" powers like leadership/etc, but that
really isn't enough to just order change by fiat.  Plus, we're all
elected for our ability to generally represent the will of the
developer community, so you shouldn't be too surprised when we don't
try to push policies that most devs disagree with.

In any case, to some extent the review workflow already exists on the
proxy maintainer project.  There is no limit to the number of packages
they can maintain, or the number of reviewers they can have.

-- 
Rich

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Peter Stuge]

Rich Freeman wrote:
> I suspect that trying to force it would basically end up putting
> the entire distro on hold until most of the current devs quit,

I think you're right. I also think those developers should quit right
here and now. I don't think they will.


//Peter

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Rich Freeman]

On Thu, Jul 9, 2015 at 5:31 AM, hasufell  wrote:
>
> The quality problem is that we have too many developers. If you make
> community contributions easier, sane and more reliable (due to code
> review) then you solve several problems at once, because you need _less_
> developers. Are you aware that we could potentially "pull" in hundreds
> of contributors who chose to work on their personal overlay instead of
> the gentoo tree? Are you aware that there are a lot of those people?

Yes and no.

I'll agree that with a review workflow we might only need one reviewer
for every 10 contributors, or something like that.  If we have 100
active devs today, in theory we could instead turn 20 of them into
reviewers, and now we can support 2000 contributors.

There are some big assumptions with this kind of argument, though:
1.  We might find that we don't even have 20 devs interested in doing
a substantial amount of review.
2.  The main repository is very diverse.  If 50% of our packages have
only one person interested in maintaining them, then they get dropped
since reviewers will ignore their contributions.  Or, they'll just
rubber-stamp them which is adding valueless work.

So, a review system could make manpower either more of an issue or
less of one.  I suspect that trying to force it would basically end up
putting the entire distro on hold until most of the current devs quit,
and a new crop signs up who is interested in using the new workflow,
and then they're starting with zero experience.

I think a review model is best implemented by individual project
teams.  They could use it to track changes in an overlay or branch in
the main tree, and then move those into the main tree using whatever
quality system seems best.  The team can figure out what is working
best for it, and if over time a large number of devs feel that it is a
good way to work we could then talk about doing it with the main tree.
I still suspect we'll end up having problems with the 70% of packages
that don't fall into a project though.

-- 
Rich

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[hasufell]

On 07/09/2015 09:19 AM, Andrew Savchenko wrote:
> On Mon, 06 Jul 2015 19:20:14 +0200 hasufell wrote:
>> On 07/05/2015 08:05 AM, Andrew Savchenko wrote:
>>> On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote:
 It's important that the review flow is well-understood and efficient.
>>>
>>> This is impossible in our case due to the lack of manpower.
>>> We already have a lot of bugs, patches, stabilization requests
>>> hanging over there for months and even years. Stabilization request
>>> will require at least two developers to participate in each commit.
>>> This will double manpower required at least. Such approach can kill
>>> the whole project.
>>>
>>
>> People misinterpret "manpower". If we successfully switch to a
>> code-review approach, then we will need _less_ manpower in the sense of
>> actual gentoo developers.
> 
> You're mixing different issues here. Code review process for
> contributors (outside of development team) will indeed save time
> and manpower. But code review for each developer commit will kill
> time and effort undoubtedly, while net quality will have little to
> negligible improvement.
> 

No, I am not mixing issues here.

The quality problem is that we have too many developers. If you make
community contributions easier, sane and more reliable (due to code
review) then you solve several problems at once, because you need _less_
developers. Are you aware that we could potentially "pull" in hundreds
of contributors who chose to work on their personal overlay instead of
the gentoo tree? Are you aware that there are a lot of those people?

Yes, it will slow down random commits. And sometimes that is what you
need to keep good quality up.

But as I said, this is currently not realistic, but not because it
cannot be done. It can. And there are lots of projects that do. And I
don't mean small projects.

Most of the confusion comes from the fact that some gentoo devs have
been doing this broken workflow for so long that they can barely imagine
a workflow that is not broken. The other problems comes from the fact
that a huge potential contributor base has withdrawn from contributing
to the tree and now sticks to overlays. Those are our main problems, not
tools.

And because of that, a workflow transition will have to be executed
step-wise.

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Andrew Savchenko]

On Mon, 06 Jul 2015 19:20:14 +0200 hasufell wrote:
> On 07/05/2015 08:05 AM, Andrew Savchenko wrote:
> > On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote:
> >> It's important that the review flow is well-understood and efficient.
> > 
> > This is impossible in our case due to the lack of manpower.
> > We already have a lot of bugs, patches, stabilization requests
> > hanging over there for months and even years. Stabilization request
> > will require at least two developers to participate in each commit.
> > This will double manpower required at least. Such approach can kill
> > the whole project.
> > 
> 
> People misinterpret "manpower". If we successfully switch to a
> code-review approach, then we will need _less_ manpower in the sense of
> actual gentoo developers.

You're mixing different issues here. Code review process for
contributors (outside of development team) will indeed save time
and manpower. But code review for each developer commit will kill
time and effort undoubtedly, while net quality will have little to
negligible improvement.

Best regards,
Andrew Savchenko


pgp40PFnATWYC.pgp
Description: PGP signature

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Alec Warner]

On Wed, Jul 8, 2015 at 10:11 PM, Steev Klimaszewski 
wrote:

> On Wed, 2015-07-08 at 21:11 +0200, Tobias Klausmann wrote:
> > Hi!
> >
> > On Wed, 08 Jul 2015, Ciaran McCreesh wrote:
> > > On Wed, 8 Jul 2015 20:07:34 +0200
> > > Tobias Klausmann  wrote:
> > > > In essence, assuming we can "just scale" to make CI work is
> > > > ignoring the matter of the slower archs. And I suspect the "it
> > > > works on amd64, fuck everyone else" is not something we want to
> > > > pick as a motto.
> > >
> > > "It works on amd64 on a clean build system" is a heck of a lot better
> > > than "it may or may not work on one developer's heavily modified
> > > box"... The point of testing is not to catch all problems. It's just
> > > there to catch some simple screwups, cheaply.
> >
> > Agreed. Still, in my experience, problems that are not seen on
> > amd64 are the vast majority of timesinks. Usually, by the time
> > non-amd64 shows up on a non-security bug, the Basic Bullshit™ has
> > been sorted. And even if it isn't: Arches are usually quick to
> > point it out and the rest of arches move on to the next bug. The
> > truly arch-dependent bugs are what wastes my time:
> >
> > For example:
> >
> > - dependencies not being keyworded for arch or ~arch but only
> >   amd64/~amd64
> > - dependencies not even building on ~arch, but on ~amd64
> > - package assuming availability of gcc/ghc/Python-X.Y when
> >   arch/~arch only has something for  > - my favourite: assuming udev is at version X for arch/~arch when
> >   it has been broken there for roughly twelve kernel versions due
> >   to udev/systemd upstream not caring. The information is one
> >   equery-y command line away, but no, let's file that bug.
> >
>
> That's a failing of the arch team or the committer then - or whomever
> keyworded the package without testing the dependencies.  That's why the
> keywording bugs happen when dependencies change - and yes, occasionally
> a dependency loses it's keywords and that may be where the issue comes
> from, I'm not sure.  This used to be watched very closely, but I believe
> the tool being used broke at some point.
>
> What exactly do you mean, it's just one command line away but let's file
> the bug - yes a bug SHOULD be filed, so that the people know of the
> issue so it doesn't get repeated, over and over.
>
>
> > Having every arch team chase the deps for every package is very,
> > very frustrating, since it is so trivial a problem. We need a
> > tool that answers the question: "I want to mov cat/pkg-1.2.3 to
> > stable for arches a, b and c, what do I need?" for _every
> > package_. Some groups seem to have tooling for this, but it is
> > far from easily (obviously?) available, so every team gets to
> > re-discover dependency hell. Ruby is especially bad since
> > FEATURES=test make the depgraph explode (and sometimes circular).
> >
> > Regards,
> > Tobias
> >
> >
>
> The only fear I have about CI, is that we turn into every other distro
> out there where "it builds, ship it!" - I know I prefer to have our arm
> team actually test the packages more than just doing FEATURES=test
> (assuming the tests aren't broken on arm) emerge, although I know there
> are some people on the team who feel that it's too much to actually test
> all of the arm boards. For a long time, certain binary distros were
> compiling anything and everything, and if it built for other arches it
> was available.  Even if there was no way it would possibly work on that
> arch.
>
>
So don't keyword or stabilize packages you don't test thoroughly. I see how
CI *could* be used to do bad things; but I don't see anyone proposing it be
used in that way; nor do you have to accept such suggestions (its your
arch, after all.)

-A


> Regards,
> Steev
>
>
>

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Steev Klimaszewski]

On Wed, 2015-07-08 at 21:11 +0200, Tobias Klausmann wrote:
> Hi! 
> 
> On Wed, 08 Jul 2015, Ciaran McCreesh wrote:
> > On Wed, 8 Jul 2015 20:07:34 +0200
> > Tobias Klausmann  wrote:
> > > In essence, assuming we can "just scale" to make CI work is
> > > ignoring the matter of the slower archs. And I suspect the "it
> > > works on amd64, fuck everyone else" is not something we want to
> > > pick as a motto.
> > 
> > "It works on amd64 on a clean build system" is a heck of a lot better
> > than "it may or may not work on one developer's heavily modified
> > box"... The point of testing is not to catch all problems. It's just
> > there to catch some simple screwups, cheaply.
> 
> Agreed. Still, in my experience, problems that are not seen on
> amd64 are the vast majority of timesinks. Usually, by the time
> non-amd64 shows up on a non-security bug, the Basic Bullshit™ has
> been sorted. And even if it isn't: Arches are usually quick to
> point it out and the rest of arches move on to the next bug. The
> truly arch-dependent bugs are what wastes my time:
> 
> For example:
> 
> - dependencies not being keyworded for arch or ~arch but only
>   amd64/~amd64
> - dependencies not even building on ~arch, but on ~amd64
> - package assuming availability of gcc/ghc/Python-X.Y when
>   arch/~arch only has something for  - my favourite: assuming udev is at version X for arch/~arch when
>   it has been broken there for roughly twelve kernel versions due
>   to udev/systemd upstream not caring. The information is one
>   equery-y command line away, but no, let's file that bug.
> 

That's a failing of the arch team or the committer then - or whomever
keyworded the package without testing the dependencies.  That's why the
keywording bugs happen when dependencies change - and yes, occasionally
a dependency loses it's keywords and that may be where the issue comes
from, I'm not sure.  This used to be watched very closely, but I believe
the tool being used broke at some point.

What exactly do you mean, it's just one command line away but let's file
the bug - yes a bug SHOULD be filed, so that the people know of the
issue so it doesn't get repeated, over and over.  


> Having every arch team chase the deps for every package is very,
> very frustrating, since it is so trivial a problem. We need a
> tool that answers the question: "I want to mov cat/pkg-1.2.3 to
> stable for arches a, b and c, what do I need?" for _every
> package_. Some groups seem to have tooling for this, but it is
> far from easily (obviously?) available, so every team gets to
> re-discover dependency hell. Ruby is especially bad since
> FEATURES=test make the depgraph explode (and sometimes circular).
> 
> Regards,
> Tobias
> 
> 

The only fear I have about CI, is that we turn into every other distro
out there where "it builds, ship it!" - I know I prefer to have our arm
team actually test the packages more than just doing FEATURES=test
(assuming the tests aren't broken on arm) emerge, although I know there
are some people on the team who feel that it's too much to actually test
all of the arm boards. For a long time, certain binary distros were
compiling anything and everything, and if it built for other arches it
was available.  Even if there was no way it would possibly work on that
arch.  

Regards,
Steev

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[hasufell]

On 07/08/2015 09:14 PM, Tobias Klausmann wrote:
> 
> I explicitly point out that amd64
> is welcome to do whatever they want regarding CI, but that I
> suspect that the rift between it and the "lesser" architectures
> will become wider.
> 

That is technically correct, but it's not really an argument. The
quality of the lesser arches will be the same as it was before, it will
not get worse. The quality of the different arches has _never_ been
consistent. Not even between x86 and amd64. It always depends on
manpower, resources and how much it is used in the community. I feel we
are drifting a bit offtopic.

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Tobias Klausmann]

Hi! 

On Wed, 08 Jul 2015, Alec Warner wrote:

> On Wed, Jul 8, 2015 at 11:07 AM, Tobias Klausmann 
> wrote:
> 
> > tl;dr: Continuous Integration is a neat idea if you have the
> > Hardware. The off-mainstream arch teams don't.
> 
> Clearly because we cannot be perfect, we should not even try!
> Realistically aside from the major arches none of the other arches have
> large userbases. I think quality for the sake of quality is pretty silly;
> but if we can improve the quality of arches where hardware is readily
> available we should do so (regardless of minority architecture objections.)

Read what I wrote further down. I explicitly point out that amd64
is welcome to do whatever they want regarding CI, but that I
suspect that the rift between it and the "lesser" architectures
will become wider.

Regards,
Tobias

-- 
Sent from aboard the Culture ship
GSV (System Class) Empiricist

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Tobias Klausmann]

Hi! 

On Wed, 08 Jul 2015, Ciaran McCreesh wrote:
> On Wed, 8 Jul 2015 20:07:34 +0200
> Tobias Klausmann  wrote:
> > In essence, assuming we can "just scale" to make CI work is
> > ignoring the matter of the slower archs. And I suspect the "it
> > works on amd64, fuck everyone else" is not something we want to
> > pick as a motto.
> 
> "It works on amd64 on a clean build system" is a heck of a lot better
> than "it may or may not work on one developer's heavily modified
> box"... The point of testing is not to catch all problems. It's just
> there to catch some simple screwups, cheaply.

Agreed. Still, in my experience, problems that are not seen on
amd64 are the vast majority of timesinks. Usually, by the time
non-amd64 shows up on a non-security bug, the Basic Bullshit™ has
been sorted. And even if it isn't: Arches are usually quick to
point it out and the rest of arches move on to the next bug. The
truly arch-dependent bugs are what wastes my time:

For example:

- dependencies not being keyworded for arch or ~arch but only
  amd64/~amd64
- dependencies not even building on ~arch, but on ~amd64
- package assuming availability of gcc/ghc/Python-X.Y when
  arch/~arch only has something for 

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Alec Warner]

On Wed, Jul 8, 2015 at 11:07 AM, Tobias Klausmann 
wrote:

> Hi!
>
> This got a bit rambly, sorry 'bout that.
>
> tl;dr: Continuous Integration is a neat idea if you have the
> Hardware. The off-mainstream arch teams don't.
>

Clearly because we cannot be perfect, we should not even try!
Realistically aside from the major arches none of the other arches have
large userbases. I think quality for the sake of quality is pretty silly;
but if we can improve the quality of arches where hardware is readily
available we should do so (regardless of minority architecture objections.)

-A


>
>
> On Tue, 07 Jul 2015, Ciaran McCreesh wrote:
> > On Tue, 07 Jul 2015 08:04:47 +0800
> > Patrick Lauer  wrote:
> > > I'll laugh about it next time I update OpenFOAM:
> > >
> > > Fri Jun 27 12:52:19 2014 >>> sci-libs/openfoam-2.3.0
> > >merge time: 1 hour, 5 minutes and 8 seconds.
> > > or
> > >
> > > Sun Jun 29 20:36:09 2014 >>> sci-mathematics/nusmv-2.5.4
> > >merge time: 2 hours, 58 minutes.
> >
> > What's the problem? Better the build bot wastes that time once than a
> > whole bunch of users do.
>
> Just be aware that that Just Won't Happen for the off-mainstream
> archs. We just don't have the hardware to keep up with something
> like that. Unless you want to employ several people reordering
> the CI checks so a test for glibc doesn't make mutt, util-linux,
> iptables and 55 other packages wait for hours.
>
> 'Cause invariably, if the CI system is delayed beyond the
> expectation for the package itself, it will be ignored.
>
> It would also mean that the other purposes the devboxes are used
> for will be delayed non-trivially. In the case of Alpha, that
> would for example be upstream gcc testing, and stage3 building. I
> am sure arches like PPC64, IA64 and so on have the same problem.
>
> > > That's without dependencies, so from a clean minimal starting point
> > > (once you figure out what useflags are needed) you're looking at 12+
> > > hours of walltime to get that checked. (On a reasonably modern Xeon
> > > with SSDs ...)
> >
> > Uh, no, because you use binary packages for the dependencies, and you
> > use a package mangler that can figure out the use flags for you.
>
> Even with binary package usage (which is not as efficient as it
> could be due to USE flags), testing Qt4 (as in compile it and run
> the test suite, which is the bare minimum) took me close to 10
> hours the other day. Not including fixing fetch problems halfway
> through. During this time, very little else got done on the one
> devbox we have.
>
> > > So thanks for your intentional comedy, but let's be serious here.
> >
> > Exherbo's been doing all this for years, and it works rather well. The
> > only comedy is that Gentoo doesn't even realise this is trivial to do
> > nowadays.
>
> Exherbo is not supporting as many off-mainstream architectures as
> we do, so the comparison is flawed at best. Yes, sure, let's run
> CI for amd64 and maybe x86 and whoever else has the hardware. But
> it will not speed up stabilization bugs regarding the long tail.
> It might even lead to people completely ignoring the slow
> architectures and the rift between amd64 and the rest becoming
> yet wider.
>
> Don't get me wrong, abandoning Alpha and other architectures is
> an option, but remember that for some of these, we are the last
> distro that still provides install media and a decent (as in:
> current and complete-ish) set of packages. The very fact that we
> are able to let amd64 and the rest drift a bit is the reason why
> we can still pull it off.
>
> I have considered dropping Alpha entirely (for myself, that is;
> I'd resign as the arch team lead and stop working on it; the
> devbox, which is soft-donated through me, would stay available).
> But I would rather not, for various reasons, none of which are
> technical. Then again, I'm not a Gentoo dev because it makes
> sense rationally (it does, but it's not my reason).
>
> In essence, assuming we can "just scale" to make CI work is
> ignoring the matter of the slower archs. And I suspect the "it
> works on amd64, fuck everyone else" is not something we want to
> pick as a motto.
>
> Regards,
> Tobias`
>
>
>
> --
> Sent from aboard the Culture ship
> GSV (System Class) Empiricist
>
>

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Ciaran McCreesh]

On Wed, 8 Jul 2015 20:07:34 +0200
Tobias Klausmann  wrote:
> In essence, assuming we can "just scale" to make CI work is
> ignoring the matter of the slower archs. And I suspect the "it
> works on amd64, fuck everyone else" is not something we want to
> pick as a motto.

"It works on amd64 on a clean build system" is a heck of a lot better
than "it may or may not work on one developer's heavily modified
box"... The point of testing is not to catch all problems. It's just
there to catch some simple screwups, cheaply.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Tobias Klausmann]

Hi! 

This got a bit rambly, sorry 'bout that.

tl;dr: Continuous Integration is a neat idea if you have the
Hardware. The off-mainstream arch teams don't.


On Tue, 07 Jul 2015, Ciaran McCreesh wrote:
> On Tue, 07 Jul 2015 08:04:47 +0800
> Patrick Lauer  wrote:
> > I'll laugh about it next time I update OpenFOAM:
> > 
> > Fri Jun 27 12:52:19 2014 >>> sci-libs/openfoam-2.3.0
> >merge time: 1 hour, 5 minutes and 8 seconds.
> > or
> > 
> > Sun Jun 29 20:36:09 2014 >>> sci-mathematics/nusmv-2.5.4
> >merge time: 2 hours, 58 minutes.
> 
> What's the problem? Better the build bot wastes that time once than a
> whole bunch of users do.

Just be aware that that Just Won't Happen for the off-mainstream
archs. We just don't have the hardware to keep up with something
like that. Unless you want to employ several people reordering
the CI checks so a test for glibc doesn't make mutt, util-linux,
iptables and 55 other packages wait for hours.

'Cause invariably, if the CI system is delayed beyond the
expectation for the package itself, it will be ignored.

It would also mean that the other purposes the devboxes are used
for will be delayed non-trivially. In the case of Alpha, that
would for example be upstream gcc testing, and stage3 building. I
am sure arches like PPC64, IA64 and so on have the same problem.

> > That's without dependencies, so from a clean minimal starting point
> > (once you figure out what useflags are needed) you're looking at 12+
> > hours of walltime to get that checked. (On a reasonably modern Xeon
> > with SSDs ...)
> 
> Uh, no, because you use binary packages for the dependencies, and you
> use a package mangler that can figure out the use flags for you.

Even with binary package usage (which is not as efficient as it
could be due to USE flags), testing Qt4 (as in compile it and run
the test suite, which is the bare minimum) took me close to 10
hours the other day. Not including fixing fetch problems halfway
through. During this time, very little else got done on the one
devbox we have.

> > So thanks for your intentional comedy, but let's be serious here.
> 
> Exherbo's been doing all this for years, and it works rather well. The
> only comedy is that Gentoo doesn't even realise this is trivial to do
> nowadays.

Exherbo is not supporting as many off-mainstream architectures as
we do, so the comparison is flawed at best. Yes, sure, let's run
CI for amd64 and maybe x86 and whoever else has the hardware. But
it will not speed up stabilization bugs regarding the long tail.
It might even lead to people completely ignoring the slow
architectures and the rift between amd64 and the rest becoming
yet wider.

Don't get me wrong, abandoning Alpha and other architectures is
an option, but remember that for some of these, we are the last
distro that still provides install media and a decent (as in:
current and complete-ish) set of packages. The very fact that we
are able to let amd64 and the rest drift a bit is the reason why
we can still pull it off.

I have considered dropping Alpha entirely (for myself, that is;
I'd resign as the arch team lead and stop working on it; the
devbox, which is soft-donated through me, would stay available).
But I would rather not, for various reasons, none of which are
technical. Then again, I'm not a Gentoo dev because it makes
sense rationally (it does, but it's not my reason).

In essence, assuming we can "just scale" to make CI work is
ignoring the matter of the slower archs. And I suspect the "it
works on amd64, fuck everyone else" is not something we want to
pick as a motto.

Regards,
Tobias`



-- 
Sent from aboard the Culture ship
GSV (System Class) Empiricist

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Ciaran McCreesh]

On Tue, 07 Jul 2015 08:04:47 +0800
Patrick Lauer  wrote:
> On 07/07/15 01:27, Ciaran McCreesh wrote:
> > On Mon, 06 Jul 2015 13:04:35 -0400
> > Michael Orlitzky  wrote:
> >> I would love my commits to be reviewed, but I usually don't feel
> >> like reviewing anyone else's. That's... not uncommon.
> > 
> > Well, you could at least get your commits reviewed by an automated
> > build system that starts from a clean stage each time. That's
> > better than nothing.
> > 
> I'll laugh about it next time I update OpenFOAM:
> 
> Fri Jun 27 12:52:19 2014 >>> sci-libs/openfoam-2.3.0
>merge time: 1 hour, 5 minutes and 8 seconds.
> or
> 
> Sun Jun 29 20:36:09 2014 >>> sci-mathematics/nusmv-2.5.4
>merge time: 2 hours, 58 minutes.

What's the problem? Better the build bot wastes that time once than a
whole bunch of users do.

> That's without dependencies, so from a clean minimal starting point
> (once you figure out what useflags are needed) you're looking at 12+
> hours of walltime to get that checked. (On a reasonably modern Xeon
> with SSDs ...)

Uh, no, because you use binary packages for the dependencies, and you
use a package mangler that can figure out the use flags for you.

> So thanks for your intentional comedy, but let's be serious here.

Exherbo's been doing all this for years, and it works rather well. The
only comedy is that Gentoo doesn't even realise this is trivial to do
nowadays.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Andrew Savchenko]

Hi,

On Tue, 7 Jul 2015 16:16:02 +1200 Kent Fredric wrote:
> It would be really nice if we could define some sort of variable in
> the ebuild itself with a relative cost metric for the ebuilds install
> time. It wouldn't need to be precise, just ballpark figures so the
> testing boxes can go "Ok, a full build of this will block testing
> everything else for XUNIT time, is this worth it?".

there is no need to increase overhead for developers for a stuff
that can be easily generated: just fill a raw build time (without
ccache/distcc) during test runs themselves.

Best regards,
Andrew Savchenko


pgpf6H0T2HXJY.pgp
Description: PGP signature

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Kent Fredric]

On 7 July 2015 at 12:04, Patrick Lauer  wrote:
>
> So thanks for your intentional comedy, but let's be serious here.


It would be really nice if we could define some sort of variable in
the ebuild itself with a relative cost metric for the ebuilds install
time. It wouldn't need to be precise, just ballpark figures so the
testing boxes can go "Ok, a full build of this will block testing
everything else for XUNIT time, is this worth it?".

Then you could have the primary test box exclude things over a certain
unit size and adjust the text boxes unit until the workflow is right.

( and then have auxliary boxes that test >XUNIT packages on demand or
something ).

I would also like a flying magical pony.

-- 
Kent

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

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Patrick Lauer]

On 07/07/15 01:27, Ciaran McCreesh wrote:
> On Mon, 06 Jul 2015 13:04:35 -0400
> Michael Orlitzky  wrote:
>> I would love my commits to be reviewed, but I usually don't feel like
>> reviewing anyone else's. That's... not uncommon.
> 
> Well, you could at least get your commits reviewed by an automated build
> system that starts from a clean stage each time. That's better than
> nothing.
> 
I'll laugh about it next time I update OpenFOAM:

Fri Jun 27 12:52:19 2014 >>> sci-libs/openfoam-2.3.0
   merge time: 1 hour, 5 minutes and 8 seconds.
or

Sun Jun 29 20:36:09 2014 >>> sci-mathematics/nusmv-2.5.4
   merge time: 2 hours, 58 minutes.


That's without dependencies, so from a clean minimal starting point
(once you figure out what useflags are needed) you're looking at 12+
hours of walltime to get that checked. (On a reasonably modern Xeon with
SSDs ...)

So thanks for your intentional comedy, but let's be serious here.

Have fun,

Patrick

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Alec Warner]

On Mon, Jul 6, 2015 at 9:42 AM, Peter Stuge  wrote:

> Alec Warner wrote:
> > Its difficult to make a large change like "all commits require review",
> > particularly for long-time contributors who are expecting to move
> quickly.
>
> I think it's a character flaw (maybe hubris due to lack of experience
> and/or ignorance?) to lack the humility to say that I would prefer my
> commits to be reviewed by peers.
>

Oh I'm not making that argument (its a tough one anyway.)

I haven't done any research in Gentoo in terms of error rates (how many),
who makes errors (newbies? oldbies? everyone?), what the error impact is
(minor, major, data loss?), and so on.

On my old team at work we had code review, but it did not impact quality
very much because (manual) review catches a pretty specific set of
conditions some of the time. We had vastly superior quality by adopting
linters (to prevent really dumb mistakes that code review also didn't catch
consistently) and fast[1] enough automated testing that caught large
subsets of other really common errors. Of course, these are all quite low
hanging fruit.

[1] for some subset of fast; I think tests still took 5 minutes or so.

>
> It is obviously easier to stick my head in the sand, but then I
> should probably keep my crap in an overlay. (I do, and am happy!)
>
> If I were committing to gentoo I would want help from my peers to
> ensure that what I commit is not just done well but also done right.
>

I think the past has proven that not all Gentoo developers feel this way (I
never did; although I have not committed to the tree in some time.)


>
>
> > I'd be curious how many subprojects use review
>
> I suspect that it's rare. Most developers are in my experience unable
> to work with review.
>
>
> > learning purposes.
>
> Another significant benefit of review, besides the obvious quality benefit.
>
>
> > I'd also be curious what adoption of a code review system would be
> > like if it was not required (but was available, and perhaps
> > required for specific subprojects that adopt it.)
>
> I think this is a lovely idea! I'd really like that setup!
>

>
> //Peter
>
>

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Ciaran McCreesh]

On Mon, 06 Jul 2015 19:34:05 +0200
hasufell  wrote:
> On 07/06/2015 07:27 PM, Ciaran McCreesh wrote:
> > On Mon, 06 Jul 2015 13:04:35 -0400
> > Michael Orlitzky  wrote:
> >> I would love my commits to be reviewed, but I usually don't feel
> >> like reviewing anyone else's. That's... not uncommon.
> > 
> > Well, you could at least get your commits reviewed by an automated
> > build system that starts from a clean stage each time. That's
> > better than nothing.
> 
> That makes sense. But it will probably have to run on a gentoo infra
> server. Can you see the problem?

I dunno, maybe if you ask the Exherbo people nicely they might share
their setup.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[hasufell]

On 07/06/2015 07:27 PM, Ciaran McCreesh wrote:
> On Mon, 06 Jul 2015 13:04:35 -0400
> Michael Orlitzky  wrote:
>> I would love my commits to be reviewed, but I usually don't feel like
>> reviewing anyone else's. That's... not uncommon.
> 
> Well, you could at least get your commits reviewed by an automated build
> system that starts from a clean stage each time. That's better than
> nothing.
> 

That makes sense. But it will probably have to run on a gentoo infra
server. Can you see the problem?

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Ciaran McCreesh]

On Mon, 06 Jul 2015 13:04:35 -0400
Michael Orlitzky  wrote:
> I would love my commits to be reviewed, but I usually don't feel like
> reviewing anyone else's. That's... not uncommon.

Well, you could at least get your commits reviewed by an automated build
system that starts from a clean stage each time. That's better than
nothing.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Peter Stuge]

hasufell wrote:
> that said... I don't think it currently makes sense to enforce
> a strict global review workflow.

For the record, neither do I, and I never proposed that it should
hold up starting to use Git.


//Peter

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[hasufell]

On 07/05/2015 08:05 AM, Andrew Savchenko wrote:
> On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote:
>> It's important that the review flow is well-understood and efficient.
> 
> This is impossible in our case due to the lack of manpower.
> We already have a lot of bugs, patches, stabilization requests
> hanging over there for months and even years. Stabilization request
> will require at least two developers to participate in each commit.
> This will double manpower required at least. Such approach can kill
> the whole project.
> 

People misinterpret "manpower". If we successfully switch to a
code-review approach, then we will need _less_ manpower in the sense of
actual gentoo developers.

However, this does not and cannot happen over night since it requires a
shift of thinking and a change of culture, involving the whole community.

But if we just want to add more independent committers to the core
gentoo tree, then we are definitely making quality worse.

I'm not particularly sure that an alternative review-based workflow can
work here, given that our workflow has been broken for quite a few
years. Such things become a strong habit and may leave some of our
developers in confusion.

But it could start (and already has, afaik) with project-internal
requirements (e.g. kde project demanding reviews). When the different
projects increase workflow strictness, it will increase overall
strictness as well.

> Code review is good at a limited scope, e.g. for non-developers
> where we have review anyway.
> 

This is not enough to maintain high quality. I've seen some ebuilds in
user overlays which have higher quality than their gx86 counterpart.


However, that said... I don't think it currently makes sense to enforce
a strict global review workflow. However, we should encourage
gentoo-internal projects to become more strict (and e.g. only have one
or two "pushers").

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Ciaran McCreesh]

On Mon, 06 Jul 2015 07:25:03 +0800
Patrick Lauer  wrote:
> On Sunday 05 July 2015 13:46:10 William Hubbs wrote:
> > On Sun, Jul 05, 2015 at 09:05:59AM +0300, Andrew Savchenko wrote:
> > > On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote:
> > > > It's important that the review flow is well-understood and
> > > > efficient.
> > > 
> > > This is impossible in our case due to the lack of manpower.
> > > We already have a lot of bugs, patches, stabilization requests
> > > hanging over there for months and even years. Stabilization
> > > request will require at least two developers to participate in
> > > each commit. This will double manpower required at least. Such
> > > approach can kill the whole project.
> > 
> > Agreed. Forcing all commits from developers to go through a code
> > review from another developer before they hit the tree would
> > potentially kill the entire project. I would strongly veto
> > something like this, because we flat out don't have the manpower to
> > keep up with it.
> > 
> ... or you have some pranksters just ok-ing all commits during their
> morning coffee, independent of content, which would keep things
> working at the cost of quality ...

Spoken like someone who's never used a code review system. Pranksters
can no more "ok all commits" than they can "commit whatever they
like", since you treat giving +2 permissions like you treat giving push
access.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Michael Orlitzky]

On 07/06/2015 12:42 PM, Peter Stuge wrote:
> Alec Warner wrote:
>> Its difficult to make a large change like "all commits require review",
>> particularly for long-time contributors who are expecting to move quickly.
> 
> I think it's a character flaw (maybe hubris due to lack of experience
> and/or ignorance?) to lack the humility to say that I would prefer my
> commits to be reviewed by peers.
> 

I would love my commits to be reviewed, but I usually don't feel like
reviewing anyone else's. That's... not uncommon.

So what it comes down to is that I would rather have my work reviewed by
no one and get committed rather than be reviewed by no one and sit in a
review queue for months or years.

And while it's not quite as good, the stabilization process serves a
similar purpose.

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Peter Stuge]

Alec Warner wrote:
> Its difficult to make a large change like "all commits require review",
> particularly for long-time contributors who are expecting to move quickly.

I think it's a character flaw (maybe hubris due to lack of experience
and/or ignorance?) to lack the humility to say that I would prefer my
commits to be reviewed by peers.

It is obviously easier to stick my head in the sand, but then I
should probably keep my crap in an overlay. (I do, and am happy!)

If I were committing to gentoo I would want help from my peers to
ensure that what I commit is not just done well but also done right.


> I'd be curious how many subprojects use review

I suspect that it's rare. Most developers are in my experience unable
to work with review.


> learning purposes.

Another significant benefit of review, besides the obvious quality benefit.


> I'd also be curious what adoption of a code review system would be
> like if it was not required (but was available, and perhaps
> required for specific subprojects that adopt it.)

I think this is a lovely idea! I'd really like that setup!


//Peter

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Alec Warner]

On Sat, Jul 4, 2015 at 11:05 PM, Andrew Savchenko 
wrote:

> On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote:
> > It's important that the review flow is well-understood and efficient.
>
> This is impossible in our case due to the lack of manpower.
> We already have a lot of bugs, patches, stabilization requests
> hanging over there for months and even years. Stabilization request
> will require at least two developers to participate in each commit.
> This will double manpower required at least. Such approach can kill
> the whole project.

Code review is good at a limited scope, e.g. for non-developers
> where we have review anyway.
>
>
Manpower issues aside, my perception of the project is that speed is valued
over quality; and this has been the case for many many years. Its difficult
to make a large change like "all commits require review", particularly for
long-time contributors who are expecting to move quickly.

I realize that a subset of the community wants quality and code review is
certainly one way to improve quality. I'd be curious how many subprojects
use review (I know infra did it informally, particularly when making
changes to parts of the infrastructure that we were unfamiliar with; for
learning purposes.)

I'd also be curious what adoption of a code review system would be like if
it was not required (but was available, and perhaps required for specific
subprojects that adopt it.)

-A


> And as was already told in this thread, the best is the enemy of
> the good. In no way we should delay git migration due to possible
> git review.
>
> Best regards,
> Andrew Savchenko
>

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Patrick Lauer]

On Sunday 05 July 2015 13:46:10 William Hubbs wrote:
> On Sun, Jul 05, 2015 at 09:05:59AM +0300, Andrew Savchenko wrote:
> > On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote:
> > > It's important that the review flow is well-understood and efficient.
> > 
> > This is impossible in our case due to the lack of manpower.
> > We already have a lot of bugs, patches, stabilization requests
> > hanging over there for months and even years. Stabilization request
> > will require at least two developers to participate in each commit.
> > This will double manpower required at least. Such approach can kill
> > the whole project.
> 
> Agreed. Forcing all commits from developers to go through a code review
> from another developer before they hit the tree would potentially
> kill the entire project. I would strongly veto something like this,
> because we flat out don't have the manpower to keep up with it.
> 
... or you have some pranksters just ok-ing all commits during their morning 
coffee, independent of content, which would keep things working at the cost of 
quality ...

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[William Hubbs]

On Sun, Jul 05, 2015 at 09:05:59AM +0300, Andrew Savchenko wrote:
> On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote:
> > It's important that the review flow is well-understood and efficient.
> 
> This is impossible in our case due to the lack of manpower.
> We already have a lot of bugs, patches, stabilization requests
> hanging over there for months and even years. Stabilization request
> will require at least two developers to participate in each commit.
> This will double manpower required at least. Such approach can kill
> the whole project.

Agreed. Forcing all commits from developers to go through a code review
from another developer before they hit the tree would potentially
kill the entire project. I would strongly veto something like this,
because we flat out don't have the manpower to keep up with it.

> Code review is good at a limited scope, e.g. for non-developers
> where we have review anyway.
 
 Agreed; I could see something like this being beneficial.

 William



signature.asc
Description: Digital signature

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Andrew Savchenko]

On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote:
> It's important that the review flow is well-understood and efficient.

This is impossible in our case due to the lack of manpower.
We already have a lot of bugs, patches, stabilization requests
hanging over there for months and even years. Stabilization request
will require at least two developers to participate in each commit.
This will double manpower required at least. Such approach can kill
the whole project.

Code review is good at a limited scope, e.g. for non-developers
where we have review anyway.

And as was already told in this thread, the best is the enemy of
the good. In no way we should delay git migration due to possible
git review.

Best regards,
Andrew Savchenko


pgpaeQblTgCEP.pgp
Description: PGP signature

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Peter Stuge]

NP-Hardass wrote:
> >> or do they typically restrict review to a certain class of users?
> >
> >Hm, why would that end up happening? I'm not saying it can't, just
> >that I don't understand why it would. What do you have in mind?
> 
> Well, it was just proposed earlier in the thread that it could be
> used for non-devs (primarily/only), hence two classes of users,
> those subjected to review and those not.

Ah I understand. Personally I think review is just as important for
devs as for non-devs. The big win with a review tool/flow is that it
becomes *at all possible* for non-devs to contribute efficiently to
the project, and if the review tool is good then giving review is
also efficient.

Some will always be more equal than others, but..


> An alternative is a situation where all users, developer and non
> developer alike require review

I feel that this is the only way to achieve the best quality.


> with the review requirements different between the two

I don't feel that this is as useful for quality. Devs produce crap too.

It's important that the review flow is well-understood and efficient.

It's important that everyone working is *motivated* to participate in
review. I've had plenty of experience with smart people who simply do
not want to participate in a review flow and that's all it takes for
the review flow to fail.


//Peter

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[NP-Hardass]

On July 4, 2015 1:49:20 PM EDT, Peter Stuge  wrote: 
>
>NP-Hardass wrote:
>> I am unfamiliar with how other big projects that use code review
>> systems. Do they generally make (almost) everyone participate,
>
>In coreboot, which admittedly isn't such a big project, my impression
>is that the introduction of Gerrit has lead to increased
>participation. Previously patches and review went across the mailing
>list, and many simply filtered the whole list into a folder.
>
>
>> or do they typically restrict review to a certain class of users?
>
>Hm, why would that end up happening? I'm not saying it can't, just
>that I don't understand why it would. What do you have in mind?
>
>
>//Peter

Well, it was just proposed earlier in the thread that it could be used for 
non-devs (primarily/only), hence two classes of users, those subjected to 
review and those not.

An alternative is a situation where all users, developer and non developer 
alike require review with the review requirements different between the two, 
e.g. devs need one signoff, non devs need two.

Additionally, for certain aspects, a hybrid of those two might be useful. A 
project or herd accepts direct commits to its packages from its members and has 
code review for non members (with the number of signoffs dependent on the 
group/content.

-- 
NP-Hardass

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Peter Stuge]

William Hubbs wrote:
> If we do add a code review system, it should be fully accessible from
> the command line. Pybugz is almost there for bugzilla; the only thing it
> lacks is the ability to reply to specific comments.

Gerrit is also almost there, it has an ssh interface which is very
usable for most operations, but not so much for writing inline
comments within patches, which is a nice feature of Gerrit that I
would like to use. At the moment I have to revert to the web
interface to do it.


NP-Hardass wrote:
> I am unfamiliar with how other big projects that use code review
> systems. Do they generally make (almost) everyone participate,

In coreboot, which admittedly isn't such a big project, my impression
is that the introduction of Gerrit has lead to increased
participation. Previously patches and review went across the mailing
list, and many simply filtered the whole list into a folder.


> or do they typically restrict review to a certain class of users?

Hm, why would that end up happening? I'm not saying it can't, just
that I don't understand why it would. What do you have in mind?


//Peter

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[NP-Hardass]

I am unfamiliar with how other big projects that use code review systems. Do 
they generally make (almost) everyone participate, or do they typically 
restrict review to a certain class of users?

--
NP-Hardass

On July 4, 2015 4:14:14 AM EDT, "Manuel Rüger"  wrote:
>On 03.07.2015 22:22, Robin H. Johnson wrote:
>> (Breaking the thread, because I believe this topic needs further
>> discussion).
>> 
>> On Fri, Jul 03, 2015 at 03:39:31PM +0200, Manuel Rüger wrote:
>>> Are there still any plans to use a code review system like gerrit
>that
>>> will avoid merges, rebases etc. to the tree by just accepting and
>>> serializing patches?
>> Merges are a fact of life, they will be happening.
>> This was included on:
>> https://wiki.gentoo.org/wiki/Gentoo_git_workflow
>> 
>> Rebases of already published commits must be avoided.
>> 
>> But beyond that, the general discussion was that a code review system
>> was not in the immediate future...
>> 
>> If the merge workflow becomes too problematic due to the high rate of
>> change, then we can revisit those systems, to take advantage of their
>> auto-merging functionality, but probably only in combination with the
>QA
>> testsuites.
>> 
>
>Using a Code Review System and allowing direct commits are not mutually
>exclusive.
>If infra has got time to set it up, this could be an option in addition
>to direct commits for developers and we could make it obligatory (e.g.
>for the first month) for new developers.
>
>It would also allow proxied maintainers to commit to the tree more
>easily, as it will require just an additional ack by the proxy
>maintainer.
>
>Manuel

-- 
NP-Hardass

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[William Hubbs]

On Sat, Jul 04, 2015 at 10:14:14AM +0200, Manuel Rüger wrote:
> On 03.07.2015 22:22, Robin H. Johnson wrote:
> > (Breaking the thread, because I believe this topic needs further
> > discussion).
> > 
> > On Fri, Jul 03, 2015 at 03:39:31PM +0200, Manuel Rüger wrote:
> >> Are there still any plans to use a code review system like gerrit that
> >> will avoid merges, rebases etc. to the tree by just accepting and
> >> serializing patches?
> > Merges are a fact of life, they will be happening.
> > This was included on:
> > https://wiki.gentoo.org/wiki/Gentoo_git_workflow
> > 
> > Rebases of already published commits must be avoided.
> > 
> > But beyond that, the general discussion was that a code review system
> > was not in the immediate future...
> > 
> > If the merge workflow becomes too problematic due to the high rate of
> > change, then we can revisit those systems, to take advantage of their
> > auto-merging functionality, but probably only in combination with the QA
> > testsuites.
> > 
> 
> Using a Code Review System and allowing direct commits are not mutually
> exclusive.
> If infra has got time to set it up, this could be an option in addition
> to direct commits for developers and we could make it obligatory (e.g.
> for the first month) for new developers.
> 
> It would also allow proxied maintainers to commit to the tree more
> easily, as it will require just an additional ack by the proxy maintainer.

If we do add a code review system, it should be fully accessible from
the command line. Pybugz is almost there for bugzilla; the only thing it
lacks is the ability to reply to specific comments.

William



signature.asc
Description: Digital signature

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Manuel Rüger]

On 03.07.2015 22:22, Robin H. Johnson wrote:
> (Breaking the thread, because I believe this topic needs further
> discussion).
> 
> On Fri, Jul 03, 2015 at 03:39:31PM +0200, Manuel Rüger wrote:
>> Are there still any plans to use a code review system like gerrit that
>> will avoid merges, rebases etc. to the tree by just accepting and
>> serializing patches?
> Merges are a fact of life, they will be happening.
> This was included on:
> https://wiki.gentoo.org/wiki/Gentoo_git_workflow
> 
> Rebases of already published commits must be avoided.
> 
> But beyond that, the general discussion was that a code review system
> was not in the immediate future...
> 
> If the merge workflow becomes too problematic due to the high rate of
> change, then we can revisit those systems, to take advantage of their
> auto-merging functionality, but probably only in combination with the QA
> testsuites.
> 

Using a Code Review System and allowing direct commits are not mutually
exclusive.
If infra has got time to set it up, this could be an option in addition
to direct commits for developers and we could make it obligatory (e.g.
for the first month) for new developers.

It would also allow proxied maintainers to commit to the tree more
easily, as it will require just an additional ack by the proxy maintainer.

Manuel




signature.asc
Description: OpenPGP digital signature

Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Duncan]

Robin H. Johnson posted on Fri, 03 Jul 2015 20:22:25 + as excerpted:

> On Fri, Jul 03, 2015 at 03:39:31PM +0200, Manuel Rüger wrote:
>> Are there still any plans to use a code review system like gerrit [...]
 
> [T]he general discussion was that a code review system was not in the
> immediate future...

I believe the general sense of previous discussion was that the git 
switch has been delayed too long already, and while code review, etc, 
might be nice, in this case it's the perfect being the enemy of the good, 
in that it would likely result in another half-decade of gentoo on cvs 
while these /additional/ things were worked out, and that was simply 
judged to be an unacceptable tradeoff to make.

Which I (strongly!) agree with.  The switch to git won't be perfect, but 
we /can/ do it now, and we should.  If code review, etc, is to happen, 
once we're on git it can happen incrementally, but we're not losing 
anything we have already by not doing it with the switch to git, while 
just the switch to git alone is already a huge improvement, bringing us 
into the current era, at least.  And there's always going to be one more 
thing we could change to make things better... at the cost of putting off 
the big switch yet again... ultimately indefinitely, letting the perfect 
be the enemy of the good, to the benefit of the otherwise generally 
agreed to be unacceptable status quo.

-- 
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] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Rich Freeman]

On Fri, Jul 3, 2015 at 7:10 PM, Andrew Savchenko  wrote:
>
> We have a rule of "one year compatibility period". ChangeLog shows
> that git-2.2.0 was introduced on 02 Dec 2014. So pushed commits
> can't be enforced before 02 Dec 2015. (And yes, my laptop
> still uses an older version, that's why I was unable to find --sign
> in the git-push manual.)
>

In general we try to avoid breaking the upgrade path for user systems
that only upgrade annually, but no such limitation applies to
developers.  I don't think it is too much to expect a developer to use
a recent version of git.  Users don't need git push signing support to
use Gentoo.

By all means debate the importance of the feature/etc, but I don't see
a need to freeze any new git feature for a year before making use of
it with the gentoo repository.

If it really bothers you, do your pushes from a chroot.  It isn't like
I close any gcc-5 bugs with "can't be bothered to look at gcc-5 - give
me a call in a year or two."

-- 
Rich

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Andrew Savchenko]

On Fri, 3 Jul 2015 21:40:50 + Robin H. Johnson wrote:
> On Sat, Jul 04, 2015 at 12:19:41AM +0300, Andrew Savchenko wrote:
> > As I see from git docs only commits and tags may be signed. There
> > is no way to sign a push. Moreover there is no need to sign each
> > commit, see what Linux says on that:
> > http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html
> That was Linus's 2009 opinion, and he changed his mind since then, with
> the research into further attacks on SHA1.
> 
> Git (since 2.2) DOES support signed push. Look at the manpage for
> git-push, for the --signed option:
> http://git-scm.com/docs/git-push

We have a rule of "one year compatibility period". ChangeLog shows
that git-2.2.0 was introduced on 02 Dec 2014. So pushed commits
can't be enforced before 02 Dec 2015. (And yes, my laptop
still uses an older version, that's why I was unable to find --sign
in the git-push manual.)
 
Best regards,
Andrew Savchenko


pgpX34YRGtbiW.pgp
Description: PGP signature

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Rich Freeman]

On Fri, Jul 3, 2015 at 5:40 PM, Robin H. Johnson  wrote:
> On Sat, Jul 04, 2015 at 12:19:41AM +0300, Andrew Savchenko wrote:
>> As I see from git docs only commits and tags may be signed. There
>> is no way to sign a push. Moreover there is no need to sign each
>> commit, see what Linux says on that:
>> http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html
> That was Linus's 2009 opinion, and he changed his mind since then, with
> the research into further attacks on SHA1.
>

A few things.  I agree with where you're going, Robin, but I do take
issue with just one bit of your email.

First, signing commits in no way protects against attacks on SHA1.
The only thing that binds a commit record to the actual data in the
tree is an SHA1 hash.  If you are able to break SHA1 then all you need
to do is tamper with a file in the tree however you want, then add or
tamper with another file anywhere else in the tree such that the two
changes "cancel each other out" and result in the same SHA1 hash.
Then you swap out any blobs/trees you modified in the repository and
nobody is the wiser, especially with something like Gentoo where you
can stick something in a random filesdir anywhere in the tree where
nobody will notice it for a long time.  The commit record itself is
not touched, so its signature verifies just fine.

That said, I do support commit signing. It makes a lot more sense for
a project like Gentoo than a project like Linux.

With Linux, the distributed repositories everybody actually uses have
only one committer each for the most part.  The only person who
commits to mainline is Linus himself.  Then there is a release process
where all the commits for the week go out with a git tag, which is
signed.  Linus basically does the final QA on the mainline kernel
before it is released, and he assumes responsibility for every commit
that went into it.

In contrast, Gentoo has numerous committers and changes go right from
the dev's repository to every user's desktop.  When I make a commit
I'm only responsible for my own change - I don't do QA on the last 47
commits other random devs have made.  So, if the last commit doesn't
interact with mine in any way, chances are I won't do any testing of
it at all before I add my own signature - I won't even run repoman on
the entire tree.  So, a dev's commit signature is really a stamp of
quality on the diff between their commit and the last, not the tree as
a whole.  So, it really makes sense to the signing at the commit
level, and not at some higher level.  In fact, to do the signing at a
higher level really does amount to rubber-stamping changes in a way
that commit signing does not, based on how we assign responsibility.

If we were a release-based distro then tag signing would be much more important.

Finally, signing commits is really cheap, so why not just do it?

-- 
Rich

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Robin H. Johnson]

On Sat, Jul 04, 2015 at 12:19:41AM +0300, Andrew Savchenko wrote:
> As I see from git docs only commits and tags may be signed. There
> is no way to sign a push. Moreover there is no need to sign each
> commit, see what Linux says on that:
> http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html
That was Linus's 2009 opinion, and he changed his mind since then, with
the research into further attacks on SHA1.

Git (since 2.2) DOES support signed push. Look at the manpage for
git-push, for the --signed option:
http://git-scm.com/docs/git-push

The point of signed commits is to authenticate the creator of each
commit.

The point of signed pushes is to authenticate who introduced a commit
(it might NOT be the person who signed the commits) and intended it to
be on a specific branch.

A slightly out of date, but good backgrounder on signed commits is here:
http://mikegerwitz.com/papers/git-horror-story

The StackOverflow asking about signed push is a good reference as well:
http://stackoverflow.com/questions/27299355/why-does-git-need-signed-pushes

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

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Brian Dolbec]

On Sat, 4 Jul 2015 00:19:41 +0300
Andrew Savchenko  wrote:

> Hi,
> 
> On Fri, 3 Jul 2015 11:19:13 -0500 William Hubbs wrote:
> > On Fri, Jul 03, 2015 at 06:34:41AM +, Robin H. Johnson wrote:
> > > On Thu, Jul 02, 2015 at 09:46:18PM -0400, Brian Evans wrote:
> > > > Does this mean that
> > > > https://wiki.gentoo.org/wiki/Gentoo_git_workflow is no longer
> > > > draft or needs work or another document is meant to display the
> > > > new flow?
> > > It does cover most of the things needed.
> > > 
> > > It could use some revision regarding gkeys, and I'd like to also
> > > mandate signed pushes in addition to signed commits.
> > 
> > A push doesn't create any data, it just uploads it to the repo, so
> > how do you sign a push?
> 
> As I see from git docs only commits and tags may be signed. There
> is no way to sign a push. Moreover there is no need to sign each
> commit, see what Linux says on that:
> http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html
> 
...
> 
> Best regards,
> Andrew Savchenko

Newer version(s) of git do have git push --sign capability.  Sorry, I
don't know the versions that it applies to. It was recently added as a
feature. It also makes the push sig and data readily available for hook
use.

-- 
Brian Dolbec 

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Michael Orlitzky]

On 07/03/2015 05:19 PM, Andrew Savchenko wrote:
> 
> As I see from git docs only commits and tags may be signed. There
> is no way to sign a push.

This was new to me, but check out the "--signed" flag of git-push (1).


> Moreover there is no need to sign each
> commit, see what Linux says on that:
> http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html
> 
> ''
> Btw, there's a final reason, and probably the really real one.
> Signing each commit is totally stupid. It just means that you
> automate it, and you make the signature worth less. It also doesn't
> add any real value, since the way the git DAG-chain of SHA1's work,
> you only ever need _one_ signature to make all the commits
> reachable from that one be effectively covered by that one. So
> signing each commit is simply missing the point.
> ''

I think the next sentence is relevant:

  IOW, you don't _ever_ have a reason to sign anything but the "tip".

My interpretation is that it doesn't make sense to sign commits one
through nine if you're going to sign the tenth before pushing. But most
of our commits are small and self-contained so it's probably easier to
automate the signing with repoman than it would be to come up with a
to-sign-or-not-to-sign guide a mile long.

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Andrew Savchenko]

Hi,

On Fri, 3 Jul 2015 11:19:13 -0500 William Hubbs wrote:
> On Fri, Jul 03, 2015 at 06:34:41AM +, Robin H. Johnson wrote:
> > On Thu, Jul 02, 2015 at 09:46:18PM -0400, Brian Evans wrote:
> > > Does this mean that https://wiki.gentoo.org/wiki/Gentoo_git_workflow
> > > is no longer draft or needs work or another document is meant to
> > > display the new flow?
> > It does cover most of the things needed.
> > 
> > It could use some revision regarding gkeys, and I'd like to also mandate
> > signed pushes in addition to signed commits.
> 
> A push doesn't create any data, it just uploads it to the repo, so how
> do you sign a push?

As I see from git docs only commits and tags may be signed. There
is no way to sign a push. Moreover there is no need to sign each
commit, see what Linux says on that:
http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html

''
Btw, there's a final reason, and probably the really real one.
Signing each commit is totally stupid. It just means that you
automate it, and you make the signature worth less. It also doesn't
add any real value, since the way the git DAG-chain of SHA1's work,
you only ever need _one_ signature to make all the commits
reachable from that one be effectively covered by that one. So
signing each commit is simply missing the point.
''

Best regards,
Andrew Savchenko


pgp3IuIWwuwJv.pgp
Description: PGP signature

Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Robin H. Johnson]

(Breaking the thread, because I believe this topic needs further
discussion).

On Fri, Jul 03, 2015 at 03:39:31PM +0200, Manuel Rüger wrote:
> Are there still any plans to use a code review system like gerrit that
> will avoid merges, rebases etc. to the tree by just accepting and
> serializing patches?
Merges are a fact of life, they will be happening.
This was included on:
https://wiki.gentoo.org/wiki/Gentoo_git_workflow

Rebases of already published commits must be avoided.

But beyond that, the general discussion was that a code review system
was not in the immediate future...

If the merge workflow becomes too problematic due to the high rate of
change, then we can revisit those systems, to take advantage of their
auto-merging functionality, but probably only in combination with the QA
testsuites.

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

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Jason Zaman]

On Fri, Jul 03, 2015 at 12:24:42PM -0400, NP-Hardass wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Fri, 3 Jul 2015 11:19:13 -0500
> William Hubbs  wrote:
> 
> > On Fri, Jul 03, 2015 at 06:34:41AM +, Robin H. Johnson wrote:
> > > On Thu, Jul 02, 2015 at 09:46:18PM -0400, Brian Evans wrote:
> > > > Does this mean that
> > > > https://wiki.gentoo.org/wiki/Gentoo_git_workflow is no longer
> > > > draft or needs work or another document is meant to display the
> > > > new flow?
> > > It does cover most of the things needed.
> > > 
> > > It could use some revision regarding gkeys, and I'd like to also
> > > mandate signed pushes in addition to signed commits.
> > 
> > A push doesn't create any data, it just uploads it to the repo, so how
> > do you sign a push?
> > 
> > William
> > 
> 
> Repoman may need to be adjusted. Git commit has support for a "-S"
> flag which signs the commit.

No that is different. There are two signing things involved here.
1) git commit -S. ie sign the commit in the tree, and git log will show
that signature later.

2) git push -S, this is signing the push itself. The client will sign
everything that it pushes to the server. Then the server can verify that
it was pushed by a dev (which is different from the commit since a dev
might be pushing a commit that was made by a user). The server will save
this push certificate so that it can also be verified later on.

We'll want to have both of these on. It may require some repoman changes
but should not be that much.

-- Jason

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 3 Jul 2015 11:19:13 -0500
William Hubbs  wrote:

> On Fri, Jul 03, 2015 at 06:34:41AM +, Robin H. Johnson wrote:
> > On Thu, Jul 02, 2015 at 09:46:18PM -0400, Brian Evans wrote:
> > > Does this mean that
> > > https://wiki.gentoo.org/wiki/Gentoo_git_workflow is no longer
> > > draft or needs work or another document is meant to display the
> > > new flow?
> > It does cover most of the things needed.
> > 
> > It could use some revision regarding gkeys, and I'd like to also
> > mandate signed pushes in addition to signed commits.
> 
> A push doesn't create any data, it just uploads it to the repo, so how
> do you sign a push?
> 
> William
> 

Oh, you said push specifically, instead of commit.  My apologies.  I'm
unaware of a means to do this.  I guess you could theoretically sign
and commit a list of the pushed commit hashes.

- --
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVlrnuAAoJEBzZQR2yrxj73C0P/003J46FmqXNYIk3cVoktvCj
hJ74J9DcAC7ZvqJjAeASdWN83AWlUNFQQeA6eSkmtJXOot7VfrfVw/ZlWReEcq1p
ZMFhUdawTDcfeH5fBx0vJLeLkyWHBIYoMBQchSzQpugEt7X378C1BL4ttrWYpOu1
Z494tvZVvZ9+hN17IT+A3wejsfWkDT2oFECXjZJuZQXR7b3qlUVZJsKAxrpZThBX
ciifiy/84sHRx6fXpU7RtqsYJXLt8dAjppPDH7ci2sh+YjJqL1nj58QZprdlvNc/
R2EupWfphv7sKdN3/yPpT5RWjERKJqYkt15UzZceLEMjhpMxW2b3Rfcz4CE+MXS2
e1/MgvoMoJI7/7x9cg8bykkYa6NmTdQ7nXtqP9s/cADtPho7mllA+FVW7aH8CE46
LG2s0AsIWAV0rR1H+d77O2bhknczlPKgKDEO+sFwy+Y7I/2V37nEkSZR8LqWVmse
RKPmxjimX0iSEUIiaX5LPR48hmkosSvIHkmwO7XIK5NCtIoMOjBXyIenYQi67+fs
PV1+ZgBxWufn1BEDXDQc8TN9IvvRpRvv2O5lKYZ096pLon9ZVB/O0BscGjk7HeL0
JCpZ4fJ6d3o/4xlsmX9n++X1zbdJyMvrHBL6mZa6wcZPMMe1L0w2/zFo8sG8mKpD
Ag/E/1m/6OXzsJCJOAbE
=1FB0
-END PGP SIGNATURE-

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 3 Jul 2015 11:19:13 -0500
William Hubbs  wrote:

> On Fri, Jul 03, 2015 at 06:34:41AM +, Robin H. Johnson wrote:
> > On Thu, Jul 02, 2015 at 09:46:18PM -0400, Brian Evans wrote:
> > > Does this mean that
> > > https://wiki.gentoo.org/wiki/Gentoo_git_workflow is no longer
> > > draft or needs work or another document is meant to display the
> > > new flow?
> > It does cover most of the things needed.
> > 
> > It could use some revision regarding gkeys, and I'd like to also
> > mandate signed pushes in addition to signed commits.
> 
> A push doesn't create any data, it just uploads it to the repo, so how
> do you sign a push?
> 
> William
> 

Repoman may need to be adjusted. Git commit has support for a "-S"
flag which signs the commit.

- --
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVlrdKAAoJEBzZQR2yrxj7XBIP/0rWguE1R0EueAdmI0ApY2Wg
lvkkWkW0P4uJnHri522dvmIeiQ9j/2NFQy5uXCHXE+TQRszog03YwP2xu9lQnoMm
OURcAUDNO1uCSUp+xYH6UDi9K/t19pkncLskNHs774ka6LLZvrnRPeU2MP6q5VuZ
flK479q8LWIfArjh/Qqi5rZ5+0boyTS5SxKjlwIaj4kUd81ph1xNHX3pEJhPL7ZW
sqt9sVmGQa+ucCWJ8zyyhNX3F8cVHQP43BPKMI51SsMo9X5xwqaccWQWoYioBoFM
9W0HwWQ/IsMxIG337KvqmCZXDQ+1CmYqWHV0f3FQScJk9DOxXpmSNBv16s2GuM5p
n0GqL4wNhvQZDIczOaH87/2I5G3L2kFETLiMQ0mY9MKxji5TrCG7Hyy9jV+lhk2V
tJS6HBHhU1wa5sayzNhxPly2W2Kw34hLbBQTscGl6hBK/hwzWrcWtLQoZO0kswWr
OvlD58uDgIxX21sCftdLANTQ9l3zn7kqsFOV0Sb6oykrek+NQpYW6J5mZg3vDO86
4Pc4Cbiqy3D9vVGg5jNlP3J0gT1cN6VFnxaSydx0kSIMUq0OxSayz3Y290U5lieF
ouCu6TaIZRFzzbTC9fyRPLROQmW/1AZOsbN7GLkFKWZ0A+T1zoTqU6zoWQPyHL5N
kwc+xJ1ffAb6Mf745Sh7
=F2sd
-END PGP SIGNATURE-

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[William Hubbs]

On Fri, Jul 03, 2015 at 06:34:41AM +, Robin H. Johnson wrote:
> On Thu, Jul 02, 2015 at 09:46:18PM -0400, Brian Evans wrote:
> > Does this mean that https://wiki.gentoo.org/wiki/Gentoo_git_workflow
> > is no longer draft or needs work or another document is meant to
> > display the new flow?
> It does cover most of the things needed.
> 
> It could use some revision regarding gkeys, and I'd like to also mandate
> signed pushes in addition to signed commits.

A push doesn't create any data, it just uploads it to the repo, so how
do you sign a push?

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Manuel Rüger]

On 02.07.2015 23:39, Robin H. Johnson wrote:
> Hi all,
> 
> The Git migration is moving forward, and I'd like to announce a
> tentative schedule for that end.
> https://wiki.gentoo.org/wiki/Project:Infrastructure/Git_migration#Status
> 
> 2015/08/08 15:00 UTC - Freeze
> 2015/08/08 19:00 UTC - Git commits open for developers
> 2015/08/09 01:00 UTC - Rsync live again (with lagged changelog)
> 2015/08/11   - History repo available to graft
> 2015/08/12   - rsync mirrors carry up-to-date changelogs again
> 
> I've allocated time for an 8 hour freeze, but hope to be completed much
> sooner than that.
> 

Thanks to all who helped to make this possible! :-)

Are there still any plans to use a code review system like gerrit that
will avoid merges, rebases etc. to the tree by just accepting and
serializing patches?

Manuel



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Donnerstag, 2. Juli 2015, 23:39:52 schrieb Robin H. Johnson:
> Hi all,
> 
> The Git migration is moving forward, and I'd like to announce a
> tentative schedule for that end.
> https://wiki.gentoo.org/wiki/Project:Infrastructure/Git_migration#Status
> 
> 2015/08/08 15:00 UTC - Freeze
> 2015/08/08 19:00 UTC - Git commits open for developers
> 2015/08/09 01:00 UTC - Rsync live again (with lagged changelog)
> 2015/08/11   - History repo available to graft
> 2015/08/12   - rsync mirrors carry up-to-date changelogs again
> 
> I've allocated time for an 8 hour freeze, but hope to be completed much
> sooner than that.

That's excellent news- thanks a lot for your work!

- -- 
Andreas K. Huettel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVlntdAAoJEB9VdM6hupKV6y8QAIT9Y7Qn0kTXezAsqs0lVyg2
V/urjQiCa0lVwxTyvTNe3vO075D4nCHSUM0VkR0MsBSESlDBboswMwRcBvUyw0jC
g7v11t9R4yQKC59Tw7aZPkQRaTcWjOkEcICTQKr4pOf0hxLribwIbUHsWDtU4iOs
fQK9XKdPnJNBFm7/j//Nodon6Ruez4Zv6jgYl2zDZbFJJzP0KykfBrH0/NNxwWXr
jRze2B6P279znRhho3sEL6hAnlYFFxzJt8CjVq3k0RfF4rqxQiyOY7EkRzOsjyHd
efj40dvsa9WwZR+hR2B0w8IZrUBlBoV0oUfoXlNlGgWs6hGVEXxG0FxY4uq6W1sL
nok8Ny2MHT8p3Z0FMViy/PfLUD7udcP8qCf93EPYLoqGvZ8+QEz/9hJlmP0FQ9W3
agWmdUnFxA0q3SwAB6nLDxHozfE4bZXKVeXs8Y6gjk1A9MKOc+wo33dGmSAF04d1
vS+s7AqNwQRO9Uq7v2QhaB8T4NSkAM+Xp7X7KmhwaJDeEgM8Xz3bT0p8HP42zCEx
X1mDVrkP+sCfCKrTti3CRdTfa7PgIi2qcnYYmVq7AVZWqqLQAcx+cxnPczsunuBt
xDWIng5wjRHrBFP9/fywzeHfv7EC4x5PQWiovlMBvH9bnKLoPYFxttojY4EzvyBM
UvqcO4hanUVjDxa13RJC
=+TyC
-END PGP SIGNATURE-

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Igor Savlook]

On Friday 03 July 2015 11:08:16 Justin wrote:
> On 03/07/15 10:51, Igor Savlook wrote:
> > On Thursday 02 July 2015 21:39:52 Robin H. Johnson wrote:
> >> Hi all,
> >> 
> >> The Git migration is moving forward, and I'd like to announce a
> >> tentative schedule for that end.
> >> https://wiki.gentoo.org/wiki/Project:Infrastructure/Git_migration#Status
> >> 
> >> 2015/08/08 15:00 UTC - Freeze
> >> 2015/08/08 19:00 UTC - Git commits open for developers
> >> 2015/08/09 01:00 UTC - Rsync live again (with lagged changelog)
> >> 2015/08/11   - History repo available to graft
> >> 2015/08/12   - rsync mirrors carry up-to-date changelogs again
> >> 
> >> I've allocated time for an 8 hour freeze, but hope to be completed much
> >> sooner than that.
> > 
> > So dev-vcs/git now by default in stage3?
> 
> Why that? rsync is and will be the default sync method. We are switching for
> development not the sync clients.
> 
> Justin
Ahhh i see. Thx for info.

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Justin (jlec)]

On 03/07/15 10:51, Igor Savlook wrote:
> On Thursday 02 July 2015 21:39:52 Robin H. Johnson wrote:
>> Hi all,
>>
>> The Git migration is moving forward, and I'd like to announce a
>> tentative schedule for that end.
>> https://wiki.gentoo.org/wiki/Project:Infrastructure/Git_migration#Status
>>
>> 2015/08/08 15:00 UTC - Freeze
>> 2015/08/08 19:00 UTC - Git commits open for developers
>> 2015/08/09 01:00 UTC - Rsync live again (with lagged changelog)
>> 2015/08/11   - History repo available to graft
>> 2015/08/12   - rsync mirrors carry up-to-date changelogs again
>>
>> I've allocated time for an 8 hour freeze, but hope to be completed much
>> sooner than that.
> 
> So dev-vcs/git now by default in stage3?
> 
> 

Why that? rsync is and will be the default sync method. We are switching for
development not the sync clients.

Justin



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Igor Savlook]

On Thursday 02 July 2015 21:39:52 Robin H. Johnson wrote:
> Hi all,
> 
> The Git migration is moving forward, and I'd like to announce a
> tentative schedule for that end.
> https://wiki.gentoo.org/wiki/Project:Infrastructure/Git_migration#Status
> 
> 2015/08/08 15:00 UTC - Freeze
> 2015/08/08 19:00 UTC - Git commits open for developers
> 2015/08/09 01:00 UTC - Rsync live again (with lagged changelog)
> 2015/08/11   - History repo available to graft
> 2015/08/12   - rsync mirrors carry up-to-date changelogs again
> 
> I've allocated time for an 8 hour freeze, but hope to be completed much
> sooner than that.

So dev-vcs/git now by default in stage3?

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Daniel Campbell (zlg)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/02/2015 02:39 PM, Robin H. Johnson wrote:
> Hi all,
> 
> The Git migration is moving forward, and I'd like to announce a 
> tentative schedule for that end. 
> https://wiki.gentoo.org/wiki/Project:Infrastructure/Git_migration#Stat
us
>
>  2015/08/08 15:00 UTC - Freeze 2015/08/08 19:00 UTC - Git commits
> open for developers 2015/08/09 01:00 UTC - Rsync live again (with
> lagged changelog) 2015/08/11   - History repo available to
> graft 2015/08/12   - rsync mirrors carry up-to-date
> changelogs again
> 
> I've allocated time for an 8 hour freeze, but hope to be completed
> much sooner than that.
> 
This is great news! I assume docs have been written for git-commit
standards as well?

- -- 
Daniel Campbell
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVlkrrAAoJEAEkDpRQOeFwxooP/iKN3RvNrITSwvihcIG4B8e8
w7acqsgCfIQTTza9sq+SQ5HXsmVadC+u702RSa5CqfgYw9JXSAdwhPVksGCt0iiL
9WdhVsRm8LE3O8B8gqGZLvG7+8OB19RCsbPN+fy0aQi+R2rtyQItibdpLLfzHw90
qfsw/JdI09ndRLh21gpmJnrC/fgelafQE0o/Z8Sl6akjwl44+dkAtPTDOroev3IF
xDs1FyhSS2gzfAKcrXFoTetdmccUs/rQcCNzB3VeqciwfDvmJvAXtnN50VefpNt0
yID2ud7DDAPDTBH74gZEteARv6abQTqdToCEiczzaDSggiJGD/mS/F4jRgeWTeOP
zgUcNyaLcjXIbb1QoBIEgBQHFXsOaiHegkuoGlNqCTCpffKBblDD38rBq/GBssce
Y4cG8jvmapXKjph0c4BC+1V3p3Slj4AcnKfIk/Rkoc+YeLcGr5VUcOJXNHvJ85ZG
M9c9kEW2X8/cscuRiS5tBMOROzculEAdEOOJZB6RJm2qk+yJ64MaiZVBd7Z6aUIx
QmJvAenWeVZcw9Pz6MSmOCszLMD6MJOWx9tUCSUiiXEd9KoSAeKrXUraZpj76fOV
Qv8jpCUd045RHTWvBqWs9g+ZPvb28rRoDzi5Xu+XU4FiTn9m079LJ5GUZvhsVFHn
exhczY0a0hFXJaExF5R7
=MoQS
-END PGP SIGNATURE-

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Mikle Kolyada]

03.07.2015 00:39, Robin H. Johnson пишет:
> Hi all,
>
> The Git migration is moving forward, and I'd like to announce a
> tentative schedule for that end.
> https://wiki.gentoo.org/wiki/Project:Infrastructure/Git_migration#Status
>
> 2015/08/08 15:00 UTC - Freeze
> 2015/08/08 19:00 UTC - Git commits open for developers
> 2015/08/09 01:00 UTC - Rsync live again (with lagged changelog)
> 2015/08/11   - History repo available to graft
> 2015/08/12   - rsync mirrors carry up-to-date changelogs again
>
> I've allocated time for an 8 hour freeze, but hope to be completed much
> sooner than that.
>
Thanks Robbin and whole the Infrastructure team! Great and i'd even say
historical news!

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Justin (jlec)]

On 02/07/15 23:39, Robin H. Johnson wrote:
> Hi all,
> 
> The Git migration is moving forward, and I'd like to announce a
> tentative schedule for that end.
> https://wiki.gentoo.org/wiki/Project:Infrastructure/Git_migration#Status
> 
> 2015/08/08 15:00 UTC - Freeze
> 2015/08/08 19:00 UTC - Git commits open for developers
> 2015/08/09 01:00 UTC - Rsync live again (with lagged changelog)
> 2015/08/11   - History repo available to graft
> 2015/08/12   - rsync mirrors carry up-to-date changelogs again
> 
> I've allocated time for an 8 hour freeze, but hope to be completed much
> sooner than that.
> 

That's cool, so we are much closer than my latest information was!!!

Thanks for your great work,

Justin



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Robin H. Johnson]

On Thu, Jul 02, 2015 at 09:46:18PM -0400, Brian Evans wrote:
> Does this mean that https://wiki.gentoo.org/wiki/Gentoo_git_workflow
> is no longer draft or needs work or another document is meant to
> display the new flow?
It does cover most of the things needed.

It could use some revision regarding gkeys, and I'd like to also mandate
signed pushes in addition to signed commits.

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

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Brian Evans]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/02/2015 05:39 PM, Robin H. Johnson wrote:
> Hi all,
> 
> The Git migration is moving forward, and I'd like to announce a 
> tentative schedule for that end. 
> https://wiki.gentoo.org/wiki/Project:Infrastructure/Git_migration#Stat
us
>
>  2015/08/08 15:00 UTC - Freeze 2015/08/08 19:00 UTC - Git commits
> open for developers 2015/08/09 01:00 UTC - Rsync live again (with
> lagged changelog) 2015/08/11   - History repo available to
> graft 2015/08/12   - rsync mirrors carry up-to-date
> changelogs again
> 
> I've allocated time for an 8 hour freeze, but hope to be completed
> much sooner than that.
> 

Sounds good.  Thanks to all the hard workers out there.

Does this mean that https://wiki.gentoo.org/wiki/Gentoo_git_workflow
is no longer draft or needs work or another document is meant to
display the new flow?

Brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJVlelqXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NkMyRTQ0RUQ5MEUzMjc1OEU3RDU1QzBE
MUY3ODFFRkY5RjRBM0I2AAoJENH3ge/59KO243gQAJDjnfy15Pq0sBjRbVwEf+fg
9yKUHLMRreB35/mt9ywqX6i/qgm02V1Nzhm0mfA56zZIkg1rAQXIznojH22SQhzy
P24c9zcCKXUTHaar/qOsGXfFqdSxVjAYsNwcurbUm1z0HvcvbmO+CP4AE3paqHXo
xEAO+vQx38oBx+hItcSshXBuPYew/cKUKEwGYaL7U1KsUXwKT0dWM1n3yuxezTOr
bOlzX1EGVlu9VJ9/svEEkxHfzD5GYpuHiDnDfKsdswFzdwaZEqh4jCB9fjPL1ewQ
uLUZLD6kJgaYxVCY7fNUMZXS7qgoeCYHKQw5+tgVxXayb+x6szhH9SJ0f0ZYNInE
85xpE2i10WaAkbVWMsRSzitUaq/DwIwjrQAged/YXsKA9MU4nLD8nVKkQbEbeglU
lpGs5JMOeTOct4G+Og4yZLyxEbi99Zs/kT6g6eAOHEYGzZZuJ4m/gWjAK/vvPtJQ
ebb5IBoeaON+riMgCNT79Bk2eGT+VZnSHA7Uz6MbI8lyt0sCld5cOoM4tnmmLI08
wRAZZjdDNJgCW3NT2hPXPIxCRojudHHHj4NW8rrGPba++m2IW96/Xc0fbDZjQKJR
4Xv4kaRpdQDcw+B5nATdB2sUJXyItTsIzHHCXzbKPmyphURSNQJaHKr2vnsLebBI
uKI4JA2Caw5N/idZaTC7
=hFP9
-END PGP SIGNATURE-

Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[NP-Hardass]

Three cheers!

Glad to see it happening. Thank you to everyone who helped to make this happen.

--
NP-Hardass

On July 2, 2015 5:39:52 PM EDT, "Robin H. Johnson"  wrote:
>Hi all,
>
>The Git migration is moving forward, and I'd like to announce a
>tentative schedule for that end.
>https://wiki.gentoo.org/wiki/Project:Infrastructure/Git_migration#Status
>
>2015/08/08 15:00 UTC - Freeze
>2015/08/08 19:00 UTC - Git commits open for developers
>2015/08/09 01:00 UTC - Rsync live again (with lagged changelog)
>2015/08/11   - History repo available to graft
>2015/08/12   - rsync mirrors carry up-to-date changelogs again
>
>I've allocated time for an 8 hour freeze, but hope to be completed much
>sooner than that.
>
>-- 
>Robin Hugh Johnson
>Gentoo Linux: Developer, Infrastructure Lead
>E-Mail : robb...@gentoo.org
>GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

-- 
NP-Hardass

[gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)

[Robin H. Johnson]

Hi all,

The Git migration is moving forward, and I'd like to announce a
tentative schedule for that end.
https://wiki.gentoo.org/wiki/Project:Infrastructure/Git_migration#Status

2015/08/08 15:00 UTC - Freeze
2015/08/08 19:00 UTC - Git commits open for developers
2015/08/09 01:00 UTC - Rsync live again (with lagged changelog)
2015/08/11   - History repo available to graft
2015/08/12   - rsync mirrors carry up-to-date changelogs again

I've allocated time for an 8 hour freeze, but hope to be completed much
sooner than that.

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


signature.asc
Description: Digital signature

Re: [gentoo-dev] Git migration?

[Matthew Summers]

On Wed, May 4, 2011 at 9:23 AM, Andreas K. Huettel  wrote:
> Am Mittwoch 04 Mai 2011, 00:18:08 schrieb Alec Warner:
>> ask on the gentoo-scm list?
>>
>> -A
>
> I'd say this is of enough general interest, and the relevant people are for 
> sure also subscribed here...
>
> -A
>
> --
> Andreas K. Huettel
> Gentoo Linux developer - kde, sci, arm, tex
> dilfri...@gentoo.org
> http://www.akhuettel.de/
>

Andreas,

While what you say is likely true, what occurs with your request is
fragmentation of the information. That said, I think the majority of
the information you seek is available in the gentoo-scm archives. From
what I know about this, I think the issue is time and the ancillary
utilities, like repoman, that will need to be updated. Beyond that
documentation is required.

See this thread for more info.
http://archives.gentoo.org/gentoo-scm/msg_98932c55ec10fcc5445ab950e62b12dc.xml

I know we are all pretty excited to migrate to git, but there is
little reason to rush something this monumental. It seems far better
to take the time to get it absolutely correct, technically (the best
kind), the first time.

I am certain, in any case, that your interest and involvement in this
effort would be appreciated.

Thanks,
Matthew

-- 
Matthew W. Summers
Gentoo Foundation Inc.

Re: [gentoo-dev] Git migration?

[Andreas K. Huettel]

Am Mittwoch 04 Mai 2011, 00:18:08 schrieb Alec Warner:
> ask on the gentoo-scm list?
> 
> -A

I'd say this is of enough general interest, and the relevant people are for 
sure also subscribed here... 

-A

-- 
Andreas K. Huettel
Gentoo Linux developer - kde, sci, arm, tex
dilfri...@gentoo.org
http://www.akhuettel.de/


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Git migration?

[Alec Warner]

ask on the gentoo-scm list?

-A

On Tue, May 3, 2011 at 2:12 PM, Andreas K. Huettel  wrote:
>
> Hello everyone,
>
> I and maybe also some other people would be interested in the status of the
> infamous "git migration" of the main portage tree... I am just curious, since
> I have not heard much lately- is anything happening there, are we talking
> about months, years or never for getting out of the vcs stone age? :)
>
> I know that there is a tracker bug [1], but that one and its blockers have not
> seen much action lately (or ever). Also, browsing through the blockers, my
> personal impression is that at least several of them are actually
> enhancements, not really requirements...
>
> Any news?
>
> Cheers,
> Andreas
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=333531
>
> --
>
> Andreas K. Huettel
> Gentoo Linux developer
> dilfri...@gentoo.org
> http://www.akhuettel.de/
>
>

[gentoo-dev] Git migration?

[Andreas K. Huettel]

Hello everyone, 

I and maybe also some other people would be interested in the status of the 
infamous "git migration" of the main portage tree... I am just curious, since 
I have not heard much lately- is anything happening there, are we talking 
about months, years or never for getting out of the vcs stone age? :)

I know that there is a tracker bug [1], but that one and its blockers have not 
seen much action lately (or ever). Also, browsing through the blockers, my 
personal impression is that at least several of them are actually 
enhancements, not really requirements...

Any news?

Cheers, 
Andreas

[1] https://bugs.gentoo.org/show_bug.cgi?id=333531

-- 

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



signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Olivier Crête]

On Fri, 2010-06-25 at 13:00 +0400, Peter Volkov wrote:
> В Птн, 25/06/2010 в 14:19 +0530, Arun Raghavan пишет:
> > On 25 June 2010 14:15, Peter Volkov  wrote:
> > > В Чтв, 24/06/2010 в 16:43 -0400, Olivier Crête пишет:
> > [...]
> > >> Or you could review the changes before pushing (since in git these
> > >> operations are separate). And live with the consequences of your
> > >> mistakes!
> > >
> > > No. We are humans and thus mistakes are unavoidable.
> > 
> > He didn't say don't make mistakes. He said, be careful and if mistakes
> > happen, so be it.
> 
> And I disagreed. This is unacceptable since we are talking about credits
> to our users. It's like paying salary to random person and blaming tools
> after that.

You can just make a new commit with just a message saying "Hey, last
time I was wrong, this is from A, not B" if you care enough.

-- 
Olivier Crête
tes...@gentoo.org
Gentoo Developer


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Peter Volkov]

В Птн, 25/06/2010 в 14:19 +0530, Arun Raghavan пишет:
> On 25 June 2010 14:15, Peter Volkov  wrote:
> > В Чтв, 24/06/2010 в 16:43 -0400, Olivier Crête пишет:
> [...]
> >> Or you could review the changes before pushing (since in git these
> >> operations are separate). And live with the consequences of your
> >> mistakes!
> >
> > No. We are humans and thus mistakes are unavoidable.
> 
> He didn't say don't make mistakes. He said, be careful and if mistakes
> happen, so be it.

And I disagreed. This is unacceptable since we are talking about credits
to our users. It's like paying salary to random person and blaming tools
after that.

-- 
Peter.

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Arun Raghavan]

On 25 June 2010 14:15, Peter Volkov  wrote:
> В Чтв, 24/06/2010 в 16:43 -0400, Olivier Crête пишет:
[...]
>> Or you could review the changes before pushing (since in git these
>> operations are separate). And live with the consequences of your
>> mistakes!
>
> No. We are humans and thus mistakes are unavoidable.

He didn't say don't make mistakes. He said, be careful and if mistakes
happen, so be it.
-- 
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Peter Volkov]

В Чтв, 24/06/2010 в 16:43 -0400, Olivier Crête пишет:
> On Thu, 2010-06-24 at 20:59 +0200, Luca Barbato wrote:
> > On 04/13/2010 01:25 PM, Peter Volkov wrote:
> > > В Втр, 06/04/2010 в 07:43 +0530, Nirbheek Chauhan пишет:
> > >> * It makes zero sense to manually manage ChangeLogs in git[1]
> > > 
> > > Once I had stupid cut&paste mistake and entered wrong credits in
> > > ChangeLog. I don't see how to resolve this issue in case ChangeLog's
> > > will be generated from git log and until somebody suggests how to edit
> > > ChangeLogs generated from git I think have to keep ChangeLogs in
> > > gentoo-x86.
> > 
> > We could abuse git-note

May be. I found this mail: http://lists.zerezo.com/git/msg623699.html
Was the problem resolved?

> Or you could review the changes before pushing (since in git these
> operations are separate). And live with the consequences of your
> mistakes!

No. We are humans and thus mistakes are unavoidable.

-- 
Peter.

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Olivier Crête]

On Thu, 2010-06-24 at 20:59 +0200, Luca Barbato wrote:
> On 04/13/2010 01:25 PM, Peter Volkov wrote:
> > В Втр, 06/04/2010 в 07:43 +0530, Nirbheek Chauhan пишет:
> >> * It makes zero sense to manually manage ChangeLogs in git[1]
> > 
> > Once I had stupid cut&paste mistake and entered wrong credits in
> > ChangeLog. I don't see how to resolve this issue in case ChangeLog's
> > will be generated from git log and until somebody suggests how to edit
> > ChangeLogs generated from git I think have to keep ChangeLogs in
> > gentoo-x86.
> > 
> 
> We could abuse git-note

Or you could review the changes before pushing (since in git these
operations are separate). And live with the consequences of your
mistakes!

-- 
Olivier Crête
tes...@gentoo.org
Gentoo Developer


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Luca Barbato]

On 04/13/2010 01:25 PM, Peter Volkov wrote:
> В Втр, 06/04/2010 в 07:43 +0530, Nirbheek Chauhan пишет:
>> * It makes zero sense to manually manage ChangeLogs in git[1]
> 
> Once I had stupid cut&paste mistake and entered wrong credits in
> ChangeLog. I don't see how to resolve this issue in case ChangeLog's
> will be generated from git log and until somebody suggests how to edit
> ChangeLogs generated from git I think have to keep ChangeLogs in
> gentoo-x86.
> 

We could abuse git-note

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero