<div dir="ltr"><div dir="ltr">Thanks for the email Misc. My reasons inline.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 21, 2019 at 4:44 PM Michael Scherer <<a href="mailto:mscherer@redhat.com" target="_blank">mscherer@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Le lundi 14 octobre 2019 à 20:30 +0530, Amar Tumballi a écrit :<br>
> On Mon, 14 Oct, 2019, 5:37 PM Niels de Vos, <<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>><br>
> wrote:<br>
> <br>
> > On Mon, Oct 14, 2019 at 03:52:30PM +0530, Amar Tumballi wrote:<br>
> > > Any thoughts on this?<br>
> > > <br>
> > > I tried a basic .travis.yml for the unified glusterfs repo I am<br>
> > > maintaining, and it is good enough for getting most of the tests.<br>
> > > Considering we are very close to glusterfs-7.0 release, it is<br>
> > > good to<br>
> > <br>
> > time<br>
> > > this after 7.0 release.<br>
> > <br>
> > Is there a reason to move to Travis? GitHub does offer integration<br>
> > with<br>
> > Jenkins, so we should be able to keep using our existing CI, I<br>
> > think?<br>
> > <br>
> <br>
> Yes, that's true. I tried Travis because I don't have complete idea<br>
> of<br>
> Jenkins infra and trying Travis needed just basic permissions from me<br>
> on<br>
> repo (it was tried on my personal repo)<br>
<br>
Travis is limited to 1 builder per project with the free version.. <br>
So since the regression test last 4h, I am not sure exactly what is the<br>
plan there.<br>
<br></blockquote><div><br></div><div>We can't regress from our current testing coverage when we migrate. So, My take is, we should start with surely using existing Jenkins itself from github. And eventually see if there are any better options, or else at least remain with this CI. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Now, on the whole migration stuff, I do have a few questions:<br>
<br>
- what will happen to the history of the project (aka, the old<br>
<a href="http://review.gluster.org" rel="noreferrer" target="_blank">review.gluster.org</a> server). I would be in favor of dropping it if we<br>
move out, but then, we would lose all informations there (the review<br>
content itself). <br>
<br></blockquote><div><br></div><div>I would like to see it hosted somewhere (ie, in same URL preferably). </div><div><br></div><div>But depending on sponsorship for the hosting charges, if we had to decide to shutting the service down, my take is, we can make the DB content made available for public download. Happy to provide a 'how to view patches' guide so one can setup Gerrit locally and see the details. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- what happen to existing proposed patches, do they need to be migrated<br>
one by one (and if so, who is going to script that part)<br>
<br></blockquote><div><br></div><div>I checked that we have < 50 patches active on master branch, and other than Yaniv, no one has more than 5 patches active in review queue. So, I propose people can take up their own patches and post it to GitHub. For those who are not willing to do that extra work, or not active in project now, I am happy to help them migrate the patch to PR.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- can we, while we are on it, force 2FA for the whole org on github ?<br>
before, I didn't push too hard because this wasn't critical, but if<br>
there is a migration, that would be much more important.<br>
<br></blockquote><div><br></div><div>Yes. I believe that is totally fine, specifically for those who are admins of the org, and those who can merge.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- what is the plan to force to enforce the various policies ?<br>
(like the fact that commit need to be sign, in a DCO like fashion, or<br>
to decide who can merge, who can give +2, and how we trigger build only<br>
when someone has said "this is verified") <br>
<br></blockquote><div><br></div><div>About people, two options IMO:</div><div>1. Provide access to same set of people who have access in Gerrit.</div><div>or 2. Look at the activity list in last 1 year, and see who has actually reviewed AND merged any patch from the above list to have access.</div><div><br></div><div>About policies on how to trigger build, and merge I prefer to use tools like <a href="http://mergify.io" target="_blank">mergify.io</a> which is also used by many open source projects, and also friends @ Ceph project use the same. That way, there would be no human pressing merge, but policy based patches would be merged. </div><div><br></div><div>About what strings, commands to use for triggering builds (/run smoke, /run regression etc), I am happy to work with someone to get this done.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- can we define also some goals on why to migrate ?<br></blockquote><div><br></div><div>Sure, will list below.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
the thread do not really explain why, except "that's what everybody is<br>
doing". Based on previous migrations for different contexts, that's<br>
usually not sufficient, and we get the exact same amount of<br>
contribution no matter what (like static blog vs wordpress vs static<br>
blog), except that someone (usually me) has to do lots of work. <br>
<br></blockquote><div><br></div><div>I agree, and sorry about causing lot of work for you :-/ None of this intentional. We all thrive and look for better way as they (and we) evolve. It is good to recheck whether we are using right tools, right processes or not every 2 yrs at least.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So could someone give some estimate that can be measured on what is<br>
going to be improved, along a timeframe for the estimated improvement ?<br>
(so like in 6 months, this will be bring new developpers, or this will<br>
make patch being merged 10% faster). And just to be clear, if the goals<br>
are not reached in the timeframe, I am gonna make people accountable<br>
and complain next time someone propose a migration. <br>
<br></blockquote><div><br></div><div>This part of the email is very critical, for everyone. Because if we don't measure it, we didn't achieve anything.</div><div><br></div><div>The '<b>1. everyone uses it, so lets use it</b>' reason is critical, and not the only one. Let me add some reasoning on this topic before listing other perks I can think of.</div><div> If you look at last 6 months of 'patch' contributions which happened directly from developers outside of Red Hat, it is ~5 people, for the total of 11 patches. In the meantime there were 340+ patches posted by people belonging to Red Hat. I posted few patches belonging to different users, who had posted the patches in bugzilla, which counts as a reason too IMO. (For example: <a href="https://review.gluster.org/#/c/glusterfs/+/22678/" target="_blank">https://review.gluster.org/22678/</a>)</div><div><br></div><div><b>2. Metrics / Insights: </b></div><div> For success of an opensource project, its popularity also is a big factor, and it can only be seen with some sort of analytics, and metrics. GitHub provides native insights of the project, and would be very helpful in seeing ourselves, and showcasing the activities in public.</div><div> This particular reason works beyond just our own repo, but helps by featuring in many promotional emails and data published by github (or even other analysis people). For example GlusterFS's activity in 2018 was higher than many projects featured in "Top 100 active open source projects of 2018" list published, but because we were running all our show in isolation, we didn't get considered.</div><div><br></div><div><b>3. Alternative options for users to reach developers.</b></div><div> Today, there are 2 ways to reach developers or raise issues for a community user. </div><div> 1. Report an issue in bugzilla (for a new user it is registering into one more tool), </div><div> 2. Send an email to gluster-devel.</div><div> The way github is structured, the repository itself can work as forum, where users can raise issues, and track progress by 'watching'. And as they can also submit patches in the same system, it will be all inclusive community.</div><div><br></div><div><b>4. Review Suggestions</b></div><div> For any new developers, coming to Gerrit, they wouldn't know whom to add as reviewer for the patch. This caused lot of delay in merging/reviewing patches, because developers complained "I was not added as the reviewer". How would an external contributor know who-is-who? GitHub, while opening the PR, depending on the history of contributions, and reviews, suggest reviewers, so Reviewers can add at least one of the maintainer, or peer as reviewer. This would fasten up the review process.</div><div><br></div><div><b>5. Tools and expanding eco-system.</b></div><div> I see that there are many tools which are being developed around github workflow to make developer's life simple, and we can use them to make ourselves efficient. Fog example, <a href="https://mergify.io">https://mergify.io</a> etc</div><div><br></div><div><br></div><div>Goals of the migration (IMO):</div><div>1. We can measure month to month growth and unique visitor metrics.</div><div>2. Measure outside Red Hat contribution, and see if it is going up.</div><div>3. Check if this makes more activity in github issues etc.</div><div><br></div><div>Regards,</div><div>Amar</div><div><a href="https://github.com/amarts">https://github.com/amarts</a></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-- <br>
Michael Scherer / He/Il/Er/Él<br>
Sysadmin, Community Infrastructure<br>
<br>
<br><br>
</blockquote></div>
</div>