[Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely

[Michael Scherer]

Le lundi 14 octobre 2019 à 20:30 +0530, Amar Tumballi a écrit :
> On Mon, 14 Oct, 2019, 5:37 PM Niels de Vos, <ndevos at redhat.com>
> wrote:
> 
> > On Mon, Oct 14, 2019 at 03:52:30PM +0530, Amar Tumballi wrote:
> > > Any thoughts on this?
> > > 
> > > I tried a basic .travis.yml for the unified glusterfs repo I am
> > > maintaining, and it is good enough for getting most of the tests.
> > > Considering we are very close to glusterfs-7.0 release, it is
> > > good to
> > 
> > time
> > > this after 7.0 release.
> > 
> > Is there a reason to move to Travis? GitHub does offer integration
> > with
> > Jenkins, so we should be able to keep using our existing CI, I
> > think?
> > 
> 
> Yes, that's true. I tried Travis because I don't have complete idea
> of
> Jenkins infra and trying Travis needed just basic permissions from me
> on
> repo (it was tried on my personal repo)

Travis is limited to 1 builder per project with the free version.. 
So since the regression test last 4h, I am not sure exactly what is the
plan there.

Now, on the whole migration stuff, I do have a few questions:

- what will happen to the history of the project (aka, the old
review.gluster.org server). I would be in favor of dropping it if we
move out, but then, we would lose all informations there (the review
content itself). 

- what happen to existing proposed patches, do they need to be migrated
one by one (and if so, who is going to script that part)

- can we, while we are on it, force 2FA for the whole org on github ?
before, I didn't push too hard because this wasn't critical, but if
there is a migration, that would be much more important.

- what is the plan to force to enforce the various policies ?
(like the fact that commit need to be sign, in a DCO like fashion, or
to decide who can merge, who can give +2, and how we trigger build only
when someone has said "this is verified") 

- can we define also some goals on why to migrate ?
the thread do not really explain why, except "that's what everybody is
doing". Based on previous migrations for different contexts, that's
usually not sufficient, and we get the exact same amount of
contribution no matter what (like static blog vs wordpress vs static
blog), except that someone (usually me) has to do lots of work. 

So could someone give some estimate that can be measured on what is
going to be improved, along a timeframe for the estimated improvement ?
(so like in 6 months, this will be bring new developpers, or this will
make patch being merged 10% faster). And just to be clear, if the goals
are not reached in the timeframe, I am gonna make people accountable
and complain next time someone propose a migration. 

-- 
Michael Scherer / He/Il/Er/Él
Sysadmin, Community Infrastructure



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20191021/7a2b900b/attachment.sig>