Review/daniel farrell/13709 #2
Conversation
Allow URLs to be longer than 79 chars in docs with an exception to Coala linting config. Also ignore the docs build directory for all Coala linting. Also reorder Coala ignores to group git, test and editor rules. Change-Id: I891a8ccb4f717b5f2dd78aa4a9a932e031e3dd1f Signed-off-by: Daniel Farrell <dfarrell@redhat.com>
Add docs to collect LFN initiatives suggestions. Bootstrap with suggestions related to CII Badging, cross-project security, cross-project CI/CD, and identifying quality tooling. Change-Id: Ie2ffb6ed42b092293576f71561383b3c785c7fec Signed-off-by: Daniel Farrell <dfarrell@redhat.com>
Signed-off-by: Ed Warnicke <hagbard@gmail.com>
Signed-off-by: Ed Warnicke <hagbard@gmail.com>
| This subgroup will explore cross project how to POC, and perhaps migrate LFN | ||
| projects to such more modern infra. | ||
|
|
||
| It is important to be clear: no community should change if it does not see benefit. |
There was a problem hiding this comment.
Need to specifically evaluate if moving to a CI as a Service approach would be lower cost and meet all the security and access requirements. For those consumers of opensource would github be easier to work with - for example companies already usin git would moving to github from gerrit allow preservation of commit history etc which is lost in the git to gerrit pushes that occur today
Task should include report on:
- Cost benefit to projects moving to CI as a Service
- Required tool changes to realize that cost savings
- New Flows documented for both PTLs and contributers with the new tooling
a. changes from git commit -as --amend and git review
b. changes to Jira plugins
c. any changes to pom.xml ?
d. conversion of jjb to another tool - How will repo creation be managed so that project requirements for accountability are maintained
- How will access control be maintained so that linux foundation ID's with Contributer Agreement relationship is maintained or replaced with a different strategy ?
There was a problem hiding this comment.
@bdfreeman1421 Excellent questions! I have some partial answers:
for example companies already usin git would moving to github from gerrit allow preservation of commit history etc which is lost in the git to gerrit pushes that occur today
Github has flexiblity here. You can pick how PRs get merged either PR by PR, or at the repo level. Options are:
- Merge
- Squash and merge
- Rebase and merge
Squash and merge has the 'collapse the history from the requested change into a single commit' behavior. I personally prefer squash and merge, but communities can decide their own preferences.
Task should include report on:
- Cost benefit to projects moving to CI as a Service
- Required tool changes to realize that cost savings
- New Flows documented for both PTLs and contributers with the new tooling
a. changes from git commit -as --amend and git review
Yep... the equivalent tool for github would be hub
b. changes to Jira plugins
Atlantsian appears to be actively improving their Jira github integration
c. any changes to pom.xml ?
Changes to pom.xml would depend on whether a community chose to switch to a cloud based maven repo provider, there are a bunch: sonatype provides free maven hosting for open source projects, packagecloud.io provides free hosting for open source projects (though at your scale, we may have to pay them a bit),deps.co offers maven hosting as a service. Not sure which if any of these would meet your communities needs... but there are a lot of good choices.
d. conversion of jjb to another tool
Yep. Thought I must say, having worked extensively with jjb and with circleci and travisci... circleci and travis are both simpler and more powerful... and the jobs are defined right in the project repos, so no more having to coordinate patches with a seperate jjb repo makes things go much much faster and smoother.
- How will repo creation be managed so that project requirements for accountability are maintained
One way to approach the problem would be to simply give the TSC members (or some subset chosen by the projects TSC) Admin rights to their github orgs. This way, when a project is approved by the TSC, a TSC member can create the repo right there on the spot.
- How will access control be maintained so that linux foundation ID's with Contributer Agreement relationship is maintained or replaced with a different strategy ?
There are tools to require DCO for github (we are using one in this repo), and a bunch of available tools for enforcing CLA (I've had to go through them at times when contributing to a project on github). So eminently solvable :) But an important point to bring up.
| * CircleCI or TravisCI or other cloud based CI - CI | ||
| * Various artifact repo as a service services | ||
| * Github Issues - Bug tracking | ||
| * Github + Hugo + Netlify - Websites/doc sites |
There was a problem hiding this comment.
as mentioned in the discussion thread (#1)
on our side we moved to gitlab because most of the features mentioned though github + .. are built-in.
we use the following features
- Source code management (very similar to github)
- CI/CD
- bug tracker
- website
- artifact management
Moreover gitlab is open source, which provides flexibility.
There was a problem hiding this comment.
@morganrOL Happy to throw gitlab into the consideration as well. The thing I care most about personally is ecosystem of tools. Github is the leader there, but gitlab is a close second (and has lots of other cool features as you mention).
| ------------------------ | ||
|
|
||
| Leverage the shared knowledge and experience of LFN Projects to identify good | ||
| solutions to common tooling problems. |
There was a problem hiding this comment.
there are lots of interesting linters available, vrpg created a docker which integrates lots of upstream linters
https://hub.docker.com/r/vpgrp/linter
(markdown, ansible, python, docker, yaml, prometheus, go, riby, shell,...).
each community may obviously have its own rules and customization.
|
I think we need a separate document or wiki page that starts to collect the outline of the teams work. Problem statement, tasks, questions to be answered and results. I dont think an rst or markup is actually the right tool to use for a document or set of documents for the working team. This should be one of the items discussed at the kick off call. |
|
Cool... I know that github has a wiki feature as well we could use :)
Ed
…On Fri, Jan 18, 2019 at 7:13 AM bdfreeman1421 ***@***.***> wrote:
I think we need a separate document or wiki page that starts to collect
the outline of the teams work. Problem statement, tasks, questions to be
answered and results. I dont think an rst or markup is actually the right
tool to use for a document or set of documents for the working team. This
should be one of the items discussed at the kick off call.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABY0aAoXEG1-e9c89f1lqeMysxm_Vaftks5vEchsgaJpZM4aDZfl>
.
|
No description provided.