[Gluster-Maintainers] [Gluster-devel] Proposal: move glusterfs development to github workflow, completely
Deepshikha Khandelwal
dkhandel at redhat.com
Tue Oct 15 06:31:34 UTC 2019
On Tue, Oct 15, 2019 at 10:57 AM Aravinda Vishwanathapura Krishna Murthy <
avishwan at redhat.com> wrote:
> Centos CI was voting Glusterd2 repo's pull requests.
>
> https://github.com/gluster/centosci/blob/master/jobs/glusterd2.yml
>
> On Mon, Oct 14, 2019 at 8:31 PM Amar Tumballi <amarts at gmail.com> wrote:
>
>>
>>
>> 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, we can make use of existing jenkins jobs for GitHub. It needs some
config changes in the JJB to get triggered for GitHub pull requests.
I can start off with basic smoke testing.
>
>> 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)
>>
>> Happy to get some help here.
>>
>> Regards,
>> Amar
>>
>>
>>> Niels
>>>
>>>
>>> >
>>> > -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
>>> > >>
>>> > >>
>>>
>>> > _______________________________________________
>>> >
>>> > 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 at gluster.org
>>> > https://lists.gluster.org/mailman/listinfo/gluster-devel
>>> >
>>>
>>> _______________________________________________
>> maintainers mailing list
>> maintainers at gluster.org
>> https://lists.gluster.org/mailman/listinfo/maintainers
>>
>
>
> --
> regards
> Aravinda VK
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> https://lists.gluster.org/mailman/listinfo/maintainers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20191015/e01c4f36/attachment.html>
More information about the maintainers
mailing list