On 6/22/20 2:34 AM, Manuel Klimek via llvm-dev wrote:> On Sat, Jun 20, 2020 at 1:45 AM Zachary Turner via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > There’s also some feature regressions in GH vs Phab. > > You *must* initiate a review via a pull request, and pull request > by definition compares your working copy against master. > > This is not very compatible with LLVMs approach to incremental > development. For example, if you ask someone to break a large > patch into 5 smaller patches, with Phab this is very easy because > you can upload the diff between N and N+1, then N+1 and N+2, etc. > > But with the GH workflow in order to get a review on N+4 you have > to include all the changes from all the earlier revisions as well. > > The way around this is to fork and make 5 branches in your fork, > then base each branch off the previous one. But now what do you > do if someone requests a change on the first one? > > Overall it’s a pretty serious limitation if you’re used to Phab, > and I would evaluate very carefully if you’re thinking of going > this route > > > Are you volunteering to drive Phab maintenance and keep it up & running?This really seems like a question for the board, rather than any individual. If you're resigning and the community values phab, having the board weigh in on cost to support the tool seems worthwhile. I suspect that cost will be high enough that we will migrate to something free, but we should at least have an informed discussion. (In case it's not clear, "cost" above is specifically meant in both the financial and non-financial sense. This might be a case where a contractor is worth considering instead of relying solely on volunteer labor.)> > > On Fri, Jun 19, 2020 at 4:35 PM Zachary Turner <zturner at roblox.com > <mailto:zturner at roblox.com>> wrote: > > Yes GH has a Squash & Merge option that works well. It’s what > we use. We use the GH web interface for all of this though, > if you’re supporting command line you may need some custom > tooling to support this. > > The biggest thing is that it requires a lot of mental > retraining to get out of the rebasing mindset for daily > development > > On Fri, Jun 19, 2020 at 4:32 PM David Blaikie > <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: > > On Fri, Jun 19, 2020 at 4:23 PM Zachary Turner via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > wrote: > > > > I use GH daily at my current employer and i can tell you > that the issues with rebasing are very real. Unless you > only use merge commits you are going to have a very bad time > > Would it be practical to use merge commits during review > (never > rebasing) & then rebasing/squashing to commit to the main > line? > (guessing that might still make looking back at the > history of the > review difficult?) > > - Dave > > > > > On Fri, Jun 19, 2020 at 2:23 PM Mehdi AMINI via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > wrote: > >> > >> > >> > >> On Fri, Jun 19, 2020 at 1:15 PM Keith Smiley > <keithbsmiley at gmail.com <mailto:keithbsmiley at gmail.com>> > wrote: > >>> > >>> FWIW GitHub's code review tools have improved > significantly in the past few years. At this point with > reviews and manual control over resolving / unresolving > comments I think many previous complaints I've seen about > GitHub vs Phabricator have been alleviated. > >> > >> > >> To be clear: this wasn't an outdated comment here, I'm > using GitHub very frequently *right now* as I'm reviewing > contributions to TensorFlow. > >> > >>> > >>> > >>> I also believe there's significant value for newcomers > and casual contributors (like myself) in using the same > tool as so many other major open source projects. > >>> > >>> On Fri, Jun 19, 2020 at 13:04 Mehdi AMINI via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > wrote: > >>>> > >>>> > >>>> > >>>> On Fri, Jun 19, 2020 at 9:56 AM Hubert Tong via > llvm-dev <llvm-dev at lists.llvm.org > <mailto:llvm-dev at lists.llvm.org>> wrote: > >>>>> > >>>>> On Fri, Jun 19, 2020 at 12:32 PM Anton Korobeynikov > via llvm-dev <llvm-dev at lists.llvm.org > <mailto:llvm-dev at lists.llvm.org>> wrote: > >>>>>> > >>>>>> Just my 2 cents here: we are working on enabling > this as a part of > >>>>>> bugzilla migration as PRs and issues are very tied > inside GitHub. Stay > >>>>>> tuned for updates! > >>>>> > >>>>> I am not aware that the previous long thread about > usage of GitHub PRs in place of Phabricator reviews got > anywhere near the point where the option of Phabricator > reviews was being dropped > >>>> > >>>> > >>>> That's my impression as well, I find GitHub review is > frustrating in comparison to phab, in particular the way > comments are handled across updates, unless you stick to > never rebase and only append commits and merges from > master. This is unfortunately not compatible with the LLVM > repo history right now. > >>>> > >>>> https://www.phacility.com offers hosting for > Phabricator, could we look into this instead? > >>>> > >>>> -- > >>>> Mehdi > >>>> > >>>> > >>>>> > >>>>> . The original post on this thread indicated > interest in not maintaining Phabricator. How does that > affect the availability of Phabricator? Does this mean > that the community is going to move to GitHub PRs because > the choice of Phabricator is being taken away? > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, Jun 19, 2020 at 3:45 PM Manuel Klimek via > llvm-dev > >>>>>> <llvm-dev at lists.llvm.org > <mailto:llvm-dev at lists.llvm.org>> wrote: > >>>>>> > > >>>>>> > -Chris' outdated email, +Chris' correct email :) > >>>>>> > > >>>>>> > On Fri, Jun 19, 2020 at 2:01 PM Manuel Klimek > <klimek at google.com <mailto:klimek at google.com>> wrote: > >>>>>> >> > >>>>>> >> Hi folks, > >>>>>> >> > >>>>>> >> phabricator maintenance is a topic that has been > lying dormant for a while now. > >>>>>> >> > >>>>>> >> That subsequently creates a non-optimal user > experience. > >>>>>> >> For me personally, given that github provides a > secure PR infrastructure, the additional effort required > to keep Phab going is not an investment I'm personally > willing to make. I understand that there are unique > selling points for Phab in its UI compared to github PRs, > but there are also significant downsides in the effort to > integrate with Phab that github PRs make easier. > >>>>>> >> > >>>>>> >> Thus, I see two options: > >>>>>> >> 1. somebody volunteers to take on Phabricator > maintenance and figures out a way to fund it, either > through the LLVM foundation or some other means (I'd love > for us at Google to pay for it directly and give folks > outside Google access, but that is unfortunately a hard > problem for a variety of reasons). I'd be happy to help to > provide a DB snapshot for the migration, of course. > >>>>>> >> > >>>>>> >> 2. We switch to github PRs > >>>>>> >> > >>>>>> >> Thoughts? > >>>>>> >> /Manuel > >>>>>> >> > >>>>>> >> > >>>>>> >> On Thu, Jun 18, 2020 at 6:42 PM Raphael Isemann > <teemperor at gmail.com <mailto:teemperor at gmail.com>> wrote: > >>>>>> >>> > >>>>>> >>> Friendly ping > >>>>>> >>> > >>>>>> >>> Am Do., 9. Apr. 2020 um 16:04 Uhr schrieb > Alexandre Ganea > >>>>>> >>> <alexandre.ganea at ubisoft.com > <mailto:alexandre.ganea at ubisoft.com>>: > >>>>>> >>> > > >>>>>> >>> > cc Paul / MyDeveloperDay > >>>>>> >>> > > >>>>>> >>> > > >>>>>> >>> > > >>>>>> >>> > De : llvm-dev > <llvm-dev-bounces at lists.llvm.org > <mailto:llvm-dev-bounces at lists.llvm.org>> De la part de > David Blaikie via llvm-dev > >>>>>> >>> > Envoyé : April 8, 2020 10:21 PM > >>>>>> >>> > À : Raphael “Teemperor” Isemann > <teemperor at gmail.com <mailto:teemperor at gmail.com>>; Manuel > Klimek <klimek at google.com <mailto:klimek at google.com>> > >>>>>> >>> > Cc : llvm-dev <llvm-dev at lists.llvm.org > <mailto:llvm-dev at lists.llvm.org>> > >>>>>> >>> > Objet : Re: [llvm-dev] Outdated Phabricator > version on reviews.llvm.org <http://reviews.llvm.org> > breaks Google authentication since today > >>>>>> >>> > > >>>>>> >>> > > >>>>>> >>> > > >>>>>> >>> > hey Manuel - are you/do you know who's likely > to be doing any upkeep on Phabricator these days? Might > need an update for this... > >>>>>> >>> > > >>>>>> >>> > > >>>>>> >>> > > >>>>>> >>> > - Dave > >>>>>> >>> > > >>>>>> >>> > > >>>>>> >>> > > >>>>>> >>> > On Wed, Apr 8, 2020 at 5:57 AM Raphael > “Teemperor” Isemann via llvm-dev <llvm-dev at lists.llvm.org > <mailto:llvm-dev at lists.llvm.org>> wrote: > >>>>>> >>> > > >>>>>> >>> > Hi all, > >>>>>> >>> > > >>>>>> >>> > I’m using my Google account to log into my > Phabricator account on reviews.llvm.org > <http://reviews.llvm.org> . Since today that no longer > works as I don’t seem to get any reply from > reviews.llvm.org <http://reviews.llvm.org> when I’m logged > into my account. It tried logging out which fixes the > issue of reviews.llvm.org <http://reviews.llvm.org> not > loading, but when I try to login I just get the following > error: > >>>>>> >>> > > >>>>>> >>> > > Expected to retrieve an "account" email > from Google Plus API call to identify account, but failed. > >>>>>> >>> > > >>>>>> >>> > After some searching it seems that this error > is due to the Google Plus API being shutdown and the > Phabricator folks replaced that logic (including this > error message string) a year ago here [1] > >>>>>> >>> > > >>>>>> >>> > I assume we haven’t updated reviews.llvm.org > <http://reviews.llvm.org> to whatever latest Phabricator > release contains that patch. > >>>>>> >>> > > >>>>>> >>> > Not sure who’s currently responsible for > updating reviews.llvm.org <http://reviews.llvm.org> so I > thought I’ll just drop a mail to the list (and maybe save > someone else from figuring out why their login is suddenly > broken). > >>>>>> >>> > > >>>>>> >>> > [1] https://secure.phabricator.com/D20030 > >>>>>> >>> > _______________________________________________ > >>>>>> >>> > LLVM Developers mailing list > >>>>>> >>> > llvm-dev at lists.llvm.org > <mailto:llvm-dev at lists.llvm.org> > >>>>>> >>> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >>>>>> > > >>>>>> > _______________________________________________ > >>>>>> > LLVM Developers mailing list > >>>>>> > llvm-dev at lists.llvm.org > <mailto:llvm-dev at lists.llvm.org> > >>>>>> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> With best regards, Anton Korobeynikov > >>>>>> Department of Statistical Modelling, Saint > Petersburg State University > >>>>>> _______________________________________________ > >>>>>> LLVM Developers mailing list > >>>>>> llvm-dev at lists.llvm.org > <mailto:llvm-dev at lists.llvm.org> > >>>>>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >>>>> > >>>>> _______________________________________________ > >>>>> LLVM Developers mailing list > >>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > >>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >>>> > >>>> _______________________________________________ > >>>> LLVM Developers mailing list > >>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >>> > >>> -- > >>> -- > >>> Keith Smiley > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200623/05d5bcf0/attachment.html>
On Tue, Jun 23, 2020 at 7:56 PM Philip Reames <listmail at philipreames.com> wrote:> > On 6/22/20 2:34 AM, Manuel Klimek via llvm-dev wrote: > > On Sat, Jun 20, 2020 at 1:45 AM Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> There’s also some feature regressions in GH vs Phab. >> >> You *must* initiate a review via a pull request, and pull request by >> definition compares your working copy against master. >> >> This is not very compatible with LLVMs approach to incremental >> development. For example, if you ask someone to break a large patch into 5 >> smaller patches, with Phab this is very easy because you can upload the >> diff between N and N+1, then N+1 and N+2, etc. >> >> But with the GH workflow in order to get a review on N+4 you have to >> include all the changes from all the earlier revisions as well. >> >> The way around this is to fork and make 5 branches in your fork, then >> base each branch off the previous one. But now what do you do if someone >> requests a change on the first one? >> >> Overall it’s a pretty serious limitation if you’re used to Phab, and I >> would evaluate very carefully if you’re thinking of going this route >> > > Are you volunteering to drive Phab maintenance and keep it up & running? > > This really seems like a question for the board, rather than any > individual. >I've mentioned that trying to get this funded through official LLVM channels is an option, but from all the information I have, it is not a short-term viable option. Having individuals step up and drive it is a significantly less coordination-heavy and thus, overall, cheaper way.> If you're resigning and the community values phab, having the board weigh > in on cost to support the tool seems worthwhile. I suspect that cost will > be high enough that we will migrate to something free, but we should at > least have an informed discussion. > > (In case it's not clear, "cost" above is specifically meant in both the > financial and non-financial sense. This might be a case where a contractor > is worth considering instead of relying solely on volunteer labor. >>> On Fri, Jun 19, 2020 at 4:35 PM Zachary Turner <zturner at roblox.com> >> wrote: >> >>> Yes GH has a Squash & Merge option that works well. It’s what we use. >>> We use the GH web interface for all of this though, if you’re supporting >>> command line you may need some custom tooling to support this. >>> >>> The biggest thing is that it requires a lot of mental retraining to get >>> out of the rebasing mindset for daily development >>> >>> On Fri, Jun 19, 2020 at 4:32 PM David Blaikie <dblaikie at gmail.com> >>> wrote: >>> >>>> On Fri, Jun 19, 2020 at 4:23 PM Zachary Turner via llvm-dev >>>> <llvm-dev at lists.llvm.org> wrote: >>>> > >>>> > I use GH daily at my current employer and i can tell you that the >>>> issues with rebasing are very real. Unless you only use merge commits you >>>> are going to have a very bad time >>>> >>>> Would it be practical to use merge commits during review (never >>>> rebasing) & then rebasing/squashing to commit to the main line? >>>> (guessing that might still make looking back at the history of the >>>> review difficult?) >>>> >>>> - Dave >>>> >>>> > >>>> > On Fri, Jun 19, 2020 at 2:23 PM Mehdi AMINI via llvm-dev < >>>> llvm-dev at lists.llvm.org> wrote: >>>> >> >>>> >> >>>> >> >>>> >> On Fri, Jun 19, 2020 at 1:15 PM Keith Smiley <keithbsmiley at gmail.com> >>>> wrote: >>>> >>> >>>> >>> FWIW GitHub's code review tools have improved significantly in the >>>> past few years. At this point with reviews and manual control over >>>> resolving / unresolving comments I think many previous complaints I've seen >>>> about GitHub vs Phabricator have been alleviated. >>>> >> >>>> >> >>>> >> To be clear: this wasn't an outdated comment here, I'm using GitHub >>>> very frequently *right now* as I'm reviewing contributions to TensorFlow. >>>> >> >>>> >>> >>>> >>> >>>> >>> I also believe there's significant value for newcomers and casual >>>> contributors (like myself) in using the same tool as so many other major >>>> open source projects. >>>> >>> >>>> >>> On Fri, Jun 19, 2020 at 13:04 Mehdi AMINI via llvm-dev < >>>> llvm-dev at lists.llvm.org> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Jun 19, 2020 at 9:56 AM Hubert Tong via llvm-dev < >>>> llvm-dev at lists.llvm.org> wrote: >>>> >>>>> >>>> >>>>> On Fri, Jun 19, 2020 at 12:32 PM Anton Korobeynikov via llvm-dev < >>>> llvm-dev at lists.llvm.org> wrote: >>>> >>>>>> >>>> >>>>>> Just my 2 cents here: we are working on enabling this as a part >>>> of >>>> >>>>>> bugzilla migration as PRs and issues are very tied inside >>>> GitHub. Stay >>>> >>>>>> tuned for updates! >>>> >>>>> >>>> >>>>> I am not aware that the previous long thread about usage of >>>> GitHub PRs in place of Phabricator reviews got anywhere near the point >>>> where the option of Phabricator reviews was being dropped >>>> >>>> >>>> >>>> >>>> >>>> That's my impression as well, I find GitHub review is frustrating >>>> in comparison to phab, in particular the way comments are handled across >>>> updates, unless you stick to never rebase and only append commits and >>>> merges from master. This is unfortunately not compatible with the LLVM repo >>>> history right now. >>>> >>>> >>>> >>>> https://www.phacility.com offers hosting for Phabricator, could >>>> we look into this instead? >>>> >>>> >>>> >>>> -- >>>> >>>> Mehdi >>>> >>>> >>>> >>>> >>>> >>>>> >>>> >>>>> . The original post on this thread indicated interest in not >>>> maintaining Phabricator. How does that affect the availability of >>>> Phabricator? Does this mean that the community is going to move to GitHub >>>> PRs because the choice of Phabricator is being taken away? >>>> >>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Fri, Jun 19, 2020 at 3:45 PM Manuel Klimek via llvm-dev >>>> >>>>>> <llvm-dev at lists.llvm.org> wrote: >>>> >>>>>> > >>>> >>>>>> > -Chris' outdated email, +Chris' correct email :) >>>> >>>>>> > >>>> >>>>>> > On Fri, Jun 19, 2020 at 2:01 PM Manuel Klimek < >>>> klimek at google.com> wrote: >>>> >>>>>> >> >>>> >>>>>> >> Hi folks, >>>> >>>>>> >> >>>> >>>>>> >> phabricator maintenance is a topic that has been lying >>>> dormant for a while now. >>>> >>>>>> >> >>>> >>>>>> >> That subsequently creates a non-optimal user experience. >>>> >>>>>> >> For me personally, given that github provides a secure PR >>>> infrastructure, the additional effort required to keep Phab going is not an >>>> investment I'm personally willing to make. I understand that there are >>>> unique selling points for Phab in its UI compared to github PRs, but there >>>> are also significant downsides in the effort to integrate with Phab that >>>> github PRs make easier. >>>> >>>>>> >> >>>> >>>>>> >> Thus, I see two options: >>>> >>>>>> >> 1. somebody volunteers to take on Phabricator maintenance and >>>> figures out a way to fund it, either through the LLVM foundation or some >>>> other means (I'd love for us at Google to pay for it directly and give >>>> folks outside Google access, but that is unfortunately a hard problem for a >>>> variety of reasons). I'd be happy to help to provide a DB snapshot for the >>>> migration, of course. >>>> >>>>>> >> >>>> >>>>>> >> 2. We switch to github PRs >>>> >>>>>> >> >>>> >>>>>> >> Thoughts? >>>> >>>>>> >> /Manuel >>>> >>>>>> >> >>>> >>>>>> >> >>>> >>>>>> >> On Thu, Jun 18, 2020 at 6:42 PM Raphael Isemann < >>>> teemperor at gmail.com> wrote: >>>> >>>>>> >>> >>>> >>>>>> >>> Friendly ping >>>> >>>>>> >>> >>>> >>>>>> >>> Am Do., 9. Apr. 2020 um 16:04 Uhr schrieb Alexandre Ganea >>>> >>>>>> >>> <alexandre.ganea at ubisoft.com>: >>>> >>>>>> >>> > >>>> >>>>>> >>> > cc Paul / MyDeveloperDay >>>> >>>>>> >>> > >>>> >>>>>> >>> > >>>> >>>>>> >>> > >>>> >>>>>> >>> > De : llvm-dev <llvm-dev-bounces at lists.llvm.org> De la >>>> part de David Blaikie via llvm-dev >>>> >>>>>> >>> > Envoyé : April 8, 2020 10:21 PM >>>> >>>>>> >>> > À : Raphael “Teemperor” Isemann <teemperor at gmail.com>; >>>> Manuel Klimek <klimek at google.com> >>>> >>>>>> >>> > Cc : llvm-dev <llvm-dev at lists.llvm.org> >>>> >>>>>> >>> > Objet : Re: [llvm-dev] Outdated Phabricator version on >>>> reviews.llvm.org breaks Google authentication since today >>>> >>>>>> >>> > >>>> >>>>>> >>> > >>>> >>>>>> >>> > >>>> >>>>>> >>> > hey Manuel - are you/do you know who's likely to be doing >>>> any upkeep on Phabricator these days? Might need an update for this... >>>> >>>>>> >>> > >>>> >>>>>> >>> > >>>> >>>>>> >>> > >>>> >>>>>> >>> > - Dave >>>> >>>>>> >>> > >>>> >>>>>> >>> > >>>> >>>>>> >>> > >>>> >>>>>> >>> > On Wed, Apr 8, 2020 at 5:57 AM Raphael “Teemperor” Isemann >>>> via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>>> >>>>>> >>> > >>>> >>>>>> >>> > Hi all, >>>> >>>>>> >>> > >>>> >>>>>> >>> > I’m using my Google account to log into my Phabricator >>>> account on reviews.llvm.org . Since today that no longer works as I >>>> don’t seem to get any reply from reviews.llvm.org when I’m logged into >>>> my account. It tried logging out which fixes the issue of >>>> reviews.llvm.org not loading, but when I try to login I just get the >>>> following error: >>>> >>>>>> >>> > >>>> >>>>>> >>> > > Expected to retrieve an "account" email from Google Plus >>>> API call to identify account, but failed. >>>> >>>>>> >>> > >>>> >>>>>> >>> > After some searching it seems that this error is due to >>>> the Google Plus API being shutdown and the Phabricator folks replaced that >>>> logic (including this error message string) a year ago here [1] >>>> >>>>>> >>> > >>>> >>>>>> >>> > I assume we haven’t updated reviews.llvm.org to whatever >>>> latest Phabricator release contains that patch. >>>> >>>>>> >>> > >>>> >>>>>> >>> > Not sure who’s currently responsible for updating >>>> reviews.llvm.org so I thought I’ll just drop a mail to the list (and >>>> maybe save someone else from figuring out why their login is suddenly >>>> broken). >>>> >>>>>> >>> > >>>> >>>>>> >>> > [1] https://secure.phabricator.com/D20030 >>>> >>>>>> >>> > _______________________________________________ >>>> >>>>>> >>> > LLVM Developers mailing list >>>> >>>>>> >>> > llvm-dev at lists.llvm.org >>>> >>>>>> >>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>>>>> > >>>> >>>>>> > _______________________________________________ >>>> >>>>>> > LLVM Developers mailing list >>>> >>>>>> > llvm-dev at lists.llvm.org >>>> >>>>>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> -- >>>> >>>>>> With best regards, Anton Korobeynikov >>>> >>>>>> Department of Statistical Modelling, Saint Petersburg State >>>> University >>>> >>>>>> _______________________________________________ >>>> >>>>>> LLVM Developers mailing list >>>> >>>>>> llvm-dev at lists.llvm.org >>>> >>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>>>> >>>> >>>>> _______________________________________________ >>>> >>>>> LLVM Developers mailing list >>>> >>>>> llvm-dev at lists.llvm.org >>>> >>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> LLVM Developers mailing list >>>> >>>> llvm-dev at lists.llvm.org >>>> >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>> >>>> >>> -- >>>> >>> -- >>>> >>> Keith Smiley >>>> >> >>>> >> _______________________________________________ >>>> >> LLVM Developers mailing list >>>> >> llvm-dev at lists.llvm.org >>>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> > >>>> > _______________________________________________ >>>> > LLVM Developers mailing list >>>> > llvm-dev at lists.llvm.org >>>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > _______________________________________________ > cfe-dev mailing listcfe-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200623/e5ff2f58/attachment-0001.html>
Chris Lattner via llvm-dev
2020-Jun-24 05:53 UTC
[llvm-dev] [cfe-dev] Phabricator Maintenance
> On Jun 23, 2020, at 10:56 AM, Philip Reames via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > On 6/22/20 2:34 AM, Manuel Klimek via llvm-dev wrote: >> On Sat, Jun 20, 2020 at 1:45 AM Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> There’s also some feature regressions in GH vs Phab. >> >> You *must* initiate a review via a pull request, and pull request by definition compares your working copy against master. >> >> This is not very compatible with LLVMs approach to incremental development. For example, if you ask someone to break a large patch into 5 smaller patches, with Phab this is very easy because you can upload the diff between N and N+1, then N+1 and N+2, etc. >> >> But with the GH workflow in order to get a review on N+4 you have to include all the changes from all the earlier revisions as well. >> >> The way around this is to fork and make 5 branches in your fork, then base each branch off the previous one. But now what do you do if someone requests a change on the first one? >> >> Overall it’s a pretty serious limitation if you’re used to Phab, and I would evaluate very carefully if you’re thinking of going this route >> >> Are you volunteering to drive Phab maintenance and keep it up & running? > This really seems like a question for the board, rather than any individual. If you're resigning and the community values phab, having the board weigh in on cost to support the tool seems worthwhile. I suspect that cost will be high enough that we will migrate to something free, but we should at least have an informed discussion. > > (In case it's not clear, "cost" above is specifically meant in both the financial and non-financial sense. This might be a case where a contractor is worth considering instead of relying solely on volunteer labor.) >I’m not speaking on behalf of the board, I am just sharing my personal opinion here: I *really* like the Phabricator workflow in practice - I feel like it fits very nicely with the LLVM development model and aside from some super minor UI squabbles, it seems to work great in practice. I am really thankful that Manuel and others made this happen over the years, it was a huge step up from where we were. That said, I can’t see a world in which it makes sense to maintain this, particularly in the absence of a dedicated team that will do ongoing security and other maintenance. Having such critical project infrastructure on shaky maintenance grounds is a huge liability, and we’ve had Phab go down briefly in the past. Furthermore, LLVM having bespoke infra like this is a burden for new people and contributors, because they have to learn our way of doing things. The Github workflows (particularly PRs and the review workflow) are widely adopted across a ton of projects, including those that are larger than LLVM and have a dedicated team (GitHub) that maintain and evolve them. While using GitHub loses us the ability to have full control over the stack, we gain by focusing our limited admin cycles on other infra that is more important to us. I fully support the move to GitHub PR flow. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200623/fe1a4588/attachment.html>
Mehdi AMINI via llvm-dev
2020-Jun-24 16:28 UTC
[llvm-dev] [cfe-dev] Phabricator Maintenance
On Wed, Jun 24, 2020 at 2:31 AM Chris Lattner via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > > On Jun 23, 2020, at 10:56 AM, Philip Reames via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > > On 6/22/20 2:34 AM, Manuel Klimek via llvm-dev wrote: > > On Sat, Jun 20, 2020 at 1:45 AM Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> There’s also some feature regressions in GH vs Phab. >> >> You *must* initiate a review via a pull request, and pull request by >> definition compares your working copy against master. >> >> This is not very compatible with LLVMs approach to incremental >> development. For example, if you ask someone to break a large patch into 5 >> smaller patches, with Phab this is very easy because you can upload the >> diff between N and N+1, then N+1 and N+2, etc. >> >> But with the GH workflow in order to get a review on N+4 you have to >> include all the changes from all the earlier revisions as well. >> >> The way around this is to fork and make 5 branches in your fork, then >> base each branch off the previous one. But now what do you do if someone >> requests a change on the first one? >> >> Overall it’s a pretty serious limitation if you’re used to Phab, and I >> would evaluate very carefully if you’re thinking of going this route >> > > Are you volunteering to drive Phab maintenance and keep it up & running? > > This really seems like a question for the board, rather than any > individual. If you're resigning and the community values phab, having the > board weigh in on cost to support the tool seems worthwhile. I suspect > that cost will be high enough that we will migrate to something free, but > we should at least have an informed discussion. > > (In case it's not clear, "cost" above is specifically meant in both the > financial and non-financial sense. This might be a case where a contractor > is worth considering instead of relying solely on volunteer labor.) > > I’m not speaking on behalf of the board, I am just sharing my personal > opinion here: > > > I *really* like the Phabricator workflow in practice - I feel like it fits > very nicely with the LLVM development model and aside from some super minor > UI squabbles, it seems to work great in practice. I am really thankful > that Manuel and others made this happen over the years, it was a huge step > up from where we were. > > That said, I can’t see a world in which it makes sense to maintain this, > particularly in the absence of a dedicated team that will do ongoing > security and other maintenance. Having such critical project > infrastructure on shaky maintenance grounds is a huge liability, and we’ve > had Phab go down briefly in the past. >This can be addressed by going to a professional hosting for Phabricator though.> > Furthermore, LLVM having bespoke infra like this is a burden for new > people and contributors, because they have to learn our way of doing > things. The Github workflows (particularly PRs and the review workflow) > are widely adopted across a ton of projects, including those that are > larger than LLVM and have a dedicated team (GitHub) that maintain and > evolve them. While using GitHub loses us the ability to have full control > over the stack, we gain by focusing our limited admin cycles on other infra > that is more important to us. > >I'm sympathetic and in general supportive of standardizing our workflows and tools on what's the most common in the industry (GitHub for example), but I'm also cautious about preserving the quality of our workflow: code-review is a key part of the development and one of the difficult things to handle in general. I consider the review to be quite a critical part and sensitive part of the development process and I would expect very strong consideration before settling for an inferior solution. The past thread on Pull-request led us to discuss asking GitHub for missing features we have in Phab and ask for a roadmap on implementing them before commiting to a migration. When I looked into this possibility (GitHub PR) when we merged MLIR in the monorepo: just Herald rules was already a blocker and I couldn't find a replacement readily available on GitHub. The handling of stack of revisions on GitHub was another problem mentioned. Best, -- Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200624/d5b3ba5a/attachment.html>