On Mon, 3 Feb 2020 at 11:04, sankarshan <sankars...@kadalu.io> wrote: > > Please note the meeting details and attached to this note is the file > to add to the calendar. > > On Thu, 23 Jan 2020 at 16:45, Sankarshan Mukhopadhyay > <sankars...@kadalu.io> wrote: > > > > [snip] > > > In preparation for the next meeting in 2 week's time (06-Feb, > > tentatively) , the following items would be reasonably ready for > > discussion. sankarshan will set up the next and subsequent meetings. > > > > + a proposed workflow including patch merge model. Amar had an earlier > > proposal and he'll review the necessity to refresh it in light of best > > practices from other projects such as Ansible > > > > I think it might be more appropriate to have this as an issue and > tracked. I'll get that in prior to our meeting. >
Attached a text file containing a general direction of the plans and possible workflow. This is based on a previous discussion initiated by Amar. > > + an enhanced understanding of dates for the start of the trial run in > > context of the GA dates for Gluster8. At this meeting the idea is to > > do the trial before the Gluster 8 release in order to get enough time > > to work through any issues > > We will need to estimate the work needed so as to pin a date for cut-over to Github. > > + Michael and Deepshikha will also endeavor to work through the topic > > to discover any additional tasks/sub-tasks and risks. > > > > ++ Invite for subsequent meetings ++ > > > > Topic: Gluster community Github migration prep meeting > > Time: Feb 6, 2020 15:00 Mumbai, Kolkata, New Delhi > > Every 2 weeks on Thu, until Apr 30, 2020, 7 occurrence(s) > > Feb 6, 2020 15:00 > > Feb 20, 2020 15:00 > > Mar 5, 2020 15:00 > > Mar 19, 2020 15:00 > > Apr 2, 2020 15:00 > > Apr 16, 2020 15:00 > > Apr 30, 2020 15:00 > > Please download and import the following iCalendar (.ics) files to > > your calendar system. > > Weekly: > > https://zoom.us/meeting/tJUtdOGtrTwrc5fFvCPhiQcvaL9jU1shNA/ics?icsToken=98tyKuCprjgiH9eSsV39Z7ItOav5bM_2kHIbrIVLvy_tChFQdALab-h3Y6F3PvmB > > > > Join Zoom Meeting > > https://zoom.us/j/910385371 > > > > Meeting ID: 910 385 371 > > > > One tap mobile > > +16699009128,,910385371# US (San Jose) > > +16465588656,,910385371# US (New York) > > > > Dial by your location > > +1 669 900 9128 US (San Jose) > > +1 646 558 8656 US (New York) > > Meeting ID: 910 385 371 > > Find your local number: https://zoom.us/u/a9X9UtuHA -- sankars...@kadalu.io | TZ: UTC+0530 kadalu.io : Making it easy to provision storage in k8s!
Migrating the Gluster development workflow to Github The project has been considering moving the entire workflow for development to Github. At present, this workflow is split across a set of tools. These include a Github repository (functioning as the mirror of the primary repository); a hosted Gerrit instance and an instance of bugzilla (hosted by Red Hat). The intended outcome is to enable the Gluster project community with modern methods of development which are also used by other related project communities. To this achieve this outcome, the project will be considering switching over to a Github based workflow. Once the migration is complete, the Gerrit can continue to exist as a mirror or, archive copy. The better option is to decommision the Gerrit instance itself. This means that repositories on Github will be considered primary respositories; Github Issues (also see https://guides.github.com/features/issues/) will be the method by which reports about issues, defects, enhancements etc be received by the project. Release planning and content curation for a release will be undertaken on Github itself using a combination of labels, queries and project boards. The glusterfs repo will be migrated to Github to enable a development workflow such as below (also see https://guides.github.com/introduction/flow/): + developer is expected to fork the glusterfs repo + developer makes changes to his/her personal branch + developer opens a PR with the project repo + approval methods of +1 and +2 will be tooled on the PR + merging of patches would be linked to successful CentOS regression and smoke runs The developers will have to adopt a Squash+Merge method of handling commits which would enable a workflow experience similar to what is currently being done on Gerrit The complete switchover to Github will need to be in at least 2 steps 1. Moving the issue reporting flows from Bugzilla (bugzilla.redhat.com) to Github 2. Moving the repository from existing primary to Github Step 1 is expected to cause no near term impact to the workflow. For Step 2, it is required to consider business rules within Github which allow for a. creation of teams or, granular abilities to do work within repository b. availability of action commands to use PR comments to invoke furture actions viz. (re)triggering tests; change labels; assign a reviewer and similar An additional set of tooling would be required for automated labelling and preliminary triage of issues filed on the project. There are large projects who maintain a set of good habits which allow for issues filed to be correctly labelled based on tooling thus allowing lesser intervention by a human at each stage.
_______________________________________________ Gluster-infra mailing list Gluster-infra@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-infra
