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

[Amar Tumballi]

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 <amarts at 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 <ndevos at 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 <ndevos at 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 <joe at 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 at gluster.org
>> https://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20191014/421768b5/attachment.html>