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.
-Amar On Thu, Sep 5, 2019 at 5:13 PM Amar Tumballi <ama...@gmail.com> wrote: > Going through the thread, I see in general positive responses for the > same, with few points on review system, and not loosing information when > merging the patches. > > While we are working on that, we need to see and understand how our CI/CD > looks like with github migration. We surely need suggestion and volunteers > here to get this going. > > Regards, > Amar > > > On Wed, Aug 28, 2019 at 12:38 PM Niels de Vos <nde...@redhat.com> wrote: > >> On Tue, Aug 27, 2019 at 06:57:14AM +0530, Amar Tumballi Suryanarayan >> wrote: >> > On Tue, Aug 27, 2019 at 12:10 AM Niels de Vos <nde...@redhat.com> >> wrote: >> > >> > > On Mon, Aug 26, 2019 at 08:36:30PM +0530, Aravinda Vishwanathapura >> Krishna >> > > Murthy wrote: >> > > > On Mon, Aug 26, 2019 at 7:49 PM Joe Julian <j...@julianfamily.org> >> wrote: >> > > > >> > > > > > Comparing the changes between revisions is something >> > > > > that GitHub does not support... >> > > > > >> > > > > It does support that, >> > > > > actually._______________________________________________ >> > > > > >> > > > >> > > > Yes, it does support. We need to use Squash merge after all review >> is >> > > done. >> > > >> > > Squash merge would also combine multiple commits that are intended to >> > > stay separate. This is really bad :-( >> > > >> > > >> > We should treat 1 patch in gerrit as 1 PR in github, then squash merge >> > works same as how reviews in gerrit are done. Or we can come up with >> > label, upon which we can actually do 'rebase and merge' option, which >> can >> > preserve the commits as is. >> >> Something like that would be good. For many things, including commit >> message update squashing patches is just loosing details. We dont do >> that with Gerrit now, and we should not do that when using GitHub PRs. >> Proper documenting changes is still very important to me, the details of >> patches should be explained in commit messages. This only works well >> when developers 'force push' to the branch holding the PR. >> >> Niels >> _______________________________________________ >> >> Community Meeting Calendar: >> >> APAC Schedule - >> Every 2nd and 4th Tuesday at 11:30 AM IST >> Bridge: https://bluejeans.com/836554017 >> >> NA/EMEA Schedule - >> Every 1st and 3rd Tuesday at 01:00 PM EDT >> Bridge: https://bluejeans.com/486278655 >> >> Gluster-devel mailing list >> Gluster-devel@gluster.org >> https://lists.gluster.org/mailman/listinfo/gluster-devel >> >>
_______________________________________________ Community Meeting Calendar: APAC Schedule - Every 2nd and 4th Tuesday at 11:30 AM IST Bridge: https://bluejeans.com/118564314 NA/EMEA Schedule - Every 1st and 3rd Tuesday at 01:00 PM EDT Bridge: https://bluejeans.com/118564314 Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
