On Thu, Sep 30, 2021 at 4:09 PM Brian Cain <brian.c...@gmail.com> wrote: > > > > On Thu, Sep 30, 2021, 6:04 PM Brian Cain <brian.c...@gmail.com> wrote: >> >> Does something like Rust's "bors" bot satisfy the herald rules need? > > > > sorry, maybe I was thinking of the high-five bot. And it looks like that's > not quite a match for herald.
Actually high-five may be a good starting point! In practice it may still be a bit limited by the GitHub integration: for example I suspect you may not be able to "subscribe" someone to a pull-request? Also what the user will receive as an email may be quite unhelpful (you have been subscribed to "<pull-request title>" instead of the current more comprehensive emails). > > >> >> re: #2 I have done this on GHE and it's mildly awkward but it does work. >> >> And yes normalizing force pushes is the unfortunate state of GitHub PRs. >> Comments are preserved. Code-anchored comments like review comments are >> marked as referring to out-of-date code, IIRC. >> >> On Thu, Sep 30, 2021, 5:56 PM Mehdi AMINI <joker....@gmail.com> wrote: >>> >>> We talked about this with the IWG (Infrastructure Working Group) just >>> last week coincidentally. >>> Two major blocking tracks that were identified at the roundtable >>> during the LLVM Dev Meeting exactly 2 years ago are still an issue >>> today: >>> >>> 1) Replacement for Herald rules. This is what allows us to subscribe >>> and track new revisions or commits based on paths in the repo or other >>> criteria. We could build a replacement based on GitHub action or any >>> other kind of service, but this is a bit tricky (how do you store >>> emails privately? etc.). I have looked around online but I didn't find >>> another OSS project (or external company) providing a similar service >>> for GitHub unfortunately, does anyone know of any? >>> >>> 2) Support for stacked commits. I can see how to structure this >>> somehow assuming we would push pull-request branches in the main repo >>> (with one new commit per branch and cascading the pull-requests from >>> one branch to the other), otherwise this will be a major regression >>> compared to the current workflow. >>> >>> What remains unknown to me is the current state of GitHub management >>> of comments across `git commit --amend` and force push to update a >>> branch. >>> >>> Others may have other items to add! >>> >>> -- >>> Mehdi >>> >>> On Thu, Sep 30, 2021 at 3:39 PM Brian Cain via llvm-dev >>> <llvm-...@lists.llvm.org> wrote: >>> > >>> > How far are we from a workflow that leverages Github's Pull Requests? Is >>> > there some consensus that it's a desired end goal, but some features are >>> > missing? Or do we prefer to use a workflow like this for the long term? >>> > >>> > On Thu, Sep 30, 2021, 4:54 PM Chris Tetreault via llvm-dev >>> > <llvm-...@lists.llvm.org> wrote: >>> >> >>> >> As I, and others have noticed, it seems that as of today, there’s some >>> >> certificate issue with arcanist. (See: >>> >> https://lists.llvm.org/pipermail/llvm-dev/2021-September/153019.html) >>> >> The fix seems simple, and a PR is up, but looking through the PR >>> >> activity, it seems that the PR will not be accepted because Phabricator >>> >> is no longer being maintained. It seems that arc has become the first >>> >> casualty of the discontinuation of maintenance of phabricator. >>> >> >>> >> >>> >> >>> >> I know that arc is not universally used, but I think it’s a serious blow >>> >> to many people’s workflows. I think that MyDeveloperDay’s question might >>> >> have just become a bit more urgent. >>> >> >>> >> >>> >> >>> >> I suppose in the short-term, we could fork the phabricator repos in >>> >> order to fix little issues like this. Alternately, we should probably >>> >> stop recommending arcanist (unless we want to provide instructions on >>> >> how to fix any breakages that come along). >>> >> >>> >> >>> >> >>> >> Thanks, >>> >> >>> >> Chris Tetreault >>> >> >>> >> >>> >> >>> >> From: llvm-dev <llvm-dev-boun...@lists.llvm.org> On Behalf Of >>> >> MyDeveloper Day via llvm-dev >>> >> Sent: Wednesday, August 18, 2021 10:17 AM >>> >> To: llvm-dev <llvm-...@lists.llvm.org>; cfe-commits >>> >> <cfe-commits@lists.llvm.org> >>> >> Subject: [llvm-dev] Phabricator Creator Pulling the Plug >>> >> >>> >> >>> >> >>> >> WARNING: This email originated from outside of Qualcomm. Please be wary >>> >> of any links or attachments, and do not enable macros. >>> >> >>> >> All >>> >> >>> >> >>> >> >>> >> I'm a massive fan of Phabricator, and I know there is often lots of >>> >> contentious discussion about its relative merits vs github, >>> >> >>> >> >>> >> >>> >> But unless I missed this, was there any discussion regarding the recent >>> >> "Winding Down" announcement of Phabricator? and what it might mean for >>> >> us in LLVM >>> >> >>> >> >>> >> >>> >> See: >>> >> >>> >> https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/ >>> >> >>> >> https://www.phacility.com/phabricator/ >>> >> >>> >> >>> >> >>> >> Personally I'm excited by the concept of a community driven replacement >>> >> ( https://we.phorge.it/) . >>> >> >>> >> epriestley did a truly amazing job, it wasn't open to public >>> >> contributions. Perhaps more open development could lead to closing some >>> >> of the github gaps that were of concern. >>> >> >>> >> >>> >> >>> >> MyDeveloperDay >>> >> >>> >> _______________________________________________ >>> >> LLVM Developers mailing list >>> >> llvm-...@lists.llvm.org >>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> > >>> > _______________________________________________ >>> > LLVM Developers mailing list >>> > llvm-...@lists.llvm.org >>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
