[lldb-dev] How soon after the GitHub migration should committing with git-llvm become optional?

[Tom Stellard via lldb-dev]

Hi,

I mentioned this in my email last week, but I wanted to start a new
thread to get everyone's input on what to do about the git-llvm script
after the GitHub migration.

The original plan was to require the use of the git-llvm script when
committing to GitHub even after the migration was complete.
The reason we decided to do this was so that we could prevent developers
from accidentally pushing merge commits and making the history non-linear.

Just in the last week, the GitHub team completed the "Require Linear
History" branch protection, which means we can now enforce linear
history server side and do not need the git-llvm script to do this.

With this new development, the question I have is when should the
git-llvm script become optional?  Should we make it optional immediately,
so that developers can push directly using vanilla git from day 1, or should we
wait a few weeks/months until things have stabilized to make it optional?

Thanks,
Tom




 
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] How soon after the GitHub migration should committing with git-llvm become optional?

[David Zarzycki via lldb-dev]

I’d like to see it go away. For better and for worse, git is feature rich and 
that makes maintaining a wrapper script difficult. Personally speaking, I had 
to fix a git-llvm bug recently because it made flimsy assumptions about git 
remote names and how upstream tracking repositories work.

> On Oct 15, 2019, at 10:47 AM, Marcus Johnson via llvm-dev 
>  wrote:
> 
> I say retire it instantly.
> 
>> On Oct 15, 2019, at 3:14 AM, Tom Stellard via cfe-dev 
>>  wrote:
>> 
>> Hi,
>> 
>> I mentioned this in my email last week, but I wanted to start a new
>> thread to get everyone's input on what to do about the git-llvm script
>> after the GitHub migration.
>> 
>> The original plan was to require the use of the git-llvm script when
>> committing to GitHub even after the migration was complete.
>> The reason we decided to do this was so that we could prevent developers
>> from accidentally pushing merge commits and making the history non-linear.
>> 
>> Just in the last week, the GitHub team completed the "Require Linear
>> History" branch protection, which means we can now enforce linear
>> history server side and do not need the git-llvm script to do this.
>> 
>> With this new development, the question I have is when should the
>> git-llvm script become optional?  Should we make it optional immediately,
>> so that developers can push directly using vanilla git from day 1, or should 
>> we
>> wait a few weeks/months until things have stabilized to make it optional?
>> 
>> Thanks,
>> Tom
>> 
>> 
>> 
>> 
>> 
>> ___
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: cfe-dev  On Behalf Of Renato Golin
> via cfe-dev
> Sent: Friday, October 11, 2019 11:24 AM
> To: David Greene 
> Cc: llvm-...@lists.llvm.org; cfe-...@lists.llvm.org; Gerolf Hoflehner
> ; openmp-...@lists.llvm.org; lldb-dev@lists.llvm.org
> Subject: Re: [cfe-dev] [llvm-dev] RFC: End-to-end testing
> 
> Hi David,
> 
> You answer some of your own questions down below, so I'll try to
> collate the responses and shorten my reply.
> 
> On Fri, 11 Oct 2019 at 15:20, David Greene  wrote:
> > How are regressions reported?  On llvm-dev?
> 
> They're buildbots, exactly like any other. Direct email, llvm-commits,
> irc, bugzilla. There is no distinction, broken bots need to be fixed.
> 
> llvm-dev is not the place to report bugs.
> 
> > I'm confused.  On the one hand you say you don't want to put e2e tests
> > in a dark corner, but here you speculate they could be easily removed.
> > Presumably a test was added because there was some failure that other
> > tests did not catch.  It's true that once a test is fixed it's very
> > likely it will never break again.  Is that a reason to remove tests?
> 
> Sorry, my point is about the dynamics between number of tests, their
> coverage, time to run, frequency of *unrelated* breakage, etc.
> 
> There are no set rules, but there is a back-pressure as developers and
> bot owners tend to breakages.
> 
> > What do you mean by "annoy?"  Taking too long to run?
> 
> Tests that break more often are looked at more often, and if their
> breakages overlap with other simpler tests, than developers will begin
> to question their importance. Tests that take too long to run will be
> looked into, and if they don't add much, they can be asked for
> removal. That pressure is higher in the LIT side than in the
> test-suite.
> 
> I'm trying to find a place where we can put the tests that will run at
> the appropriate frequency and have the lowest probability of upsetting
> CI and developers, so we can evolve them into what they *need* to be,
> not cap it from the start and end up with something sub-par.
> 
> > Would it be possible to keep them in the monorepo but have bots that
> > exercise those tests at the test-suite frequency?  I suspect that if e2e
> > tests live in test-suite very few people will ever run them before
> > merging to master.
> 
> Bots are pretty dumb: either they run something or they don't.
> 
> But more importantly, if we split the e2e tests in LIT, then people
> won't run them before merging to master anyway.

Depends on whether they are part of check-all.

> Truth is, we don't *need* to. That's the whole point of having a fast
> CI and the community really respects that.
> 
> As long as we have the tests running every few dozen commits, and bot
> owner and developers work to fix them in time, we're good.
> 
> Furthermore, the test-suite already has e2e tests in there, so it is
> the right place to add more. We can have more control of which tools
> and libraries to use, how to check for quality, etc.

My understanding is that test-suite had large-ish executable tests.
David is talking about small compile-only e2e tests.  These would hardly
take any more time than any other existing lit test.

> > I still think the kinds of e2e tests I'm thinking of are much closer to
> > the existing LIT tests in the monorepo than things in test-suite.  I
> > expect them to be quite small.
> 
> Adding tests to LIT means all fast bots will be slower. Adding them to
> the test-suite means all test-suite bots will still take the about
> same time.
> 
> If the tests only need to be ran once ever few dozen commits, then
> having them on LIT is clearly not the right place.

The lit-versus-test-suite distinction is not the right one.  Bots don't
run "lit tests" as one big lump; they run the tests for a configured set
of projects.  If the e2e tests are in with all the other clang tests, 
then they get run by the clang bots.  If they are in a different project 
(test-suite or their own) then they get run by the bots that run that 
project.  This is decided by the bot owner.

> 
> > They wouldn't necessarily need to run as
> > part of check-all (and indeed, I've been told that no one runs check-all
> > anyway because it's too fragile).
> 
> check-all doesn't need to check everything that is in the repo, but
> everything that is built.
> 
> So if you build llvm+clang, then you should *definitely* check both.
> "make check" doesn't do that.
> 
> With the monorepo this may change slightly, but we still need a way to
> test everything that our patches touch, including clang, rt, and
> others.
> 
> I always ran check-all before every patch, FWIW.

Yep.  Although I run check-all before *starting* on a patch, to make sure
the starting point is clean.  It usually is, but I've been caught enough
times to be slightly wary.
--paulr

> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing

[Renato Golin via lldb-dev]

Hi Paul,

I'm not to strongly opposing to anything, and I don't want to be the
noisy one in the corner. :)

The only point I have is that it's easier to control the environment
in the TS and e2e tests are supposed to catch higher level problems
that cannot be handled in Clang.

We already have tests in clang that check for diagnostics, IR and
other things. Expanding those can handle 99.9% of what Clang could
possibly do without descending into assembly.

Assembly errors are more complicated than just "not generating VADD",
and that's easier done in the TS than LIT.

On Tue, 15 Oct 2019 at 15:55, Robinson, Paul  wrote:
> Yep.  Although I run check-all before *starting* on a patch, to make sure
> the starting point is clean.  It usually is, but I've been caught enough
> times to be slightly wary.

Ah! yes! Been there, too. :)
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] How soon after the GitHub migration should committing with git-llvm become optional?

[Tom Stellard via lldb-dev]

On 10/15/2019 12:20 AM, Roman Lebedev wrote:
> On Tue, Oct 15, 2019 at 10:14 AM Tom Stellard via cfe-dev
>  wrote:
>>
>> Hi,
>>
>> I mentioned this in my email last week, but I wanted to start a new
>> thread to get everyone's input on what to do about the git-llvm script
>> after the GitHub migration.
>>
>> The original plan was to require the use of the git-llvm script when
>> committing to GitHub even after the migration was complete.
>> The reason we decided to do this was so that we could prevent developers
>> from accidentally pushing merge commits and making the history non-linear.
>>
>> Just in the last week, the GitHub team completed the "Require Linear
>> History" branch protection, which means we can now enforce linear
>> history server side and do not need the git-llvm script to do this.
> 
> What about prevention of new branch creation?
> From the bugzilla disscussion, i gather that is not possible to do via github?
> 

Correct, but the git-llvm script can only prevent people from creating new
branches if they use the script.  Someone could still create a new branch
using `git push`.   We can use branch protections to prevent pushing to
existing branches but not for preventing new ones.

-Tom



>> With this new development, the question I have is when should the
>> git-llvm script become optional?  Should we make it optional immediately,
>> so that developers can push directly using vanilla git from day 1, or should 
>> we
>> wait a few weeks/months until things have stabilized to make it optional?
>>
>> Thanks,
>> Tom
> Roman
> 
>> ___
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] How soon after the GitHub migration should committing with git-llvm become optional?

[Tom Stellard via lldb-dev]

On 10/15/2019 11:51 AM, Lei Huang wrote:
> On 10/15/2019 12:20 AM, Roman Lebedev wrote:
>> On Tue, Oct 15, 2019 at 10:14 AM Tom Stellard via cfe-dev
>>  wrote:
>>>
>>> Hi,
>>>
>>> I mentioned this in my email last week, but I wanted to start a new
>>> thread to get everyone's input on what to do about the git-llvm script
>>> after the GitHub migration.
>>>
>>> The original plan was to require the use of the git-llvm script when
>>> committing to GitHub even after the migration was complete.
>>> The reason we decided to do this was so that we could prevent developers
>>> from accidentally pushing merge commits and making the history non-linear.
>>>
>>> Just in the last week, the GitHub team completed the "Require Linear
>>> History" branch protection, which means we can now enforce linear
>>> history server side and do not need the git-llvm script to do this.
>>
>> What about prevention of new branch creation?
>> From the bugzilla disscussion, i gather that is not possible to do via 
>> github?
>>
> 
> Correct, but the git-llvm script can only prevent people from creating new
> branches if they use the script.  Someone could still create a new branch
> using `git push`.   We can use branch protections to prevent pushing to
> existing branches but not for preventing new ones.
> 
> -Tom
> 
> Maybe I missed something, but the git doc seem to indicate we can setup a 
> server
> side pre-receive hook.  Can we not use this to prevent users from creating a 
> new branch?
> 

GitHub only supports pre-receive hooks in their Enterprise Server edition,
which isn't a good option for us, because we would need to self-host it.

-Tom

 
> - Lei
> 
>>> With this new development, the question I have is when should the
>>> git-llvm script become optional?  Should we make it optional immediately,
>>> so that developers can push directly using vanilla git from day 1, or 
>>> should we
>>> wait a few weeks/months until things have stabilized to make it optional?
>>>
>>> Thanks,
>>> Tom
>> Roman
>>
>>> ___
>>> cfe-dev mailing list
>>> cfe-...@lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev 
> 
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev 
>  
>  
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub Migration Schedule and Plans

[James Y Knight via lldb-dev]

On Thu, Oct 10, 2019 at 4:15 PM Jordan Rupprecht via llvm-dev <
llvm-...@lists.llvm.org> wrote:

>
>
> On Thu, Oct 10, 2019 at 12:29 PM Tom Stellard via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> On 10/10/2019 11:40 AM, Mehdi AMINI wrote:
>> >
>> >
>> > On Thu, Oct 10, 2019 at 10:59 AM Tom Stellard > > wrote:
>> >
>> > On 10/09/2019 11:05 PM, Mehdi AMINI wrote:
>> > >
>> > >
>> > > On Wed, Oct 9, 2019 at 10:16 PM Tom Stellard via cfe-dev <
>> cfe-...@lists.llvm.org  > cfe-...@lists.llvm.org >> wrote:
>> > >
>> > > Hi,
>> > >
>> > > We're less than 2 weeks away from the developer meeting, so I
>> wanted to
>> > > give an update on the GitHub migration and what's (hopefully)
>> going to
>> > > happen during the developer meeting.
>> > >
>> > > Everyone who has added their information to the
>> github-usernames.txt
>> > > file in SVN before today should have received an invite to
>> become a collaborator
>> > > on the llvm-project repository.  If you did not receive an
>> invite and think
>> > > you should have, please contact me off-list.  I will continue
>> to monitor the
>> > > file for new updates and periodically send out new batches of
>> invites.
>> > >
>> > > There is still some ongoing work to get the buildbots ready
>> and the mailing lists
>> > > ready, but we are optimistic that the work will be done in
>> time.
>> > >
>> > > The team at GitHub has finished implementing the "Require
>> Linear History"
>> > > branch protection that we requested.  The feature is in beta
>> and currently
>> > > enabled in the llvm-project repository.  This means that we
>> will have the
>> > > option to commit directly via git, in addition to using the
>> git-llvm script.
>> > > A patch that updates git-llvm to push to git instead of svn
>> can be found here:
>> > > https://reviews.llvm.org/D67772.  You should be able to test
>> it out on your
>> > > own fork of the llvm-project repository.
>> > >
>> > > The current plan is to begin the final migration steps on the
>> evening (PDT)
>> > > of October 21.  Here is what will happen:
>> > >
>> > > 1. Make SVN read-only.
>> > > 2. Turn-off the SVN->git update process.
>> > > 3. Commit the new git-llvm script directly to github.
>> > > 4. Grant all contributors write access to the repository.
>> > >
>> > >
>> > > Is the repo configured to forbid contributors to create new
>> branches? I'm worried about the "jungle" it can become quickly if we leave
>> open the possibility to create branches "at will" in the repo, I rather
>> leave this to maintainers.
>> > >
>> >
>> > I haven't been able to find a way to restrict branch creation for
>> committers,
>> > I'm not sure if this is even possible.
>> >
>> >
>> > I think you can just go to the branch settings, add a new branch
>> protection rule, match on everything but master, and check "Restrict who
>> can push to matching branches".
>> >
>>
>> I tried this, and the branch protections only come into effect after a
>> branch
>> has been creating, so this doesn't prevent new branches.  It's actually
>> worse
>> than doing nothing, because once the branch is created the branch
>> protection
>> prevents you from deleting it.
>>
>> -Tom
>>
>
> FWIW, we're interested in periodically (weekly) tagging well-tested/stable
> revisions, but via a branch instead of just a tag so we can include which
> cherrypicks (e.g. reverts or fixes) are needed. We do this with the current
> svn repo so we'd just be porting existing functionality to github.
>
> (Also, I'm not sure this announcement thread with all the *-dev lists is
> the best place to discuss branching policy, but I wanted to get this bit in
> since y'all brought it up :) )
>

IMO -- we should generally discourage random developer branches, and
instead encourage people to fork the repo and do their work there. But I'd
concur that it's not so big a concern as to require it to be prohibited via
tooling, since they're easily removable. I can imagine some cases where a
temporary dev branch in the main repo might be appropriate to use, and it'd
be nice not to prohibit such a valid use.

With regards to these sorts of "vendor release branches", though -- I'm
strongly against putting those in the main repo. That usage would certainly
be best handled with a separate Google "fork" of the llvm-project
repository -- and similarly for anyone else who wants to do it. Putting
such branches into the main llvm repo means that everyone pulling it pulls
down all the google release branches by default, which is really
unnecessary clutter (check out
https://github.com/llvm/llvm-project-legacy-branches if you'd like to see
what such clutter starts to look li

[lldb-dev] Mailing list changes this week

[Tom Stellard via lldb-dev]

Hi,

We are going to start to switching from SVN commit emails to GitHub commit
emails this week.  The only real change you should notice is that
the revision number in the subject will be replaced with a git hash and
the diff links in the email will point to GitHub.  Otherwise the
content and format of the email should be the same.

We are going to start by rolling this out for the openmp-commits list
and then once that's working begin migrating the rest of the lists.  If you
notice any issues with the new emails, please file a bug and mark it
as a blocker of the github meta-bug (llvm.org/PR39393).

Thanks,
Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] Mailing list changes this week

[Tom Stellard via lldb-dev]

On 10/15/2019 09:24 PM, Mehdi AMINI wrote:
> Hi Tom.
> 
> One issue with this is that we don't have a clear "ordering" from linear 
> revision numbers from these emails. Have we looked into continuing to 
> generate our own emails per commits instead so that we control the format?
> 

This actually what we are doing, we are listening for github commit events and
then generating our own emails based on the data in the event.  We can format
the emails how ever we want, and we tried to match the current SVN format 
exactly.
Is the some other information you would like to have in the emails to show the
ordering?

-Tom

> Thanks,
> 
> -- 
> Mehdi
> 
> 
> 
> On Tue, Oct 15, 2019 at 9:07 PM Tom Stellard via cfe-dev 
> mailto:cfe-...@lists.llvm.org>> wrote:
> 
> Hi,
> 
> We are going to start to switching from SVN commit emails to GitHub commit
> emails this week.  The only real change you should notice is that
> the revision number in the subject will be replaced with a git hash and
> the diff links in the email will point to GitHub.  Otherwise the
> content and format of the email should be the same.
> 
> We are going to start by rolling this out for the openmp-commits list
> and then once that's working begin migrating the rest of the lists.  If 
> you
> notice any issues with the new emails, please file a bug and mark it
> as a blocker of the github meta-bug (llvm.org/PR39393 
> ).
> 
> Thanks,
> Tom
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org 
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] Mailing list changes this week

[Tom Stellard via lldb-dev]

On 10/15/2019 09:44 PM, Mehdi AMINI wrote:
> 
> 
> On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard  > wrote:
> 
> On 10/15/2019 09:24 PM, Mehdi AMINI wrote:
> > Hi Tom.
> >
> > One issue with this is that we don't have a clear "ordering" from 
> linear revision numbers from these emails. Have we looked into continuing to 
> generate our own emails per commits instead so that we control the format?
> >
> 
> This actually what we are doing, we are listening for github commit 
> events and
> then generating our own emails based on the data in the event.  We can 
> format
> the emails how ever we want, and we tried to match the current SVN format 
> exactly.
> 
> 
> Ah great!
>  
> 
> Is the some other information you would like to have in the emails to 
> show the
> ordering?
> 
> 
> The only thing I was looking to get was to continue to have a monotonic 
> incrementing integer for the revision instead of the git hash alone: I don't 
> know if `git llvm` has this feature yet but this was discussed a while ago (I 
> don't remember if we just mentioned counting the commits in the repo from the 
> beginning or using an invocation of `git describe` or something derived).
> 

We talked about using `git describe` for this, but this would require that we
add tags to the master branch each time the version number was bumped.  We
discussed this[1] last year, but deferred the decision, since we couldn't get
consensus on the tag name.

-Tom

[1] http://lists.llvm.org/pipermail/llvm-dev/2018-December/128484.html

> -- 
> Mehdi
> 
>  
> 
> 
> -Tom
> 
> > Thanks,
> >
> > --
> > Mehdi
> >
> >
> >
> > On Tue, Oct 15, 2019 at 9:07 PM Tom Stellard via cfe-dev 
> mailto:cfe-...@lists.llvm.org> 
> >> wrote:
> >
> > Hi,
> >
> > We are going to start to switching from SVN commit emails to GitHub 
> commit
> > emails this week.  The only real change you should notice is that
> > the revision number in the subject will be replaced with a git hash 
> and
> > the diff links in the email will point to GitHub.  Otherwise the
> > content and format of the email should be the same.
> >
> > We are going to start by rolling this out for the openmp-commits 
> list
> > and then once that's working begin migrating the rest of the lists. 
>  If you
> > notice any issues with the new emails, please file a bug and mark it
> > as a blocker of the github meta-bug (llvm.org/PR39393 
>  ).
> >
> > Thanks,
> > Tom
> > ___
> > cfe-dev mailing list
> > cfe-...@lists.llvm.org  
> >
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev