Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests

2020-05-27 Thread Matt Turner
On Wed, May 27, 2020 at 1:14 AM Alec Warner  wrote:
> On Tue, May 26, 2020, 23:08 Michał Górny  wrote:
>>
>> On Tue, 2020-05-26 at 20:24 -0700, Alec Warner wrote:
>> > The TL;DR is that a crack team of infra-folks[0] have been putting together
>> > demos of CI services and things like gitlab / gitea / gerrit and so on.
>> >
>> > Some of these come in combined (e.g. gitlab offers repo hosting, code
>> > review / pull reqs, CI services, and deploy services.) Some of these are
>> > piecemeal (e.g. gerrit has code review, zuul has CI) and gitea offers
>> > repo-hosting but CI is separate (e.g. drone.)
>> >
>> > On the infra-side, I think we are pretty happy with repo-hosting (gitolite)
>> > and repo-serving (gitweb). We are missing a CI piece and a pull-request
>> > piece. Most of the users using PRs use either a gitlab or github mirror.
>> >
>> > I think the value of CI is pretty obvious to me (and I see tons of use
>> > cases in Infra.) We could easily build CI into our current repository
>> > solution (e.g. gitolite.) However gitolite doesn't really support PRs in a
>> > uniform way and so CI is mostly for submitted code; similar to the existing
>> > ::gentoo repo CI offered by mgorny.
>> >
>> > If we build a code review solution (like gitea / gerrit) would people use
>> > it? Would you use it if you couldn't merge (because the code review
>> > solution can't gpg sign your commits or merges) so a tool like the existing
>> > pram tool would be needed to merge?
>> >
>>
>> Does GitLab count?  Gerrit is just PITA.  I think we had some concerns
>> about Gitea, so I'd like to test it before deciding.  GitLab OTOH works
>> just fine for a lot of projects, and seems the next best thing after
>> GitHub
>
>
> Gitlab does count (we deployed and tested an onprem version.) I think there 
> are some major issues with it though.
>  - Licensing. Gitlab-CE is available, gitlab-EE is not OSS nor OSI approved 
> and many of the features we need are EE only and are not available in CE.

It's very surprising to me that CE wouldn't work for our purposes.
Debian, GNOME, KDE, XFCE, and FreeDesktop have all switched to GitLab
and are using CE. It's hard to believe that Gentoo's usage or
requirements would be so different as to make GitLab a non-viable
option.

What features of EE do you think we need?



Re: [gentoo-dev] Packages up for grabs

2020-05-27 Thread Christopher Head
On Wed, 27 May 2020 11:38:39 +0200
Nils Freydank  wrote:

> Zoltan, I prepared a branch with khard plus metadata.xml and would
> like to ask you to merge it into your PR as you took deps of khard:
> 
> https://github.com/holgersson32644/gentoo/tree/bump-khard

Hi Nils,
I already had a PR[1] open for the version bump and Python 3.7 support.
I’m happy for you to take over if you like; mine is waiting for review.
Just thought you ought to know in case you get merge conflicts later
on, or want to take any bits of my changes.

[1] https://github.com/gentoo/gentoo/pull/15783
-- 
Christopher Head


pgp9AYxcdnXhY.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs

2020-05-27 Thread Brian Dolbec
On Wed, 27 May 2020 17:39:21 +0200
Piotr Karbowski  wrote:

> Hi,
> 
> On 27/05/2020 01.31, Brian Dolbec wrote:
> > * dev-python/boto3
> > * dev-python/botocore  
> 
> Do you mind if I join you on those? I use them a lot, and I planned to
> comaintain awscli since Patrick is the only one current maintainer of
> those, boto3 is vital part of it too.
> 
> -- Piotr.
> 

Yes, by all means join in :)



Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/

2020-05-27 Thread Alexis Ballier
On Tue, 26 May 2020 23:41:28 +0200
zo...@gentoo.org wrote:

> tisdag 26 maj 2020 kl. 19:54:51 CEST skrev  Alexis Ballier:
> > On Tue, 26 May 2020 10:45:39 -0400
> > 
> > Mike Gilbert  wrote:
> > > > Note that having the 'pic' useflag should be considered
> > > > something to be fixed: rewrite the asm in a PIC way. But these
> > > > days nobody has the will to do it since this is mostly an issue
> > > > on x86+pax, both being slowly decreasing.
> > > 
> > > Given that PaX has been stripped out of official Gentoo kernels
> > > due to the grsecurity licensing issue, I wonder if there is any
> > > other good reason to keep the "pic" USE flag today. Surely this
> > > affects a very small population of users.
> > 
> > Yeah that was my thought when I saw pax/grsec beginning to be more
> > hostile to open source. That's not my call but the hardened team's,
> > however I'm all for removing these workarounds entirely if there's
> > no point in having them anymore.
> Is not only PaX/Grsec that don't allow textrel. SELinux do it to and
> that is manline kernel.


k so that means there's no dropping the pic useflag then i guess



Re: [gentoo-dev] Packages up for grabs

2020-05-27 Thread Piotr Karbowski
Hi,

On 27/05/2020 01.31, Brian Dolbec wrote:
> * dev-python/boto3
> * dev-python/botocore

Do you mind if I join you on those? I use them a lot, and I planned to
comaintain awscli since Patrick is the only one current maintainer of
those, boto3 is vital part of it too.

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests

2020-05-27 Thread Alec Warner
On Wed, May 27, 2020 at 5:16 AM Thomas Deutschmann 
wrote:

> Hi,
>
> is this really CI _vs_ Code Review? I.e. we can only have one?
>

I'll try to come back to this. We can make computers do anything, but it's
a question of limited time for me and for Gentoo as a whole.


>
> CI is nice and helpful. For example I usually don't start review until CI
> sets green light but CI alone wouldn't be enough. Thought that Gitlab will
> support same kind of hooks similar to how current CI is integrated into
> Github, not?
>

So I'm basically back to worrying about social contract here. If its a
common Gentoo workflow to:
 - Have a user fork a repo (github)
 - Submit a PR (github)
 - Gentoo CI sees the PR against ::gentoo and runs CI (github)
 - CI turns green and comments on the PR (github)
 - Human Gentoo dev reviews PR (github) [some iterations of review and
changes with PR author]
 - Human Gentoo dev downloads PR patch and applies to Gentoo (Gentoo
Hosted.)

Does this workflow meet the social contract? I would assert it does not.
Now of course Gentoo doesn't "solely rely" on this workflow and other
workflows are available; but if this is a de-facto workflow people are
using...does not that concern the community?  It concerns me! Hey we
originally were like 'nah github is OK' and now I'm coming around and
saying 'hey maybe this isn't OK in its current form.' So one idea might be
"what can we do about this particular problem."

What others have done is typically left mirrors of their projects on
github, written bots to auto-close PRs to those repos, and funneled users
somewhere else. We could do that if we wanted.


>
> Also, when I could wish something: The problem when doing review on Github
> for me is, that we usually create new revisions. Therefore we don't see
> what's changed in new revision versus previous revision. So the change to
> review looks like an entire new file was added (which is what basically
> happened). It would be cool if our solution would be aware of this and
> could handle this somehow. But I guess we would have to create our own
> solution for this...
>

So to address your first point above, there are a bunch of (sometimes
conflicting) requirements.

[Github]
A past argument for Github was "we need to be on github because this is
where the users are." I can tell you the users have not left Github and so
without us funneling them somewhere else...I mean if we are going to
continue to accept PRs on github we should probably service them (vs
auto-closing.)

[Code Review]
Basically how do we build a system where a user can go find our code, fork
it, generate a patch, send us the patch, and then be able to run CI on it
and do a review online (as opposed to on bugzilla / in-email.) Currently
this happens on github and I think there is some support for moving those
users to some other solution.

We could:
 - Build something on gitlab CE.
 - Build something on gitea + a CI solution (drone, zuul, etc.)
 - I don't think gerrit credibly meets these requirements because users
can't fork in gerrit and it requires annoying client side tooling.
 - The main problem I think with gitlab-CE is no one wants to operate it;
its too complex of a software package and there is a major fear that once
we mgirate everyone on it, something will go wrong and then we will be in
trouble. I don't have this fear with gitea because there are fewer moving
parts.
 - The main problem with gitea is that it's relatively unproven and we
already know it needs patches for ::gentoo.

[CI-for-ebuilds]
My understanding is that there are two existing CI workflows (I'm ignoring
the new thing nattka; it's what I'd consider a different workflow.)
(1) Github PRs: A bot watches for PRs against ::gentoo on Github and runs
CI on them.
(2) Post-Submit CI: Every so often we run Ci against ::gentoo and if
something looks super bad we bisect and email that the build is broken.

So right off the bat there are some gaps.
 - There is no pre-submit CI on git.gentoo.org at all, so devs can't vet
their changes there. Would anyone like this?
 - There is no flexibility; the CI you get is whatever is configured (e.g.
what mgorny set up). This isn't meant as a dig; maybe no one wants to set
up CI at all and just wants to use this stuff; I have no idea.

[Other Projects]
Portage has had CI for ages; but it runs on github and uses travis-CI
soko.git uses hosted gitlab-ci to build, run tests, and upload containers.
https://gitweb.gentoo.org/proj/catalyst.git/ has no CI, but might like some?
https://gitweb.gentoo.org/proj/gentoo-mirrorstats.git/
 has no CI but
might like some?
https://gitweb.gentoo.org/proj/sandbox.git/ has no CI but might want some?
I could go on.

So to kind of summarize. If I wanted to just do [CI for other projects] we
could likely just build that now and not need to talk to most of the
community because the CI for other projects is fairly segmented. It's the
part that 

Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests

2020-05-27 Thread Louis Sautier
On 27/05/2020 15:22, Guilherme Amadio wrote:
> Hi,
> 
> On Wed, May 27, 2020 at 02:45:29PM +0200, Toralf Förster wrote:
>> On 5/27/20 2:16 PM, Thomas Deutschmann wrote:
>>> The problem when doing review on Github
>>> for me is, that we usually create new revisions. Therefore we don't see
>>> what's changed in new revision versus previous revision. 
>> That's my main concern with the current behaviour: a "git diff" often 
>> doesn't show a diff against the previous (ebuild) file, it shows a diff 
>> against /dev/null :-/
> 
> Indeed, on GitHub it is hard to review, but locally you can add
> 
> [diff]
> algorithm = patience
> 
> to your .gitconfig, and that should help with the diffs even when
> the revision changes by moving the file. When copying, it probably
> won't help.
> 
> We could also try as a policy to split the revision bump from the
> changes, i.e. bump the revision in the first commit, then apply the
> changes in a second one. That way, one can click on the right commit
> to see the differences only, even on GitHub. Then we can squash when
> merging locally, since we don't click merge on GitHub anyway.
> 
> Cheers,
> -Guilherme
>
Hi,

That looks like it could lead to errors when merging if the committer
forgets to squash the two commits.

Whether it is on GitHub or another platform, it is probably possible to
have a bot compute the diff with the previous version every time a
commit is pushed to a PR and add that as a comment.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests

2020-05-27 Thread Guilherme Amadio
Hi,

On Wed, May 27, 2020 at 02:45:29PM +0200, Toralf Förster wrote:
> On 5/27/20 2:16 PM, Thomas Deutschmann wrote:
> > The problem when doing review on Github
> > for me is, that we usually create new revisions. Therefore we don't see
> > what's changed in new revision versus previous revision. 
> That's my main concern with the current behaviour: a "git diff" often doesn't 
> show a diff against the previous (ebuild) file, it shows a diff against 
> /dev/null :-/

Indeed, on GitHub it is hard to review, but locally you can add

[diff]
algorithm = patience

to your .gitconfig, and that should help with the diffs even when
the revision changes by moving the file. When copying, it probably
won't help.

We could also try as a policy to split the revision bump from the
changes, i.e. bump the revision in the first commit, then apply the
changes in a second one. That way, one can click on the right commit
to see the differences only, even on GitHub. Then we can squash when
merging locally, since we don't click merge on GitHub anyway.

Cheers,
-Guilherme



Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests

2020-05-27 Thread Toralf Förster
On 5/27/20 2:16 PM, Thomas Deutschmann wrote:
> The problem when doing review on Github
> for me is, that we usually create new revisions. Therefore we don't see
> what's changed in new revision versus previous revision. 
That's my main concern with the current behaviour: a "git diff" often doesn't 
show a diff against the previous (ebuild) file, it shows a diff against 
/dev/null :-/

-- 
Toralf
PGP 23217DA7 9B888F45



signature.asc
Description: OpenPGP digital signature


RE: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests

2020-05-27 Thread Thomas Deutschmann
Hi,

is this really CI _vs_ Code Review? I.e. we can only have one?

CI is nice and helpful. For example I usually don't start review until CI
sets green light but CI alone wouldn't be enough. Thought that Gitlab will
support same kind of hooks similar to how current CI is integrated into
Github, not?

Also, when I could wish something: The problem when doing review on Github
for me is, that we usually create new revisions. Therefore we don't see
what's changed in new revision versus previous revision. So the change to
review looks like an entire new file was added (which is what basically
happened). It would be cool if our solution would be aware of this and
could handle this somehow. But I guess we would have to create our own
solution for this...


-- 
Regards, 
Thomas Deutschmann / Gentoo Linux Developer 
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


openpgp-digital-signature.asc
Description: PGP signature


Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests

2020-05-27 Thread Andreas K . Hüttel
> Works great for whom?  How many deployments are we talking about?  To be
> honest, I don't think I've stumbled upon a single instance.
> On the other hand, GitLab deployments are pretty common -- GNOME, Xfce,
> Debian come instantly to my mind.  Then, there's Heptapod -- the GitLab
> fork for Mercurial.

KDE also just migrated to GitLab.

> 
> > Gerrit is widely used for large projects and I'm not worried for ::gentoo
> > and we have deployed gerrit and it seems to work fine. Gerrit doesn't have
> > CI (we would need to deploy something) and it uses gitweb for repository
> > browsing (which we use today.)
> 
> Not to mention it's ugly and I found it cumbersome to use.

Everytime I tried to use Gerrit I got so thouroughly confused that I gave up 
after a while.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

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


Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/

2020-05-27 Thread Alexis Ballier
On Tue, 2020-05-26 at 14:14 -0400, Mike Gilbert wrote:
[...]
> 
> > 
> > Assuming that the pic performance penalty is really only relevant
> > on
> > legacy arches (like x86), here are a couple of options:
> > 
> > 1. Disable pic on arches where tie performance penalty is small.
> > 2. Force pic everywhere, performance be damned.
> 
> Option 1 should say "Disable pic on arches where the performance
> penalty is large."

Performance penalty is not really a matter of arch. Of course -fPIC
from C/C++ code has a small performance impact on x86 (bigger than on
amd64), but the gain is worth it. Here it is a matter of hand written
assembly that is not relocatable. The performance impact thus depends
on the gain of said assembly, which in the case of multimedia apps/libs
is huge because that's usually about vectorizing inner loops bodys
(somewhere between x4 or x8 speedups is not unusual for the part in
question).

That's why the policy has always been to have PIC everywhere with
exceptions/workarounds tied to the pic useflag, giving users and
profiles the choice.

Again, the real fix is to rewrite the assembly in a PIC way, or at
least have ifdefs to allow it, but that is hard. Packages that have the
option to have PIC or slightly faster non-PIC assembly do/should not
have a pic useflag and always use the PIC variant.




Re: [gentoo-dev] Packages up for grabs

2020-05-27 Thread Nils Freydank
Hi,

I can add my already bumped app-misc/khard and start to co-maintain it via
p.m. project.

Am Mittwoch, den 27.05.2020 um 06:00:18 Uhr +0200 schrieb Zoltan Puskas 
:
> [...]
> I'm happy to take dev-python/ruamel-yaml and dev-python/ruamel-yaml-clib 
> either
> as a solo or as a comaintainer. I'll put up a PR later adding myself to the
> metadata as a proxy maintainer. Feel free to keep or remove yourself
> after that.

Zoltan, I prepared a branch with khard plus metadata.xml and would like to ask
you to merge it into your PR as you took deps of khard:

https://github.com/holgersson32644/gentoo/tree/bump-khard

regards,
Nils


signature.asc
Description: PGP signature


Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests

2020-05-27 Thread Alec Warner
On Wed, May 27, 2020 at 1:09 AM Brian Dolbec  wrote:

> On Tue, 26 May 2020 20:24:56 -0700
> Alec Warner  wrote:
>
> > The TL;DR is that a crack team of infra-folks[0] have been putting
> > together demos of CI services and things like gitlab / gitea / gerrit
> > and so on.
> >
> > Some of these come in combined (e.g. gitlab offers repo hosting, code
> > review / pull reqs, CI services, and deploy services.) Some of these
> > are piecemeal (e.g. gerrit has code review, zuul has CI) and gitea
> > offers repo-hosting but CI is separate (e.g. drone.)
> >
> > On the infra-side, I think we are pretty happy with repo-hosting
> > (gitolite) and repo-serving (gitweb). We are missing a CI piece and a
> > pull-request piece. Most of the users using PRs use either a gitlab
> > or github mirror.
> >
> > I think the value of CI is pretty obvious to me (and I see tons of use
> > cases in Infra.) We could easily build CI into our current repository
> > solution (e.g. gitolite.) However gitolite doesn't really support PRs
> > in a uniform way and so CI is mostly for submitted code; similar to
> > the existing ::gentoo repo CI offered by mgorny.
> >
> > If we build a code review solution (like gitea / gerrit) would people
> > use it? Would you use it if you couldn't merge (because the code
> > review solution can't gpg sign your commits or merges) so a tool like
> > the existing pram tool would be needed to merge?
> >
> > -A
> >
> > [0] Mostly arzano, if I'm honest. I am just the point-y haired
> > manager in this effort.
>
> There are several CI systems that could be used.  As for CI, my
> experience has been with buildbot.  It would be fairly straightforward
> to integrate with the current gitolite/gitweb hosting.
> It is also extremely flexible in its capabilities, although can be
> difficult to master.  It has a good web interface, but it can even be
> run via it's API's using curses, python, bash,   There is a
> buildbot-travis plugin which is capable of running existing .travis file
> configurations.  It also extends its capabilities to include custom
> buildbot step definitions.  I have not packaged it yet for gentoo, but
> it is on my todo list. One of buildbot's capabilities is the ability to
> run tests/builds on multiple workers (different arches or whatever)
> both in parallel or series.  It could be made to integrate with our
> bugzilla using the python client (pybugs was it?).
>

My understanding is that CI systems are all quite similar. We have
configured gitlab-ci, drone, and zuul as tests and I am familiar with
travis-ci and buildbot from other projects. I'm less concerned about this
aspect tbh. I'm also not super concerned about packaging. E.g. for
gitlab-runner (the worker portion of gitlab-ci) we just deploy upstream
containers and don't package them in ::gentoo at all. Our onprem gitlab is
a container solution; gitea is a container solution; our SSO IDP is a
container solution; gerrit is currently a container solution. These don't
bother me (too much, ugh zuul uses zookeeper? ugh.)

The major differentiators for CI appear to be:
 - SCM support (we currently only really care about git compatible systems,
but some contenders only support some providers.)
 - builders / workers (how do they deploy). For example gitlab has a
container based work executor while zuul uses ansible; I suspect
 - Authentication (ideally should support SAML or openID so we can
integrate with our alpha sso solution for Gentoo.)
 - The webUI; e.g is the solution horrible to use / interact with. Hard to
say without a trial, IMHO.

-A


>
> But that still leaves a PR/code review option.
>
>


Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests

2020-05-27 Thread Michał Górny
On Wed, 2020-05-27 at 01:14 -0700, Alec Warner wrote:
> On Tue, May 26, 2020, 23:08 Michał Górny  wrote:
> 
> > On Tue, 2020-05-26 at 20:24 -0700, Alec Warner wrote:
> > > The TL;DR is that a crack team of infra-folks[0] have been putting
> > together
> > > demos of CI services and things like gitlab / gitea / gerrit and so on.
> > > 
> > > Some of these come in combined (e.g. gitlab offers repo hosting, code
> > > review / pull reqs, CI services, and deploy services.) Some of these are
> > > piecemeal (e.g. gerrit has code review, zuul has CI) and gitea offers
> > > repo-hosting but CI is separate (e.g. drone.)
> > > 
> > > On the infra-side, I think we are pretty happy with repo-hosting
> > (gitolite)
> > > and repo-serving (gitweb). We are missing a CI piece and a pull-request
> > > piece. Most of the users using PRs use either a gitlab or github mirror.
> > > 
> > > I think the value of CI is pretty obvious to me (and I see tons of use
> > > cases in Infra.) We could easily build CI into our current repository
> > > solution (e.g. gitolite.) However gitolite doesn't really support PRs in
> > a
> > > uniform way and so CI is mostly for submitted code; similar to the
> > existing
> > > ::gentoo repo CI offered by mgorny.
> > > 
> > > If we build a code review solution (like gitea / gerrit) would people use
> > > it? Would you use it if you couldn't merge (because the code review
> > > solution can't gpg sign your commits or merges) so a tool like the
> > existing
> > > pram tool would be needed to merge?
> > > 
> > 
> > Does GitLab count?  Gerrit is just PITA.  I think we had some concerns
> > about Gitea, so I'd like to test it before deciding.  GitLab OTOH works
> > just fine for a lot of projects, and seems the next best thing after
> > GitHub
> 
> Gitlab does count (we deployed and tested an onprem version.) I think there
> are some major issues with it though.
>  - Licensing. Gitlab-CE is available, gitlab-EE is not OSS nor OSI approved
> and many of the features we need are EE only and are not available in CE.

What are these features, and why do you believe we need them?

>  - Complex: Gitlab is a giant piece of software with maybe 8-12 components
> (unicorn, postgres, redis, memcache, sidekiq, puma, workhouse, gitaly,
> grafana, sshd,nginx, prometheus ..the list goes on)

Is gitea any better?

>  - I think gitlab ships with more features than we will use (CD, docker
> registry, issues / bugs, wiki, analytics, snippets, milestones, repo
> hosting, repo browsing, ... Again the list goes on.) I don't play to
> migrate away from bugs.gentoo.org nor wiki.gentoo.org, nor gitolite. I
> think if we did; then gitlab would be a more compelling option because it
> is a one-stop-shop solution for those use cases.

I don't think there is any requirement to use all of them.  Furthermore,
I think some of them may actually be helpful -- say, some Gentoo-
specific projects could use GitLab issue tracker over creating more
Bugzilla components.

> My understanding of gitea is that it works great for not-::gentoo, but
> ::gentoo and gitea don't work well and it would require work upstream to
> fix; other large repos seemed to work OK in gitea (based on our test
> deployment and conversations with gitea upstream.)

Works great for whom?  How many deployments are we talking about?  To be
honest, I don't think I've stumbled upon a single instance.
On the other hand, GitLab deployments are pretty common -- GNOME, Xfce,
Debian come instantly to my mind.  Then, there's Heptapod -- the GitLab
fork for Mercurial.

> Gerrit is widely used for large projects and I'm not worried for ::gentoo
> and we have deployed gerrit and it seems to work fine. Gerrit doesn't have
> CI (we would need to deploy something) and it uses gitweb for repository
> browsing (which we use today.)
> 

Not to mention it's ugly and I found it cumbersome to use.

-- 
Best regards,
Michał Górny



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


Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests

2020-05-27 Thread Alec Warner
On Tue, May 26, 2020, 23:08 Michał Górny  wrote:

> On Tue, 2020-05-26 at 20:24 -0700, Alec Warner wrote:
> > The TL;DR is that a crack team of infra-folks[0] have been putting
> together
> > demos of CI services and things like gitlab / gitea / gerrit and so on.
> >
> > Some of these come in combined (e.g. gitlab offers repo hosting, code
> > review / pull reqs, CI services, and deploy services.) Some of these are
> > piecemeal (e.g. gerrit has code review, zuul has CI) and gitea offers
> > repo-hosting but CI is separate (e.g. drone.)
> >
> > On the infra-side, I think we are pretty happy with repo-hosting
> (gitolite)
> > and repo-serving (gitweb). We are missing a CI piece and a pull-request
> > piece. Most of the users using PRs use either a gitlab or github mirror.
> >
> > I think the value of CI is pretty obvious to me (and I see tons of use
> > cases in Infra.) We could easily build CI into our current repository
> > solution (e.g. gitolite.) However gitolite doesn't really support PRs in
> a
> > uniform way and so CI is mostly for submitted code; similar to the
> existing
> > ::gentoo repo CI offered by mgorny.
> >
> > If we build a code review solution (like gitea / gerrit) would people use
> > it? Would you use it if you couldn't merge (because the code review
> > solution can't gpg sign your commits or merges) so a tool like the
> existing
> > pram tool would be needed to merge?
> >
>
> Does GitLab count?  Gerrit is just PITA.  I think we had some concerns
> about Gitea, so I'd like to test it before deciding.  GitLab OTOH works
> just fine for a lot of projects, and seems the next best thing after
> GitHub


Gitlab does count (we deployed and tested an onprem version.) I think there
are some major issues with it though.
 - Licensing. Gitlab-CE is available, gitlab-EE is not OSS nor OSI approved
and many of the features we need are EE only and are not available in CE.
 - Complex: Gitlab is a giant piece of software with maybe 8-12 components
(unicorn, postgres, redis, memcache, sidekiq, puma, workhouse, gitaly,
grafana, sshd,nginx, prometheus ..the list goes on)
 - I think gitlab ships with more features than we will use (CD, docker
registry, issues / bugs, wiki, analytics, snippets, milestones, repo
hosting, repo browsing, ... Again the list goes on.) I don't play to
migrate away from bugs.gentoo.org nor wiki.gentoo.org, nor gitolite. I
think if we did; then gitlab would be a more compelling option because it
is a one-stop-shop solution for those use cases.

My understanding of gitea is that it works great for not-::gentoo, but
::gentoo and gitea don't work well and it would require work upstream to
fix; other large repos seemed to work OK in gitea (based on our test
deployment and conversations with gitea upstream.)

Gerrit is widely used for large projects and I'm not worried for ::gentoo
and we have deployed gerrit and it seems to work fine. Gerrit doesn't have
CI (we would need to deploy something) and it uses gitweb for repository
browsing (which we use today.)

-A


>
> --
> Best regards,
> Michał Górny
>
>


Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests

2020-05-27 Thread Brian Dolbec
On Tue, 26 May 2020 20:24:56 -0700
Alec Warner  wrote:

> The TL;DR is that a crack team of infra-folks[0] have been putting
> together demos of CI services and things like gitlab / gitea / gerrit
> and so on.
> 
> Some of these come in combined (e.g. gitlab offers repo hosting, code
> review / pull reqs, CI services, and deploy services.) Some of these
> are piecemeal (e.g. gerrit has code review, zuul has CI) and gitea
> offers repo-hosting but CI is separate (e.g. drone.)
> 
> On the infra-side, I think we are pretty happy with repo-hosting
> (gitolite) and repo-serving (gitweb). We are missing a CI piece and a
> pull-request piece. Most of the users using PRs use either a gitlab
> or github mirror.
> 
> I think the value of CI is pretty obvious to me (and I see tons of use
> cases in Infra.) We could easily build CI into our current repository
> solution (e.g. gitolite.) However gitolite doesn't really support PRs
> in a uniform way and so CI is mostly for submitted code; similar to
> the existing ::gentoo repo CI offered by mgorny.
> 
> If we build a code review solution (like gitea / gerrit) would people
> use it? Would you use it if you couldn't merge (because the code
> review solution can't gpg sign your commits or merges) so a tool like
> the existing pram tool would be needed to merge?
> 
> -A
> 
> [0] Mostly arzano, if I'm honest. I am just the point-y haired
> manager in this effort.

There are several CI systems that could be used.  As for CI, my
experience has been with buildbot.  It would be fairly straightforward
to integrate with the current gitolite/gitweb hosting.
It is also extremely flexible in its capabilities, although can be
difficult to master.  It has a good web interface, but it can even be
run via it's API's using curses, python, bash,   There is a
buildbot-travis plugin which is capable of running existing .travis file
configurations.  It also extends its capabilities to include custom
buildbot step definitions.  I have not packaged it yet for gentoo, but
it is on my todo list. One of buildbot's capabilities is the ability to
run tests/builds on multiple workers (different arches or whatever)
both in parallel or series.  It could be made to integrate with our
bugzilla using the python client (pybugs was it?).

But that still leaves a PR/code review option.



Re: [gentoo-dev] Packages up for grabs

2020-05-27 Thread Zoltan Puskas
Hey,

> I have transitioned to "away" state as I have to reclaim my time for other
> uses. Here I am trying to reduce the scope of my Gentoo responsibilities to
> make potential return to activity less dreadful and overwhelming.
>
> ...
> 
> Call for co-maintainers or successors
> =
> 
> For these I have some minor use. You can expect me to have some interest 
> revived.
> Still, taking responsibility for them in my absence is highly appreciated.
> 
> * dev-python/ruamel-std-pathlib
> * dev-python/ruamel-yaml-clib
> * dev-python/ruamel-yaml

I'm happy to take dev-python/ruamel-yaml and dev-python/ruamel-yaml-clib either
as a solo or as a comaintainer. I'll put up a PR later adding myself to the
metadata as a proxy maintainer. Feel free to keep or remove yourself
after that.

Cheers,
Zoltan


signature.asc
Description: PGP signature


Re: [gentoo-dev] Packages up for grabs

2020-05-27 Thread Alarig Le Lay
Hi,

On Tue 26 May 2020 23:12:06 GMT, Andrey Utkin wrote:
> WIFI access point service:
> 
> * net-wireless/hostapd
> (Co-maintained by zerochaos, still additional attention is encouraged.)

I can take it.

Regards,
-- 
Alarig



Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests

2020-05-27 Thread Michał Górny
On Tue, 2020-05-26 at 20:24 -0700, Alec Warner wrote:
> The TL;DR is that a crack team of infra-folks[0] have been putting together
> demos of CI services and things like gitlab / gitea / gerrit and so on.
> 
> Some of these come in combined (e.g. gitlab offers repo hosting, code
> review / pull reqs, CI services, and deploy services.) Some of these are
> piecemeal (e.g. gerrit has code review, zuul has CI) and gitea offers
> repo-hosting but CI is separate (e.g. drone.)
> 
> On the infra-side, I think we are pretty happy with repo-hosting (gitolite)
> and repo-serving (gitweb). We are missing a CI piece and a pull-request
> piece. Most of the users using PRs use either a gitlab or github mirror.
> 
> I think the value of CI is pretty obvious to me (and I see tons of use
> cases in Infra.) We could easily build CI into our current repository
> solution (e.g. gitolite.) However gitolite doesn't really support PRs in a
> uniform way and so CI is mostly for submitted code; similar to the existing
> ::gentoo repo CI offered by mgorny.
> 
> If we build a code review solution (like gitea / gerrit) would people use
> it? Would you use it if you couldn't merge (because the code review
> solution can't gpg sign your commits or merges) so a tool like the existing
> pram tool would be needed to merge?
> 

Does GitLab count?  Gerrit is just PITA.  I think we had some concerns
about Gitea, so I'd like to test it before deciding.  GitLab OTOH works
just fine for a lot of projects, and seems the next best thing after
GitHub.

-- 
Best regards,
Michał Górny



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