Typo correction: "the bot should remove", not "the boy" (oh my mobile tapping...)
сб, 25 дек. 2021 г., 12:31 Vasily <just.one....@yandex.ru>: > Hi, > > First off, a great idea bridging that gap! But I agree that the topic is > misleading, maybe rename to smth like "github bridge for PR creation" to be > really explicit? > > Second one, why first-comers aren't allowed to submit without > pre-approval? (context: I haven't made my contributions to ffmpeg yet, > though posted a single patch which stalled at review because of lack of my > time). > > And last point - if comments from github aren't re-posted to the list, > maybe the boy should remove them or edit by removing the message and > telling the commenter to use the ML? > > Anyway, good idea! > > Thanks, Vasily > > > пт, 24 дек. 2021 г., 1:30 Soft Works <softwo...@hotmail.com>: > >> >> >> > -----Original Message----- >> > From: Soft Works >> > Sent: Thursday, December 23, 2021 12:25 AM >> > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org >> > >> > Subject: GitHub Integration >> > >> > Hi, >> > >> > holidays are approaching and I got a little present for all of you >> > even though it won’t be something for everybody. >> > >> > A while ago I had committed to prepare a test setup for integrating >> > GitHub in a similar way as the Git developers are doing. >> > >> > For those who missed it or don’t remember the outcome: >> > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123329.html >> > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg123288.html >> >> I think I should add a quick summary on this subject for all those >> who haven't followed the discussion in August. >> >> The Git project (https://git-scm.com/) has a similar problem like >> ffmpeg: There are a number of long-time core developers that are >> strictly rejecting to move away from the ML based approach. >> That's how GitGitGadget came to life, intending to bridge that gap. >> >> Adopting that approach for ffmpeg has a number of advantages: >> >> - we can skip the "learning process", i.e. finding out what works >> in practical use and what doesn't >> - what has found acceptance at their project - given the similar >> profile of the developers involved - will likely be acceptable >> for ffmpeg as well (roughly at least) >> - the part that I like most is: even without explicit acceptance - >> this approach doesn't leave much room for objection, because it >> doesn't impose any changes or drawback to the way people are >> working with the ML >> >> >> Here's a rough overview about how it's working: >> >> - User submits a PR to the GitHub repo >> >> - When it's a user's first PR, the ffmpeg-codebot will >> respond with a very comprehensive message (as PR comment), >> explaining the procedures and providing an overview about >> contributing to ffmpeg with links to the individual topics >> on the ffmpeg website regarding contributing. >> >> - The message further explains that first-time users are not >> allowed to submit immediately, and that a user needs to >> find and contact another developer who is allowed to make >> submissions and ask that developer to vouch for him. >> >> - Every developer who has been allowed to submit can vouch >> for a first-time submitter >> It is done by adding a comment containing "/allow" to the >> first-time user's PR >> >> - Upon submitting the PR (no matter whether first-time or existing >> submitter), the code bot will likely have posted some other >> comments, indicating which changes need to be made to the >> patchset before it can be submitted. >> >> - The user addresses those changes and then force-pushes the branch >> to GitHub, the code bot re-runs all checks and when all >> requirements are met (and only then), the user will be >> able to submit. >> This is done by posting a comment to the PR containing "/submit" >> The code bot will automatically create the patch e-mails and >> send them to the ML. >> (it's also possible to post "/preview" to get the same e-mails >> created but only sent to a user's own e-mail account) >> >> - Comments that are made on the ML are mirrored back to the GitHub >> PR as comments. The other way is not yet implemented, so at this >> point, a user will need to respond through the ML (that's >> clearly indicated). >> I hope this will be implemented soon, it's not easy though to >> do it in a nice way without repeating all those quoted lines >> each time >> >> What's really like is the way how you submit new versions of >> a patchset: >> >> - After having applied the changes locally, you just (force-) push >> the branch again, and post another comment with "/submit" >> Everything is done automatically then: the patchset version >> number is increased, new patches are generated and sent to the ML >> >> Kind regards, >> softworkz >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". >> > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
