Re: [lldb-dev] [cfe-dev] 13.0.1 Release Update

[Anton Korobeynikov via lldb-dev]

And for the record, here is the milestone:
https://github.com/llvm/llvm-project/milestone/2

On Fri, Dec 17, 2021 at 5:58 AM Tom Stellard via cfe-dev
 wrote:
>
> Hi,
>
> I'm back on track with the release after the buzilla migration, so I'm
> going to accept backport requests until Monday, Dec 20, and then
> I'll try to tag -rc2 on Wed Dec 21.
>
> If you have patches you want backported to the release/13.x branch, please
> file an issue and add it to the "LLVM 13.0.1 release" milestone.
>
> Also, if you emailed me a backport request and haven't seen an issue created 
> for
> it yet, please ping me on the email thread, so I don't forget about it.
>
> -Tom
>
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] Bugzilla / GitHub migration: username request

[Anton Korobeynikov via lldb-dev]

Hi Paul

> I'm hoping it's not a requirement that the GitHub account knows
> the same email addresses that Bugzilla knows.  Sony has assigned me
> 3 different addresses over time; Bugzilla knows the older two, and
> GitHub knows only the most recent one.
Correct. And we do not care about emails on github side as everything
should be associated with github username, not email.
So, we just need to know the mapping between bugzilla email and the
corresponding github username, not email.

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Bugzilla / GitHub migration: username request

[Anton Korobeynikov via lldb-dev]

Dear All,

As you might know, LLVM Foundation is working on migrating the data
that is currently residing in Bugzilla at http://bugs.llvm.org into
LLVM GitHub project repository. The ultimate goal is to shut down the
Bugzilla instance and allow the use of GitHub issues and pull requests
across LLVM repositories. We hope that this will lower the bar for
newer contributors and allow much smoother user experience than we're
having now.

Unfortunately, this is not an easy task and several valid (legal)
concerns with respect to the procedure, process and content were
raised in the past. The LLVM Foundation together with lawyers is
working on resolving them and now it's time for the next step of this
migration: the username mapping. Bugzilla uses email addresses as
usernames and GitHub operates solely via github usernames. There is no
way to associate an email with github username in automatic way, so we
are asking you to fill in the survey above:

https://forms.gle/tNg86K6T7y2YfsBx9

I would appreciate if this from will be filled by April, 30

Q:

Q: How will this data be used?
A: This email - username mapping will be used by the LLVM Foundation
solely for the purposes of the Bugzilla migration process and will be
deleted as soon as migration will finish.

Q: What will happen if I will not provide email - username mapping?
A: All data produced by unidentified users will be anonymized during
the migration, so there will be no way to attribute data to a
particular github username

Q: What if I cannot use the form above for some reason?
A: Please email LLVM Foundation Board your bugzilla username (email)
and your github username. By receiving this data it will be assumed
that you will be giving permission to the LLVM Foundation to migrate
all the data created by you in LLVM Bugzilla database under the
account(s) you sent to the Github issues in the LLVM project
repository.

Thanks,

On behalf of the LLVM Foundation,
Anton Korobeynikov
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Google Summer of Code Call for Projects

[Anton Korobeynikov via lldb-dev]

Dear all,

This year as usual we are planning to submit our application to
participate in the Google Summer of Code program. However, the
application is not possible without the list of tentative projects.
So, please consider adding your project ideas to the Open Projects
page at: https://llvm.org/OpenProjects.html#gsoc21 I would appreciate
it if this would be done within this week, if possible.

Please note a few things:
  - The overall duration of the program (in hours) is shorter this
year. Students are expected to do 175-hour projects
  - Listing some prerequisites for some projects could be a good idea
to shorten the ramp-up period

Here is the whole program timeline:
https://developers.google.com/open-source/gsoc/timeline

Thanks!

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
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] Renaming The Default Branch

[Anton Korobeynikov via lldb-dev]

Hi Martin,

It seems it's in the `master` branch:
https://github.com/llvm/llvm-project/commit/78a57069b53a08d5aef98a8472fcfa73dbbc8771

So, is the problem resolved?

On Mon, Dec 7, 2020 at 11:12 AM Martin Storsjö via cfe-dev
 wrote:
>
> Hi,
>
> On Sun, 6 Dec 2020, Mike Edwards via llvm-dev wrote:
>
> > The change to the default branch setting has been completed.  The new
> > default branch for the llvm-project is now 'main'.  Pushes to the 'master'
> > branch will no longer be accepted.  Please update your workflow to use the
> > new 'main' branch.  Thank you for your patience and cooperation during this
> > process.  I hope everyone has a nice, productive day.
>
> I just pushed a patch to the new main branch, and I've noticed these
> issues:
>
> - The master branch isn't updated to reflect this. Afaik it was supposed
> that the master branch, while read only, would still receive updates until
> it's being discontinued - or did I misunderstand that bit?
>
> - Phabricator doesn't seem to pick up on commits to master, and doesn't
> autoclose reviews based on pushed patches. I guess this would be fixed by
> either making it track the main branch, or if new commits are mirrored
> into the previous branch until Phabricator is switched?
>
> // Martin
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Changes to 2021 GSoC program

[Anton Korobeynikov via lldb-dev]

Dear All,

TL;DR: It is expected for the projects to be shorter, but more spread
over the summer.

Google recently announced major changes into their program for the
next year. Here is the excerpt:

1. Smaller project size - all students participating in the 2021
program will be working on a 175 hour project (instead of a 350 hr
project). This change will also result in a few other changes
including the student stipend being cut in half.
2. Shortened coding period - the coding period will be 10 weeks with a
lot more flexibility for the mentor and student to decide together how
they want to spread the work out over the summer.
3. 2 evaluations  (instead of 3) - There will be an evaluation after 5
weeks and the final evaluation will take place after the 10th week.
The students are NO longer required to complete their first
evaluation, so if a student doesn’t complete the first evaluation they
will not automatically be removed from the program. They are still
required to complete the final evaluation.
4. Students are no longer strongly encouraged to focus only on GSoC
over their summer. Hence 2x shorter projects.

And please start thinking about possible topics and scope GSoC 2021 projects :)

Thanks!

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
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] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[Anton Korobeynikov via lldb-dev]

GitHub also supports custom prefixes for the issues. However, here is
another limitation: the prefix must be at least 3 letters, so we
cannot, for example, autolink PR1234 issues. Already asked whether
this restriction could be lifted.

On Wed, Apr 22, 2020 at 3:15 PM James Y Knight via llvm-dev
 wrote:
>
> GitHub canonically uses "#NNN" to refer to its bugs or pull requests, and 
> also supports "GH-NNN". We'll want to switch to one of those schemes, so that 
> automatic linking works properly. So, in that case, PR1234 == legacy issue, 
> #1234 or GH-1234 == new issue.
>
> (See 
> https://help.github.com/en/github/writing-on-github/autolinked-references-and-urls)
>
> On Tue, Apr 21, 2020, 10:43 PM Johannes Doerfert via cfe-dev 
>  wrote:
>>
>>
>> On 4/21/20 7:00 PM, Tom Stellard via llvm-dev wrote:
>> > On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote:
>> >> On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev 
>> >> mailto:cfe-...@lists.llvm.org>> wrote:
>> >>
>> >>  +1 to James's take
>> >>
>> >>  I'd prefer simplicity of implementation over perfection here.
>> >>
>> >> If we end up with two different bug numbering systems, that's a problem 
>> >> that we will be paying for for many years. It's worth some investment now 
>> >> to avoid that problem. And it doesn't seem like it really requires much 
>> >> investment.
>> >>
>> >> Here's another path we could take:
>> >>
>> >> 1) Fork the llvm repository to a private "bugs" repository. Mirror the 
>> >> bugzilla issues there. Iterate until we're happy, as per James's proposal.
>> >> 2) Sync the forked repository to the llvm repository, delete the llvm 
>> >> repository, rename "bugs" to "llvm", and make it public.
>> >>
>> >> Then we'll have the first N bugs in llvm-project/llvm being *exactly* the 
>> >> bugzilla bugs, and we'll have excised the existing github issues that we 
>> >> want to pretend never existed anyway.
>> >>
>> >>
>> >> I think we've missed an important step in the planning here: we've not 
>> >> agreed on a set of goals for the transition. Here are mine:
>> >>
>> >>   * We end up with one single issue tracking system containing all 
>> >> issues, both old and new, both open and closed.
>> >>   * All links and references to existing bugs still work.
>> >>   * We have a single bug numbering system covering all bugs, and old bugs 
>> >> retain their numbers.
>> > Why are the bug numbers important?  Could you help give some example use 
>> > cases that require having
>> > a non-intersecting set of bug numbers for bugzilla bugs and github issues?
>>
>>
>> While I have no experience in bugzilla or github tooling, the two step
>> process described by Richard doesn't seem to be very complicated.
>>
>>
>> As mentioned by others, we have commits and tests (and sometimes source
>> files) that explicitly mention bug numbers. I do regularly look up bugs
>> from a decade ago to determine if a test or some code still has
>> relevance or not. If PR3214 can be one of two bugs, it does not only
>> increase lookup time but also add confusion to everyone involved.
>>
>>
>> Cheers,
>>
>>Johannes
>>
>>
>>
>> > -Tom
>> >
>> >
>> >> It sounds like we don't all agree that the last point is important, but 
>> >> if we can achieve it without any significant additional cost, why not do 
>> >> so?
>> >>
>> >>  Philip
>> >>
>> >>  On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote:
>> >>>  In a previous discussion, one other suggestion had been to migrate 
>> >>> all the bugzilla bugs to a separate initially-private "bug archive" 
>> >>> repository in github. This has a few benefits:
>> >>>  1. If the migration is messed up, the repo can be deleted, and the 
>> >>> process run again, until we get a result we like.
>> >>>  2. The numbering can be fully-controlled.
>> >>>  Once the bugs are migrated to /some/ github repository, individual 
>> >>> issues can then be "moved" between repositories, and github will 
>> >>> redirect from the movefrom-repository's bug to the target repository's 
>> >>> bug.
>> >>>
>> >>>  We could also just have llvm.org/PR###  
>> >>> be the url only for legacy bugzilla issue numbers -- and have it use a 
>> >>> file listing the mappings of bugzilla id -> github id to generate the 
>> >>> redirects. (GCC just did this recently for svn revision number 
>> >>> redirections, https://gcc.gnu.org/pipermail/gcc/2020-April/232030.html).
>> >>>
>> >>>  Then we could introduce a new naming scheme for github issue 
>> >>> shortlinks.
>> >>>
>> >>>  On Mon, Apr 20, 2020 at 3:50 PM Richard Smith via llvm-dev 
>> >>> mailto:llvm-...@lists.llvm.org>> wrote:
>> >>>
>> >>>  On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev 
>> >>> mailto:llvm-...@lists.llvm.org>> wrote:
>> >>>
>> >>>  Hi,
>> >>>
>> >>>  I wanted to continue discussing the plan to migrate from 
>> >>> Bugzilla to Github.
>> >>>  It was suggested that I 

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[Anton Korobeynikov via lldb-dev]

Hi Konrad,

Thanks for the scripts – look useful! For the record, here is the
result of previous experiments
https://github.com/asl/llvm-bugzilla/issues

On Wed, Apr 22, 2020 at 2:21 PM Konrad Kleine via cfe-dev
 wrote:
>
> I wanted to try importing llvm bugs into a fresh github repo and here's my 
> result so far (import is still running): 
> https://github.com/kwk/test-llvm-bz-import-4 . I've written the scripts 
> (https://github.com/kwk/bz2gh) myself because I wanted to remain in control 
> and don't make my life more complicated than it needs to be. The README.md 
> describes in great length what's imported and how. For now I import the 
> bugzillas just as placeholder issues. Then I lock those issues in github to 
> avoid messing with them. Before I created labels based on 
> /. Those are assigned to each issue. It should give a 
> good start to at least reserve all github #IDs so they map 1:1 to LLVM BZs.
>
> On Wed, 22 Apr 2020 at 09:23, Dimitry Andric via cfe-dev 
>  wrote:
>>
>> Since Bugzilla numbers are all under 50,000 (at least for now:), can't we 
>> simply bump the GitHub issue/pull request numbers to 50,000, and start from 
>> there?
>>
>> Then it would be easy to identify: < 5 means Bugzilla, >= 5 means 
>> GitHub.
>>
>> Now somebody's only gotta find a way to file 5-200 bogus GitHub tickets. 
>> :)  (Or ask GitHub support to bump the number synthetically.)
>>
>> -Dimitry
>>
>> On 22 Apr 2020, at 09:10, James Henderson via cfe-dev 
>>  wrote:
>>
>> Similar to other people's experiences, I've worked on a common code base 
>> that supported three different platforms, and each platform used a different 
>> bugzilla with it's own numbering scheme. I regularly came across references 
>> to "BZ123456" with no indication as to which of the three systems that 
>> referred to. This would often mean having to go to each in turn and seeing 
>> if the corresponding bug looked like it had anything to do with the related 
>> topic. Fortunately, given that there were many other things using the same 
>> bugzilla instances, this was usually pretty clear, but not always. Typos in 
>> bug numbers sometimes made things even harder, since you had to spend three 
>> times as long trying to guess.
>>
>> In other words +1 to using unique numbers, however we do it.
>>
>> On Wed, 22 Apr 2020 at 03:44, Johannes Doerfert via cfe-dev 
>>  wrote:
>>>
>>>
>>> On 4/21/20 7:00 PM, Tom Stellard via llvm-dev wrote:
>>> > On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote:
>>> >> On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev 
>>> >> mailto:cfe-...@lists.llvm.org>> wrote:
>>> >>
>>> >>  +1 to James's take
>>> >>
>>> >>  I'd prefer simplicity of implementation over perfection here.
>>> >>
>>> >> If we end up with two different bug numbering systems, that's a problem 
>>> >> that we will be paying for for many years. It's worth some investment 
>>> >> now to avoid that problem. And it doesn't seem like it really requires 
>>> >> much investment.
>>> >>
>>> >> Here's another path we could take:
>>> >>
>>> >> 1) Fork the llvm repository to a private "bugs" repository. Mirror the 
>>> >> bugzilla issues there. Iterate until we're happy, as per James's 
>>> >> proposal.
>>> >> 2) Sync the forked repository to the llvm repository, delete the llvm 
>>> >> repository, rename "bugs" to "llvm", and make it public.
>>> >>
>>> >> Then we'll have the first N bugs in llvm-project/llvm being *exactly* 
>>> >> the bugzilla bugs, and we'll have excised the existing github issues 
>>> >> that we want to pretend never existed anyway.
>>> >>
>>> >>
>>> >> I think we've missed an important step in the planning here: we've not 
>>> >> agreed on a set of goals for the transition. Here are mine:
>>> >>
>>> >>   * We end up with one single issue tracking system containing all 
>>> >> issues, both old and new, both open and closed.
>>> >>   * All links and references to existing bugs still work.
>>> >>   * We have a single bug numbering system covering all bugs, and old 
>>> >> bugs retain their numbers.
>>> > Why are the bug numbers important?  Could you help give some example use 
>>> > cases that require having
>>> > a non-intersecting set of bug numbers for bugzilla bugs and github issues?
>>>
>>>
>>> While I have no experience in bugzilla or github tooling, the two step
>>> process described by Richard doesn't seem to be very complicated.
>>>
>>>
>>> As mentioned by others, we have commits and tests (and sometimes source
>>> files) that explicitly mention bug numbers. I do regularly look up bugs
>>> from a decade ago to determine if a test or some code still has
>>> relevance or not. If PR3214 can be one of two bugs, it does not only
>>> increase lookup time but also add confusion to everyone involved.
>>>
>>>
>>> Cheers,
>>>
>>>Johannes
>>>
>>>
>>>
>>> > -Tom
>>> >
>>> >
>>> >> It sounds like we don't all agree that the last point is important, but 
>>> >> if we can achieve it without any significant 

Re: [lldb-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[Anton Korobeynikov via lldb-dev]

Hi James,

> Please could we replace the "llvm-tools" with a single label for each LLVM 
> tool (i.e. labels for llvm-ar, llvm-as, llvm-cxxfilt, llvm-objdump etc etc).
Sorry, I missed the subcomponents for the tools when I did the
migration of the labels. Will add them!

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[Anton Korobeynikov via lldb-dev]

> On 04/20/2020 04:08 PM, James Y Knight wrote:
> > In a previous discussion, one other suggestion had been to migrate all the 
> > bugzilla bugs to a separate initially-private "bug archive" repository in 
> > github. This has a few benefits:
> > 1. If the migration is messed up, the repo can be deleted, and the process 
> > run again, until we get a result we like.
> > 2. The numbering can be fully-controlled.
> > Once the bugs are migrated to /some/ github repository, individual issues 
> > can then be "moved" between repositories, and github will redirect from the 
> > movefrom-repository's bug to the target repository's bug.
> This seems like a good approach to me.
This might work, yes.

There are some limitations as well, this is why I'm very cautious
here. See 
https://docs.google.com/document/d/1byEcbsxF3pL-HGGd_K6axdh87tbcsuJK3Dp6ThxGjKA/edit
for some list.

>
> > We could also just have llvm.org/PR###  be the url 
> > only for legacy bugzilla issue numbers -- and have it use a file listing 
> > the mappings of bugzilla id -> github id to generate the redirects. (GCC 
> > just did this recently for svn revision number redirections, 
> > https://gcc.gnu.org/pipermail/gcc/2020-April/232030.html).
> >
>
> Would we even need a mapping file for this if we are able to get bugzilla id N
> to be archived to GitHub issue id N?
>
> -Tom
>
> > Then we could introduce a new naming scheme for github issue shortlinks.
> >
> > On Mon, Apr 20, 2020 at 3:50 PM Richard Smith via llvm-dev 
> > mailto:llvm-...@lists.llvm.org>> wrote:
> >
> > On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev 
> > mailto:llvm-...@lists.llvm.org>> wrote:
> >
> > Hi,
> >
> > I wanted to continue discussing the plan to migrate from Bugzilla 
> > to Github.
> > It was suggested that I start a new thread and give a summary of 
> > the proposal
> > and what has changed since it was originally proposed in October.
> >
> > == Here is the original proposal:
> >
> > http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html
> >
> > == What has changed:
> >
> > * You will be able to subscribe to notifications for a specific 
> > issue
> >   labels.  We have a proof of concept notification system using 
> > github actions
> >   that will be used for this.
> >
> > * Emails will be sent to llvm-bugs when issues are opened or closed.
> >
> > * We have the initial list of labels: 
> > https://github.com/llvm/llvm-project/labels
> >
> > == Remaining issue:
> >
> > * There is one remaining issue that I don't feel we have consensus 
> > on,
> > and that is what to do with bugs in the existing bugzilla.  Here 
> > are some options
> > that we have discussed:
> >
> > 1. Switch to GitHub issues for new bugs only.  Bugs filed in 
> > bugzilla that are
> > still active will be updated there until they are closed.  This 
> > means that over
> > time the number of active bugs in bugzilla will slowly decrease as 
> > bugs are closed
> > out.  Then at some point in the future, all of the bugs from 
> > bugzilla will be archived
> > into their own GitHub repository that is separate from the 
> > llvm-project repo.
> >
> > 2. Same as 1, but also create a migration script that would allow 
> > anyone to
> > manually migrate an active bug from bugzilla to a GitHub issue in 
> > the llvm-project
> > repo.  The intention with this script is that it would be used to 
> > migrate high-traffic
> > or important bugs from bugzilla to GitHub to help increase the 
> > visibility of the bug.
> > This would not be used for mass migration of all the bugs.
> >
> > 3. Do a mass bug migration from bugzilla to GitHub and enable 
> > GitHub issues at the same time.
> > Closed or inactive bugs would be archived into their own GitHub 
> > repository, and active bugs
> > would be migrated to the llvm-project repo.
> >
> >
> > Can we preserve the existing bug numbers if we migrate this way? There 
> > are lots of references to "PRx" in checked in LLVM artifacts and 
> > elsewhere in the world, as well as links to llvm.org/PRx 
> > , and if we can preserve all the issue numbers 
> > this would ease the transition pain substantially.
> >
> >
> > The key difference between proposal 1,2 and 3, is when bugs will be 
> > archived from bugzilla
> > to GitHub.  Delaying the archiving of bugs (proposals 1 and 2) 
> > means that we can migrate
> > to GitHub issues sooner (within 1-2 weeks), whereas trying to 
> > archive bugs during the
> > transition (proposal 3) will delay the transition for a while 
> > (likely several months)
> > while we evaluate the various solutions for moving bugs from 
> > bugzilla to GitHub.
> >
> >
> > The original 

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[Anton Korobeynikov via lldb-dev]

> If we are reasonably certain that no one would be opening new issues on 
> GitHub while the migration is running...
And pull requests (the numbering is common for issues and pull
requests) as well. And we cannot disable pull requests at all. And I'm
afraid the issues will need to be opened as well during the migration.
And now the real problem: should an "extra" pull request or issue
intervene in the migration there is no way to "reset" the counter
besides deleting the project and creating it once again. We could only
sacrifice some bugzilla issues to restore the numbering...


-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[Anton Korobeynikov via lldb-dev]

Just to clarify a bit: what I wanted to say is that it's unlikely
that we will be able to ensure that bugzilla issue numbers after
migration would coincide with github issue numbers. And therefore
proper mapping will be necessary. And this mapping would be more
complex than just rewriting the URL.


On Mon, Apr 20, 2020 at 11:25 PM Anton Korobeynikov
 wrote:
>
> > Can we preserve the existing bug numbers if we migrate this way? There are 
> > lots of references to "PRx" in checked in LLVM artifacts and elsewhere 
> > in the world, as well as links to llvm.org/PRx, and if we can preserve 
> > all the issue numbers this would ease the transition pain substantially.
> Well... I hate to say this, but quite unlikely. Unfortunately, there
> were significant changes in GitHub opensource team and these days they
> are much less responsive than they used to be during our github
> migration. I asked this question several times, and unfortunately,
> there is no answer. I will certainly keep trying.
>
> The problem here is there is no way to assign / control issue numbers
> at all. They are just automatically assigned in sequential order.
> While it might be possible to utilize this while migrating everything
> to, say, a special archive project on GitHub, we will not be able to
> control the numbers assigned should we migrate the issues one-by-one
> or just move from archive to main project.
>
> So, the only viable way seems to be plain big mapping from bugzilla to
> github issue numbers without anything simple like "llvm.org/PRxx
> becomes https://github.com/llvm/llvm-project/issues/xx;.
>
>
> --
> With best regards, Anton Korobeynikov
> Department of Statistical Modelling, Saint Petersburg State University



--
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[Anton Korobeynikov via lldb-dev]

> Can we preserve the existing bug numbers if we migrate this way? There are 
> lots of references to "PRx" in checked in LLVM artifacts and elsewhere in 
> the world, as well as links to llvm.org/PRx, and if we can preserve all 
> the issue numbers this would ease the transition pain substantially.
Well... I hate to say this, but quite unlikely. Unfortunately, there
were significant changes in GitHub opensource team and these days they
are much less responsive than they used to be during our github
migration. I asked this question several times, and unfortunately,
there is no answer. I will certainly keep trying.

The problem here is there is no way to assign / control issue numbers
at all. They are just automatically assigned in sequential order.
While it might be possible to utilize this while migrating everything
to, say, a special archive project on GitHub, we will not be able to
control the numbers assigned should we migrate the issues one-by-one
or just move from archive to main project.

So, the only viable way seems to be plain big mapping from bugzilla to
github issue numbers without anything simple like "llvm.org/PRxx
becomes https://github.com/llvm/llvm-project/issues/xx;.


--
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] GSoC application submission deadline is tomorrow

[Anton Korobeynikov via lldb-dev]

Dear prospective GSoC students,

This is a reminder that GSoC application submission deadline is
tomorrow, so you're having slightly more than 24 hours in order to
review, finish, polish and finally submit your project proposal.

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLVM GSoC 2020

[Anton Korobeynikov via lldb-dev]

Dear Prospective GSoC students,

As you already know, the proposal submission process recently started
and will continue until March 31 (please see GSoC website for the
complete timeline).

While one can submit the proposal to GSoC system directly, we strongly
encourage to submit proposals for discussion into the corresponding
mailing lists (e.g. llvm-dev for LLVM related projects, cfe-dev for
clang, lldb-dev for LLDB and MLIR discourse for MLIR). Previous
experience shows that the review and discussions around the proposals
contribute greatly to their overall quality and drive the success of
the project should it be accepted.

In your proposal, besides the details of the project itself, its
timeline, etc. please also provide some additional information like:
  - Any prior experience to LLVM (e.g. patches submitted, courses that
use LLVM taken, any theses, etc)
  - Any prior experience in compiler and compiler-related technologies
  - What is your motivation to contribute to LLVM, why it is
interesting for you.

Thanks and good luck!

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
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] RFC: Switching from Bugzilla to Github Issues

[Anton Korobeynikov via lldb-dev]

Good idea. Let me ask for this.

On Sat, Feb 1, 2020 at 2:17 AM Fangrui Song via llvm-dev
 wrote:
>
> On 2020-01-30, Anton Korobeynikov via cfe-dev wrote:
> >> Will you be able to start numbering in github at a number larger than the 
> >> largest bug in bugzilla?  It would be annoying to have overlapping bug 
> >> numbers.  Bug numbers exist in code comments, list archives, etc., etc.  
> >> If someone reads 'clang bug #1234' somewhere it will be ambiguous, which 
> >> would be a real shame.
> >This won't work in general, unfortunately as there are already a bunch
> >of PRs and issues opened... And github uses consecutive numbering for
> >all PRs, issues and such... So, there is already overlap here.
>
> It'd be nice if Github allows to bump the issue counter to 44000+ .
> (current largest https://bugs.llvm.org/show_bug.cgi?id= id is 44000+)
>
> Then the website can set up a redirector:
>
> http://llvm.org/PR1 => https://bugs.llvm.org/show_bug.cgi?id=1
> ...
> http://llvm.org/PR44000 => https://bugs.llvm.org/show_bug.cgi?id=44000
> ...
> http://llvm.org/PR45000 => https://github.com/llvm/llvm-project/issue/45000
> http://llvm.org/PR5 => https://github.com/llvm/llvm-project/issue/5
> ___
> LLVM Developers mailing list
> llvm-...@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
___
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] RFC: Switching from Bugzilla to Github Issues

[Anton Korobeynikov via lldb-dev]

I tend to support this – after 10.0.0 seems like a proper timeline.

And we already have some set of tags from bugzilla, so we could simply add them.

On Thu, Jan 30, 2020 at 8:49 PM David Major via llvm-dev
 wrote:
>
> Would it make sense to wait until 10.0.0 is released, in order to keep all 
> the blockers in one place?
>
>
>
> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev 
>  wrote:
>>
>> On 01/30/2020 10:24 AM, Aaron Ballman wrote:
>> > On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev
>> >  wrote:
>> >>
>> >> On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote:
>> >>> We held a round-table at the llvm dev conference about what other pieces 
>> >>> of Github infrastructure we may want to use. This thread in particular 
>> >>> is about switching to github issue tracking. Use of other parts of 
>> >>> Github functionality was also discussed -- but that should be for other 
>> >>> email threads.
>> >>>
>> >>> Most of the ideas here were from other people. I /believe/ this proposal 
>> >>> represents the overall feeling of the folks at the round-table, in 
>> >>> spirit if not in exact details, but nobody else has reviewed this text, 
>> >>> so I can't make any specific such claim as to who the "we" represents, 
>> >>> other than myself. Just assume all the good ideas here were from others, 
>> >>> and all the bad parts I misremembered or invented.
>> >>>
>> >>>
>> >>
>> >> Hi,
>> >>
>> >> I want to restart this discussion.  There seemed to be support for this,
>> >> but we got held up trying to decide on the appropriate set of tags to
>> >> use to classify issues.
>> >>
>> >> I propose that we move forward with this proposal and disable creation of
>> >> new bugs in bugzilla on Feb 11, and require all new bugs be filed via 
>> >> GitHub
>> >> issues from that date forward.
>> >>
>> >> I think that for choosing the tags to use, we should just take requests
>> >> from the community over the next week and add whatever is asked for.  The 
>> >> main
>> >> purpose of adding tags is so we can setup cc lists for bugs, so I think 
>> >> this
>> >> is a good way to ensure that we have tags people care about.  We can 
>> >> always
>> >> add more tags later if necessary.
>> >>
>> >> What does everyone think about this?
>> >
>> > What did we decide to do with all the existing issues in Bugzilla?
>> >
>>
>> This is undecided.  The first step of this  proposal only affects new issues.
>> Existing issues will remain in bugzilla and will be updated there too.  At
>> some point in the future bugzilla will become read-only and/or the issues 
>> will
>> be migrated somewhere else, but no decision has been made about how to do 
>> that yet.
>>
>> -Tom
>>
>> > ~Aaron
>> >
>> >>
>> >> -Tom
>> >>
>> >>
>> >>> Background
>> >>> 
>> >>> Our bugzilla installation is...not great. It's been not-great for a long 
>> >>> time now.
>> >>>
>> >>> Last year, I argued against switching to github issues. I was somewhat 
>> >>> optimistic that it was possible to improve our bugzilla in some 
>> >>> incremental ways...but we haven't. Additionally, the upstream bugzilla 
>> >>> project was supposed to make a new release of bugzilla ("harmony"), 
>> >>> based on bugzilla.mozilla.org 's fork, 
>> >>> which is much nicer. I thought we would be able to upgrade to that. But 
>> >>> there has been no such release, and not much apparent progress towards 
>> >>> such. I can't say with any confidence that there will ever be. I no 
>> >>> longer believe it really makes sense to continue using bugzilla.
>> >>>
>> >>> This year, we again discussed switching. This time, nobody really spoke 
>> >>> up in opposition. So, this time, instead of debating /whether/ we should 
>> >>> switch, we discussed /how/ we should switch. And came up with a plan to 
>> >>> switch quickly.
>> >>>
>> >>> GitHub issues may not be perfect, but I see other similarly-large 
>> >>> projects using it quite successfully (e.g. rust-lang/rust) -- so I 
>> >>> believe it should be good for us, as well. Importantly, Github Issues is 
>> >>> significantly less user-hostile than our bugzilla is, for new 
>> >>> contributors and downstream developers who just want to tell us about 
>> >>> bugs!
>> >>>
>> >>>
>> >>> Proposal
>> >>> 
>> >>> We propose to enable Github issues for the llvm-project repository in 
>> >>> approximately two weeks from now, and instruct everyone to start filing 
>> >>> new issues there, rather than in bugzilla.
>> >>>
>> >>> Some things we'd like to get in place before turning on Github's Issue 
>> >>> tracker:
>> >>> 1. Updated documentation.
>> >>> 2. An initial set of issue tags we'd like to use for 
>> >>> triaging/categorizing issues.
>> >>> 3. Maybe setup an initial issue template. Or maybe multiple templates. 
>> >>> Or maybe not.
>> >>>
>> >>> But more important are the things we do /not/ want to make prerequisites 
>> >>> for turning on Github issues:
>> >>>
>> >>> We do /not/ yet plan to 

Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues

[Anton Korobeynikov via lldb-dev]

> Will you be able to start numbering in github at a number larger than the 
> largest bug in bugzilla?  It would be annoying to have overlapping bug 
> numbers.  Bug numbers exist in code comments, list archives, etc., etc.  If 
> someone reads 'clang bug #1234' somewhere it will be ambiguous, which would 
> be a real shame.
This won't work in general, unfortunately as there are already a bunch
of PRs and issues opened... And github uses consecutive numbering for
all PRs, issues and such... So, there is already overlap here.

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
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] RFC: Switching from Bugzilla to Github Issues

[Anton Korobeynikov via lldb-dev]

> Do we have a way for individuals to get individually automatically subscribed 
> on all the bugs created for a given tag?
> Mailing-lists seem fairly rigid in terms of granularity with respect to tags.
No, all notifications are essentially all-or-nothing thing. Github
folks knows about this issue and planned to work on them, but there
was no ETA on this.

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Call for GSoC 2020 projects

[Anton Korobeynikov via lldb-dev]

Sure, feel free to propose a project!

On Thu, Jan 30, 2020 at 12:55 PM David Tellenbach 
wrote:

> Hi,
>
> sorry for the late response. Yes, my question is answered.
>
> I hadn't any doubt that LLVM will participate in GSoC and my question
> aimed on knowing if it's too late to propose a project - sorry for being
> unclear here.
>
> Thanks for organising LLVM's GSoC participation!
>
> Cheers,
> David
>
> On 29. Jan 2020, at 11:24, Anton Korobeynikov 
> wrote:
>
> Hello David,
> I believe Johannes already answered your questions, but just to
> clarify the things fully: yes, we are going to submit an application
> to participate in GSoC this year as usual. I will take care of
> necessary paperwork and stuff.
> Currently we're collecting the list of summer projects here and there.
> It's perfectly fine to have the lists from sub-projects to be posted
> on their respective websites as a part of corresponding "Open
> Projects" pages.
> On Fri, Jan 24, 2020 at 2:52 PM David Tellenbach
> wrote:
> >
> > Hi all,
> >
> > may I ask about the current status of this?
> >
> > The deadline for organizations to apply is February 5, 2020; has an
> application
> > already been made?
> >
> > Another thing: https://llvm.org/OpenProjects.html states that MLIR
> related
> > projects can be found on
> https://mlir.llvm.org/getting_started/openprojects/. I
> > suggest adding these projects (including some more background
> information) to
> > our common list, just like other sub-projects do.
> >
> > Cheers,
> > David
> >
> > > On 23. Dec 2019, at 11:00, Anton Korobeynikov via llvm-dev wrote:
> > >
> > > Dear prospective LLVM GSoC Mentors,
> > >
> > > The organization application period for GSoC 2020 will open on
> > > January, 14. This means that we're having some time to prepare the
> > > list of project ideas for the next year.
> > >
> > > When proposing the project please keep in mind the following criteria:
> > > 1. The project should serve both LLVM as a project and provide the
> > > relevant LLVM knowledge to the student.
> > > 2. The project should contribute directly to LLVM, clang or LLVM
> > > compiler infrastructure subproject (e.g. not related to some
> > > out-of-tree 3rd party project just using LLVM).
> > > 3. There should be well-defined scope of the project and some set of
> > > "deliverables" at the end of the project.
> > > 4. The project should be either developed in the LLVM mainline or be
> > > ready to be committed to LLVM at the end of GSoC period.
> > >
> > > The Open Projects page was just updated to include the necessary
> > > boilerplate, so feel free to propose the projects there.
> > >
> > > Thanks!
> > >
> > > --
> > > With best regards, Anton Korobeynikov
> > > Department of Statistical Modelling, Saint Petersburg State University
> > > ___
> > > LLVM Developers mailing list
> > > llvm-...@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
>
>
>

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Call for GSoC 2020 projects

[Anton Korobeynikov via lldb-dev]

Hello David,

I believe Johannes already answered your questions, but just to
clarify the things fully: yes, we are going to submit an application
to participate in GSoC this year as usual. I will take care of
necessary paperwork and stuff.

Currently we're collecting the list of summer projects here and there.
It's perfectly fine to have the lists from sub-projects to be posted
on their respective websites as a part of corresponding "Open
Projects" pages.

On Fri, Jan 24, 2020 at 2:52 PM David Tellenbach
 wrote:
>
> Hi all,
>
> may I ask about the current status of this?
>
> The deadline for organizations to apply is February 5, 2020; has an 
> application
> already been made?
>
> Another thing: https://llvm.org/OpenProjects.html states that MLIR related
> projects can be found on https://mlir.llvm.org/getting_started/openprojects/. 
> I
> suggest adding these projects (including some more background information) to
> our common list, just like other sub-projects do.
>
> Cheers,
> David
>
> > On 23. Dec 2019, at 11:00, Anton Korobeynikov via llvm-dev 
> >  wrote:
> >
> > Dear prospective LLVM GSoC Mentors,
> >
> > The organization application period for GSoC 2020 will open on
> > January, 14. This means that we're having some time to prepare the
> > list of project ideas for the next year.
> >
> > When proposing the project please keep in mind the following criteria:
> > 1. The project should serve both LLVM as a project and provide the
> > relevant LLVM knowledge to the student.
> > 2. The project should contribute directly to LLVM, clang or LLVM
> > compiler infrastructure subproject (e.g. not related to some
> > out-of-tree 3rd party project just using LLVM).
> > 3. There should be well-defined scope of the project and some set of
> > "deliverables" at the end of the project.
> > 4. The project should be either developed in the LLVM mainline or be
> > ready to be committed to LLVM at the end of GSoC period.
> >
> > The Open Projects page was just updated to include the necessary
> > boilerplate, so feel free to propose the projects there.
> >
> > Thanks!
> >
> > --
> > With best regards, Anton Korobeynikov
> > Department of Statistical Modelling, Saint Petersburg State University
> > ___
> > LLVM Developers mailing list
> > llvm-...@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
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Call for GSoC 2020 projects

[Anton Korobeynikov via lldb-dev]

Dear prospective LLVM GSoC Mentors,

The organization application period for GSoC 2020 will open on
January, 14. This means that we're having some time to prepare the
list of project ideas for the next year.

When proposing the project please keep in mind the following criteria:
1. The project should serve both LLVM as a project and provide the
relevant LLVM knowledge to the student.
2. The project should contribute directly to LLVM, clang or LLVM
compiler infrastructure subproject (e.g. not related to some
out-of-tree 3rd party project just using LLVM).
3. There should be well-defined scope of the project and some set of
"deliverables" at the end of the project.
4. The project should be either developed in the LLVM mainline or be
ready to be committed to LLVM at the end of GSoC period.

The Open Projects page was just updated to include the necessary
boilerplate, so feel free to propose the projects there.

Thanks!

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [Release-testers] [9.0.0 Release] The release branch is open; trunk is now 10.0.0

[Anton Korobeynikov via lldb-dev]

> > When the branch is in good enough shape, hopefully by tomorrow, the
> > first release candidate (RC1) will be tagged and testing can begin.
> > The release schedule can be found under "Upcoming Releases" to the
> > right at https://llvm.org
> >
>
> Could you please do the necessary magic for 'release_90' branches to
> appear on llvm-mirror/* repos?
Should be there. At lest on official mirrors


-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [GitHub] RFC: Enforcing no merge commit policy

[Anton Korobeynikov via lldb-dev]

> Github PRs are how everyone who is not already super-involved in the llvm 
> project is going to want to contribute changes, and we ought to be as 
> welcoming as possible to such users.
Still we'd need some policy & checks here. Say, what if someone will
issue a PR to LLVM 4.0 branch? With clear code style violations, etc.

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] EuroLLVM 2019 CFP deadline is in 20 minutes

[Anton Korobeynikov via lldb-dev]

Dear All,

Another reminder: the deadline for submitting talk proposals for
EuroLLVM'19 is in 20 minutes. Details are available at
http://llvm.org/devmtg/2019-04/#cfp

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] Updates on SVN to GitHub migration

[Anton Korobeynikov via lldb-dev]

Correct. One important part of the migration is the ability to keep
the various CIs and other integrations intact via switching to
svn-from-git bridge:
https://help.github.com/articles/support-for-subversion-clients/

Otherwise the things might be even more complicated for downstream users.
On Fri, Nov 9, 2018 at 10:56 AM Dean Michael Berris
 wrote:
>
> I think Anton is referring to the SVN bridge -- where Git repositories
> can be accessed through the Subversion API/protocol.
> On Fri, Nov 9, 2018 at 6:27 PM Jean-Daniel via cfe-dev
>  wrote:
> >
> > Isn’t the checkout a local operation that should not involved GitHub ? Did 
> > you mean the clone operation ?
> >
> > And about sparse-checkout, I though they require a full clone of the 
> > repository anyway. Is there a way to do a partial clone only ?
> >
> > Note: If you don’t need the whole history local, you may perform a swallow 
> > clone (using —depth 1).
> >
> > Le 9 nov. 2018 à 01:02, Anton Korobeynikov via llvm-dev 
> >  a écrit :
> >
> > No idea, the checkout just timed out. I tried to play with sparse
> > checkouts, etc. and my current hypothesis that the large number of
> > revisions makes it unhappy.
> > On Fri, Nov 9, 2018 at 2:39 AM James Y Knight  wrote:
> >
> >
> > It'd be nice to know what about our repository is breaking it. Do they have 
> > any idea what that is?
> >
> > For example -- I think that we probably will want to archive+discard many 
> > of the random branches and tags currently in the repository. If the large 
> > number of branches and tags is breaking it, then maybe it just starts 
> > working after we do so.
> >
> > On Thu, Nov 8, 2018 at 3:53 PM Anton Korobeynikov  
> > wrote:
> >
> >
> > Some status update wrt GitHub SVN bridge.
> >
> > It does not work for any non-trivial (= LLVM) repo. I filled the issue
> > there, however, there is no ETA when it will be fixed. Even worse,
> > there are no promises that the issue will be addressed at all. Though
> > they are aware that this is the issue for us.
> > On Thu, Nov 8, 2018 at 12:53 PM Nico Weber via llvm-dev
> >  wrote:
> >
> >
> > What's the status here?
> >
> > Can someone keep https://llvm.org/docs/Proposals/GitHubMove.html updated 
> > with the current status of things?
> >
> > And once things are usable, probably update 
> > https://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo
> >  as well.
> >
> > On Wed, Oct 24, 2018 at 4:57 AM Jacob Carlborg via lldb-dev 
> >  wrote:
> >
> >
> > On 2018-10-24 08:25, Whisperity via cfe-dev wrote:
> >
> > They are not shown in the project graph, but if you open the "branch"
> > drop down it has a tab named 'Tags'.
> >
> >
> > It shows some tags there, but not all of them. But clicking "releases"
> > then "Tags" will show this page [1], which seems to include all of them.
> >
> > [1] https://github.com/llvm-git-prototype/llvm/tags
> >
> > --
> > /Jacob Carlborg
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> >
> > ___
> > LLVM Developers mailing list
> > llvm-...@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> >
> >
> >
> > --
> > With best regards, Anton Korobeynikov
> > Department of Statistical Modelling, Saint Petersburg State University
> >
> >
> >
> >
> > --
> > With best regards, Anton Korobeynikov
> > Department of Statistical Modelling, Saint Petersburg State University
> > ___
> > LLVM Developers mailing list
> > llvm-...@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> >
> > ___
> > cfe-dev mailing list
> > cfe-...@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
> --
> Dean



-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Updates on SVN to GitHub migration

[Anton Korobeynikov via lldb-dev]

No idea, the checkout just timed out. I tried to play with sparse
checkouts, etc. and my current hypothesis that the large number of
revisions makes it unhappy.
On Fri, Nov 9, 2018 at 2:39 AM James Y Knight  wrote:
>
> It'd be nice to know what about our repository is breaking it. Do they have 
> any idea what that is?
>
> For example -- I think that we probably will want to archive+discard many of 
> the random branches and tags currently in the repository. If the large number 
> of branches and tags is breaking it, then maybe it just starts working after 
> we do so.
>
> On Thu, Nov 8, 2018 at 3:53 PM Anton Korobeynikov  
> wrote:
>>
>> Some status update wrt GitHub SVN bridge.
>>
>> It does not work for any non-trivial (= LLVM) repo. I filled the issue
>> there, however, there is no ETA when it will be fixed. Even worse,
>> there are no promises that the issue will be addressed at all. Though
>> they are aware that this is the issue for us.
>> On Thu, Nov 8, 2018 at 12:53 PM Nico Weber via llvm-dev
>>  wrote:
>> >
>> > What's the status here?
>> >
>> > Can someone keep https://llvm.org/docs/Proposals/GitHubMove.html updated 
>> > with the current status of things?
>> >
>> > And once things are usable, probably update 
>> > https://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo
>> >  as well.
>> >
>> > On Wed, Oct 24, 2018 at 4:57 AM Jacob Carlborg via lldb-dev 
>> >  wrote:
>> >>
>> >> On 2018-10-24 08:25, Whisperity via cfe-dev wrote:
>> >> > They are not shown in the project graph, but if you open the "branch"
>> >> > drop down it has a tab named 'Tags'.
>> >>
>> >> It shows some tags there, but not all of them. But clicking "releases"
>> >> then "Tags" will show this page [1], which seems to include all of them.
>> >>
>> >> [1] https://github.com/llvm-git-prototype/llvm/tags
>> >>
>> >> --
>> >> /Jacob Carlborg
>> >>
>> >> ___
>> >> lldb-dev mailing list
>> >> lldb-dev@lists.llvm.org
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> >
>> > ___
>> > LLVM Developers mailing list
>> > llvm-...@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>>
>> --
>> With best regards, Anton Korobeynikov
>> Department of Statistical Modelling, Saint Petersburg State University



--
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Updates on SVN to GitHub migration

[Anton Korobeynikov via lldb-dev]

Some status update wrt GitHub SVN bridge.

It does not work for any non-trivial (= LLVM) repo. I filled the issue
there, however, there is no ETA when it will be fixed. Even worse,
there are no promises that the issue will be addressed at all. Though
they are aware that this is the issue for us.
On Thu, Nov 8, 2018 at 12:53 PM Nico Weber via llvm-dev
 wrote:
>
> What's the status here?
>
> Can someone keep https://llvm.org/docs/Proposals/GitHubMove.html updated with 
> the current status of things?
>
> And once things are usable, probably update 
> https://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo
>  as well.
>
> On Wed, Oct 24, 2018 at 4:57 AM Jacob Carlborg via lldb-dev 
>  wrote:
>>
>> On 2018-10-24 08:25, Whisperity via cfe-dev wrote:
>> > They are not shown in the project graph, but if you open the "branch"
>> > drop down it has a tab named 'Tags'.
>>
>> It shows some tags there, but not all of them. But clicking "releases"
>> then "Tags" will show this page [1], which seems to include all of them.
>>
>> [1] https://github.com/llvm-git-prototype/llvm/tags
>>
>> --
>> /Jacob Carlborg
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [7.0.0 Release] The final tag is in

[Anton Korobeynikov via lldb-dev]

Hi Gabor,

The revision Hans mentioned is essentially the revision that created
svn tag. Content-wise it's equal to the tip of release_70 branch.
On Wed, Sep 19, 2018 at 6:21 PM Gábor Márton via cfe-dev
 wrote:
>
> Hi Hans,
>
> > The final version of 7.0.0 has been tagged from the branch at r342370.
>
> I'd like to fork from 7.0.0 final but I got confused:
> The tip of release_70 branch is still r341805, which is identical to
> rc3. This should be r342370 instead, shouldn't it? Or the final
> (r342370) does not go into the release branch? Or it just takes some
> more time?
>
> Thanks,
> Gabor
> On Mon, Sep 17, 2018 at 1:42 PM Hans Wennborg via cfe-dev
>  wrote:
> >
> > Dear testers,
> >
> > The final version of 7.0.0 has been tagged from the branch at r342370.
> > It is identical to rc3 modulo release notes and docs changes.
> >
> > Please build the final binaries and upload to the sftp.
> >
> > For those following along: this means 7.0.0 is done, but it will take
> > a few days to get all the tarballs ready and published on the web
> > page. I will send the announcement once everything is ready.
> >
> > Thanks again everyone for your work!
> >
> > Hans
> > ___
> > cfe-dev mailing list
> > cfe-...@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] GSoC 2018 Student Applications

[Anton Korobeynikov via lldb-dev]

Dear Prospective GSoC Students,

The student applications website is currently open and there are still
4 days before the deadline.

While you can submit your proposals directly there we strongly suggest
you to submit, refine and discuss your proposals via the corresponding
mailing lists.

The "Open Projects" page at http://llvm.org/OpenProjects.html has some
ideas for may-be projects. However, you could also submit your own
project provided that the proposal is strong enough.

Please do not forget to indicate your current familiarity with LLVM
and whether you already contributed to any of its subprojects.

Have luck!

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLVM & GSoC 2018

[Anton Korobeynikov via lldb-dev]

Dear All,

On behalf of LLVM Foundation it's my pleasure to announce to LLVM has
been accepted to participate in Google Summer of Code program this
year.

The list of open projects could be found at
http://llvm.org/OpenProjects.html#gsoc18

Please let me know, if:
 - You're LLVM contributor and would like to mentor some of projects
listed there
 - You're LLVM contributor and you're thinking you're having a decent
project for this summer

Dear prospective students, the GSoC applications won't be open until
early March (please consult GSoC page for exact timing), but still
we'd encourage everyone willing to participate to submit your proposal
for the discussion in the appropriate subprojects' mailing list.
Please do not forget to indicate your current familiarity with LLVM
and whether you already contributed to any of its subprojects.

If you have questions about the program for the organizers, please
email g...@lists.llvm.org. Project specific questions should be sent
to the appropriate developer mailing list instead.

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Fwd: [GSoC Mentors] GSoC Org Ideas List should be solid by this Monday at 19:00 UTC for review

[Anton Korobeynikov via lldb-dev]

Dear All,

I'm afraid this applies to LLVM as well. So, please fill in the
OpenProjects pages for GSoC today - 19:00 UTC Monday is morning in
California, so Monday will be too late :(


-- Forwarded message --
From: 'Stephanie Taylor' via Google Summer of Code Mentors List

Date: Sun, Jan 28, 2018 at 11:05 AM
Subject: [GSoC Mentors] GSoC Org Ideas List should be solid by this
Monday at 19:00 UTC for review
To: Google Summer of Code Mentors List




Hi all,

It seems quite a few veteran orgs have 0, or very few, projects listed
on their Ideas List for their GSoC Org apps. Some have something like
"coming soon" with no actual ideas on their page - this will result in
an automatic rejection - please don't let that be you!

Our team has been reviewing hundreds of applications this week and
taking notes and we have noticed MANY orgs that have not completed
their lists (have 1-2 ideas or ideas with 1 sentence describing the
problem) or say 'coming in March', 'coming soon', etc. That's a
'Reject in our book.

We will meet Monday, Jan 29 as a team to start our multi day meetings
going through each and every org application together so you have
until Monday at 19:00 UTC to get your ideas onto your list. You can
always add more ideas later but if you are an Umbrella Org you should
have plenty of ideas listed now - and if you are a smaller org you
should have 4-5 well developed ideas minimum.

And please don't just link to a bug tracker. If the bug tracker has
extensive descriptions about the project/problem then that can
sometimes be fine. But just saying here are 5 things we want worked on
and a sentence about each isn't going to cut it.

If you are an Org Admin I strongly encourage you to go back and look
at your Ideas List before Monday at 19:00 UTC and make sure it is
representative of what you want us to evaluate.

Every year we have a few orgs who give us bad URLs or don't give us
access permission to see their Project Ideas List. Again, please don't
be that org... (your community will not be happy).

Remember, the #1 thing our team considers when choosing which orgs to
accept is the quality of the Project Ideas list. If you have nothing
for us to look at we have to reject you.

Please don't ask us to go and see if your application is okay. If you
have a solid Project Ideas List and have read the Defining a Project
Ideas list from the Mentor Guide and followed the advice your list is
likely good to go.

Best,
Stephanie

 Stephanie Taylor
 Open Source Programs, Google
 sttay...@google.com



--
You received this message because you are subscribed to the Google
Groups "Google Summer of Code Mentors List" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to google-summer-of-code-mentors-list+unsubscr...@googlegroups.com.
To post to this group, send email to
google-summer-of-code-mentors-l...@googlegroups.com.
Visit this group at
https://groups.google.com/group/google-summer-of-code-mentors-list.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-summer-of-code-mentors-list/CAEp7XcT%2BacNEJP7E0ZYr742_xDFcJDQkB_DEB-gRwa9FKsOvEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] GSoC: Deadline is coming!

[Anton Korobeynikov via lldb-dev]

Dear prospective GSoC students,

Please do not forget that the deadline for final versions of proposals
is April 3rd, 16:00 UTC (if I'm not mistaken, this corresponds to
12:00 pm in New York and 9:00 am in San Francisco, but please double
check and do not rely on my conversion).

Looking forward to see you this summer doing fun stuff for LLVM!

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] GSoC 2017 Student Applications are Open

[Anton Korobeynikov via lldb-dev]

Dear Prospective GSoC Students,

The student applications website is currently open!

While you can submit your proposals directly there we strongly suggest
you to submit, refine and discuss your proposals via the corresponding
mailing lists.

The "Open Projects" page at http://llvm.org/OpenProjects.html has some
ideas for may-be projects. However, you could also submit your own
project provided that the proposal is strong enough.

Please do not forget to indicate your current familiarity with LLVM
and whether you already contributed to any of its subprojects.

Have luck!

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Google Summer of Code 2017: Call for Mentors & Projects

[Anton Korobeynikov via lldb-dev]

Dear All,

On behalf of LLVM Foundation I would like to announce that LLVM will
be participating in Google Summer of Code this year. GSoC this year
will be quite different from what we saw over last years, so stay
tuned for updates!

Thanks to Vassil, 'Open Projects' pages received a major update this
year, but still please let me know, if:
 - You're LLVM contributor and would like to mentor some of projects
listed there
 - You're LLVM contributor and you're thinking you're having a decent
project for this summer

The 'Open Projects' pages could be found at:
http://llvm.org/OpenProjects.html#gsoc17

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [4.0.0 Release] The branch is here, the release process starts

[Anton Korobeynikov via lldb-dev]

The branches should be fixed as of now. Please let me know whether
you'll see any issues.

On Fri, Jan 13, 2017 at 9:57 AM, Anton Korobeynikov
 wrote:
> Something is weird. The branches were created as usual. And some are
> totally fine (like compiler-rt) and some - broken like llvm and clang.
> I will try to figure out what made git svn mad...
>
> On Fri, Jan 13, 2017 at 9:30 AM, Anton Korobeynikov
>  wrote:
>> That's odd... Have the branch created as usual?
>>
>> On Fri, Jan 13, 2017 at 9:28 AM, Hans Wennborg  wrote:
>>> Oh wait, the branch on the git mirror doesn't look right!
>>>
>>> Anton, can you take a look? The first commit on the branch for llvm is:
>>>
>>> 
>>> r291843 | hans | 2017-01-12 14:12:41 -0800 (Thu, 12 Jan 2017) | 1 line
>>>
>>> Drop 'svn' suffix from version.
>>> 
>>>
>>> It should be similar for cfe and the others.
>>>
>>> The current git mirror branch for llvm seems to only have one commit,
>>> and that's one I just made:
>>>
>>> $ git log --oneline origin/release_40
>>> 817cc1a7301 Merging r291863:
>>> 
>>> r291863 | chapuni | 2017-01-12 16:17:15 -0800 (Thu, 12 Jan 2017) | 1
>>> line
>>>
>>> Note that it doesn't have any parent!
>>>
>>> On Fri, Jan 13, 2017 at 9:23 AM, Hans Wennborg  wrote:
 It's there for me now:

 $ git fetch origin
 remote: Counting objects: 811, done.
 remote: Compressing objects: 100% (561/561), done.
 remote: Total 562 (delta 462), reused 2 (delta 0)
 Receiving objects: 100% (562/562), 927.00 KiB | 1.29 MiB/s, done.
 Resolving deltas: 100% (462/462), completed with 240 local objects.
 From http://llvm.org/git/llvm
233ecbde652..16c5e12d3a5  master -> origin/master
  * [new branch]  release_40 -> origin/release_40


 On Fri, Jan 13, 2017 at 5:49 AM, Nicolai Hähnle  wrote:
> I don't see the release branch in the Git mirror at
> http://llvm.org/git/llvm.git yet. Is that going to appear soon?
>
> Thanks,
> Nicolai
>
>
> On 13.01.2017 00:34, Hans Wennborg via llvm-dev wrote:
>>
>> Dear everyone,
>>
>> It has begun: the release branch was recently created from trunk at
>> r291814 and the trunk version was subsequently incremented to 5.0.0
>> (as per the new versioning scheme [1]).
>>
>> Release blockers are tracked by http://llvm.org/PR31622 Please mark
>> any bugs, old or new, that you think need to be fixed before the
>> release as blocking that.
>>
>> Please help me out in staying on top of the release by cc'ing me on
>> any bugs, commits, or other issues you think may be relevant. If I'm
>> not cc'd on it, there's a large chance I'll miss it. I'm on IRC too,
>> but email is more reliable.
>>
>> If you know of any committs that occurred close to the branch that
>> need to be reverted or merged, please let me know.
>>
>> To get a change committed to the branch, first commit to trunk as
>> usual, and then reply to the commit message on the mailing list with
>> myself and the code owner cc'd, asking for the change to be merged to
>> the branch. Alternatively, make the request by filing a bug blocking
>> PR31622.
>>
>> Release notes should be committed directly to the branch. If you know
>> of any significant change made since the last release, it should get
>> mentioned in the notes.
>>
>> What's next? Once the branch is in good shape, hopefully within a few
>> days, a first release candidate will be made available for testing.
>> The schedule for the release is under "Upcoming Releases" on
>> http://llvm.org.
>>
>> Thanks,
>> Hans
>>
>>
>>  [1] http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>>
>>
>>
>> --
>> With best regards, Anton Korobeynikov
>> Department of Statistical Modelling, Saint Petersburg State University
>
>
>
> --
> With best regards, Anton Korobeynikov
> Department of Statistical Modelling, Saint Petersburg State University



-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [4.0.0 Release] The branch is here, the release process starts

[Anton Korobeynikov via lldb-dev]

Something is weird. The branches were created as usual. And some are
totally fine (like compiler-rt) and some - broken like llvm and clang.
I will try to figure out what made git svn mad...

On Fri, Jan 13, 2017 at 9:30 AM, Anton Korobeynikov
 wrote:
> That's odd... Have the branch created as usual?
>
> On Fri, Jan 13, 2017 at 9:28 AM, Hans Wennborg  wrote:
>> Oh wait, the branch on the git mirror doesn't look right!
>>
>> Anton, can you take a look? The first commit on the branch for llvm is:
>>
>> 
>> r291843 | hans | 2017-01-12 14:12:41 -0800 (Thu, 12 Jan 2017) | 1 line
>>
>> Drop 'svn' suffix from version.
>> 
>>
>> It should be similar for cfe and the others.
>>
>> The current git mirror branch for llvm seems to only have one commit,
>> and that's one I just made:
>>
>> $ git log --oneline origin/release_40
>> 817cc1a7301 Merging r291863:
>> 
>> r291863 | chapuni | 2017-01-12 16:17:15 -0800 (Thu, 12 Jan 2017) | 1
>> line
>>
>> Note that it doesn't have any parent!
>>
>> On Fri, Jan 13, 2017 at 9:23 AM, Hans Wennborg  wrote:
>>> It's there for me now:
>>>
>>> $ git fetch origin
>>> remote: Counting objects: 811, done.
>>> remote: Compressing objects: 100% (561/561), done.
>>> remote: Total 562 (delta 462), reused 2 (delta 0)
>>> Receiving objects: 100% (562/562), 927.00 KiB | 1.29 MiB/s, done.
>>> Resolving deltas: 100% (462/462), completed with 240 local objects.
>>> From http://llvm.org/git/llvm
>>>233ecbde652..16c5e12d3a5  master -> origin/master
>>>  * [new branch]  release_40 -> origin/release_40
>>>
>>>
>>> On Fri, Jan 13, 2017 at 5:49 AM, Nicolai Hähnle  wrote:
 I don't see the release branch in the Git mirror at
 http://llvm.org/git/llvm.git yet. Is that going to appear soon?

 Thanks,
 Nicolai


 On 13.01.2017 00:34, Hans Wennborg via llvm-dev wrote:
>
> Dear everyone,
>
> It has begun: the release branch was recently created from trunk at
> r291814 and the trunk version was subsequently incremented to 5.0.0
> (as per the new versioning scheme [1]).
>
> Release blockers are tracked by http://llvm.org/PR31622 Please mark
> any bugs, old or new, that you think need to be fixed before the
> release as blocking that.
>
> Please help me out in staying on top of the release by cc'ing me on
> any bugs, commits, or other issues you think may be relevant. If I'm
> not cc'd on it, there's a large chance I'll miss it. I'm on IRC too,
> but email is more reliable.
>
> If you know of any committs that occurred close to the branch that
> need to be reverted or merged, please let me know.
>
> To get a change committed to the branch, first commit to trunk as
> usual, and then reply to the commit message on the mailing list with
> myself and the code owner cc'd, asking for the change to be merged to
> the branch. Alternatively, make the request by filing a bug blocking
> PR31622.
>
> Release notes should be committed directly to the branch. If you know
> of any significant change made since the last release, it should get
> mentioned in the notes.
>
> What's next? Once the branch is in good shape, hopefully within a few
> days, a first release candidate will be made available for testing.
> The schedule for the release is under "Upcoming Releases" on
> http://llvm.org.
>
> Thanks,
> Hans
>
>
>  [1] http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

>
>
>
> --
> With best regards, Anton Korobeynikov
> Department of Statistical Modelling, Saint Petersburg State University



-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] [4.0.0 Release] The branch is here, the release process starts

[Anton Korobeynikov via lldb-dev]

Should be there.

On Fri, Jan 13, 2017 at 9:46 AM, Robinson, Paul  wrote:
> Also, compiler-rt release_40 not set up yet?
> Thanks,
> --paulr
>
>> -Original Message-
>> From: cfe-dev [mailto:cfe-dev-boun...@lists.llvm.org] On Behalf Of Anton
>> Korobeynikov via cfe-dev
>> Sent: Friday, January 13, 2017 9:31 AM
>> To: Hans Wennborg
>> Cc: llvm-dev; Nicolai Hähnle; cfe-dev; openmp-dev (openmp-
>> d...@lists.llvm.org); LLDB Dev
>> Subject: Re: [cfe-dev] [llvm-dev] [4.0.0 Release] The branch is here, the
>> release process starts
>>
>> That's odd... Have the branch created as usual?
>>
>> On Fri, Jan 13, 2017 at 9:28 AM, Hans Wennborg  wrote:
>> > Oh wait, the branch on the git mirror doesn't look right!
>> >
>> > Anton, can you take a look? The first commit on the branch for llvm is:
>> >
>> > 
>> > r291843 | hans | 2017-01-12 14:12:41 -0800 (Thu, 12 Jan 2017) | 1 line
>> >
>> > Drop 'svn' suffix from version.
>> > 
>> >
>> > It should be similar for cfe and the others.
>> >
>> > The current git mirror branch for llvm seems to only have one commit,
>> > and that's one I just made:
>> >
>> > $ git log --oneline origin/release_40
>> > 817cc1a7301 Merging r291863:
>> > 
>> > r291863 | chapuni | 2017-01-12 16:17:15 -0800 (Thu, 12 Jan 2017) | 1
>> > line
>> >
>> > Note that it doesn't have any parent!
>> >
>> > On Fri, Jan 13, 2017 at 9:23 AM, Hans Wennborg 
>> wrote:
>> >> It's there for me now:
>> >>
>> >> $ git fetch origin
>> >> remote: Counting objects: 811, done.
>> >> remote: Compressing objects: 100% (561/561), done.
>> >> remote: Total 562 (delta 462), reused 2 (delta 0)
>> >> Receiving objects: 100% (562/562), 927.00 KiB | 1.29 MiB/s, done.
>> >> Resolving deltas: 100% (462/462), completed with 240 local objects.
>> >> From http://llvm.org/git/llvm
>> >>233ecbde652..16c5e12d3a5  master -> origin/master
>> >>  * [new branch]  release_40 -> origin/release_40
>> >>
>> >>
>> >> On Fri, Jan 13, 2017 at 5:49 AM, Nicolai Hähnle 
>> wrote:
>> >>> I don't see the release branch in the Git mirror at
>> >>> http://llvm.org/git/llvm.git yet. Is that going to appear soon?
>> >>>
>> >>> Thanks,
>> >>> Nicolai
>> >>>
>> >>>
>> >>> On 13.01.2017 00:34, Hans Wennborg via llvm-dev wrote:
>> 
>>  Dear everyone,
>> 
>>  It has begun: the release branch was recently created from trunk at
>>  r291814 and the trunk version was subsequently incremented to 5.0.0
>>  (as per the new versioning scheme [1]).
>> 
>>  Release blockers are tracked by http://llvm.org/PR31622 Please mark
>>  any bugs, old or new, that you think need to be fixed before the
>>  release as blocking that.
>> 
>>  Please help me out in staying on top of the release by cc'ing me on
>>  any bugs, commits, or other issues you think may be relevant. If I'm
>>  not cc'd on it, there's a large chance I'll miss it. I'm on IRC too,
>>  but email is more reliable.
>> 
>>  If you know of any committs that occurred close to the branch that
>>  need to be reverted or merged, please let me know.
>> 
>>  To get a change committed to the branch, first commit to trunk as
>>  usual, and then reply to the commit message on the mailing list with
>>  myself and the code owner cc'd, asking for the change to be merged to
>>  the branch. Alternatively, make the request by filing a bug blocking
>>  PR31622.
>> 
>>  Release notes should be committed directly to the branch. If you know
>>  of any significant change made since the last release, it should get
>>  mentioned in the notes.
>> 
>>  What's next? Once the branch is in good shape, hopefully within a few
>>  days, a first release candidate will be made available for testing.
>>  The schedule for the release is under "Upcoming Releases" on
>>  http://llvm.org.
>> 
>>  Thanks,
>>  Hans
>> 
>> 
>>   [1] http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html
>>  ___
>>  LLVM Developers mailing list
>>  llvm-...@lists.llvm.org
>>  http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 
>> >>>
>>
>>
>>
>> --
>> With best regards, Anton Korobeynikov
>> Department of Statistical Modelling, Saint Petersburg State University
>> ___
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org

Re: [lldb-dev] [llvm-dev] [4.0.0 Release] The branch is here, the release process starts

[Anton Korobeynikov via lldb-dev]

That's odd... Have the branch created as usual?

On Fri, Jan 13, 2017 at 9:28 AM, Hans Wennborg  wrote:
> Oh wait, the branch on the git mirror doesn't look right!
>
> Anton, can you take a look? The first commit on the branch for llvm is:
>
> 
> r291843 | hans | 2017-01-12 14:12:41 -0800 (Thu, 12 Jan 2017) | 1 line
>
> Drop 'svn' suffix from version.
> 
>
> It should be similar for cfe and the others.
>
> The current git mirror branch for llvm seems to only have one commit,
> and that's one I just made:
>
> $ git log --oneline origin/release_40
> 817cc1a7301 Merging r291863:
> 
> r291863 | chapuni | 2017-01-12 16:17:15 -0800 (Thu, 12 Jan 2017) | 1
> line
>
> Note that it doesn't have any parent!
>
> On Fri, Jan 13, 2017 at 9:23 AM, Hans Wennborg  wrote:
>> It's there for me now:
>>
>> $ git fetch origin
>> remote: Counting objects: 811, done.
>> remote: Compressing objects: 100% (561/561), done.
>> remote: Total 562 (delta 462), reused 2 (delta 0)
>> Receiving objects: 100% (562/562), 927.00 KiB | 1.29 MiB/s, done.
>> Resolving deltas: 100% (462/462), completed with 240 local objects.
>> From http://llvm.org/git/llvm
>>233ecbde652..16c5e12d3a5  master -> origin/master
>>  * [new branch]  release_40 -> origin/release_40
>>
>>
>> On Fri, Jan 13, 2017 at 5:49 AM, Nicolai Hähnle  wrote:
>>> I don't see the release branch in the Git mirror at
>>> http://llvm.org/git/llvm.git yet. Is that going to appear soon?
>>>
>>> Thanks,
>>> Nicolai
>>>
>>>
>>> On 13.01.2017 00:34, Hans Wennborg via llvm-dev wrote:

 Dear everyone,

 It has begun: the release branch was recently created from trunk at
 r291814 and the trunk version was subsequently incremented to 5.0.0
 (as per the new versioning scheme [1]).

 Release blockers are tracked by http://llvm.org/PR31622 Please mark
 any bugs, old or new, that you think need to be fixed before the
 release as blocking that.

 Please help me out in staying on top of the release by cc'ing me on
 any bugs, commits, or other issues you think may be relevant. If I'm
 not cc'd on it, there's a large chance I'll miss it. I'm on IRC too,
 but email is more reliable.

 If you know of any committs that occurred close to the branch that
 need to be reverted or merged, please let me know.

 To get a change committed to the branch, first commit to trunk as
 usual, and then reply to the commit message on the mailing list with
 myself and the code owner cc'd, asking for the change to be merged to
 the branch. Alternatively, make the request by filing a bug blocking
 PR31622.

 Release notes should be committed directly to the branch. If you know
 of any significant change made since the last release, it should get
 mentioned in the notes.

 What's next? Once the branch is in good shape, hopefully within a few
 days, a first release candidate will be made available for testing.
 The schedule for the release is under "Upcoming Releases" on
 http://llvm.org.

 Thanks,
 Hans


  [1] http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html
 ___
 LLVM Developers mailing list
 llvm-...@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

>>>



-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] YouTrack e-mails

[Anton Korobeynikov via lldb-dev]

Dear All,

Today some of you received dozen e-mails from YouTrack connected with
something which looks like LLVM PRs. Please ignore them and I do
apologize that you received them.

Here is some background. As you may know we had a lot of problems with
Bugzilla recently due to spam activity. Currently we're having user
registration disabled and all the users have to be created by hands.
Unfortunately, Bugzilla has very poor possibilities for dealing with
spam PRs as well as bulk operations, e.g. we simply cannot remove spam
PRs without executing SQL statement directly in the mysql console.

Currently we're simply evaluating different approaches how to proceed:
  - Customize bugzilla to add some filtering / captcha / whatever (it
seems there is no built-in functionality for this).
  - Move to some other product, including (but not limited to) to e.g.
JIRA, YouTrack, Redmine, Mantis, 

The second approach regardless of the selected system involves the
migration of the whole Bugzilla and this process might have a lot of
rough edges. So, recently we started to test whether we could import
the whole Bugzilla contents to Youtrack, evaluate the completeness of
the data, etc. Accidentally I enabled the e-mail notifications for a
moment and this is how all the e-mails were sent.

Note that nothing was decided yet, it might be very probable that
we'll continue use Bugzilla, we're just evaluating other options and
collecting the relevant information. We will try to make sure that
there will be no more e-mail notifications without reason.

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Anton Korobeynikov via lldb-dev]

>  1. Control the history via server hooks updating a unique and
> auto-increment identifier, which will apply to every commit on its
> submodules (ie, every other LLVM project).
Does github allow this? IIRC their support for server-side hooks was
very limited due to obvious reasons. And executing hooks e.g. on
llvm.org seems very error-prone.

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[Anton Korobeynikov via lldb-dev]

>> Regarding the issue of git sub-modules and keeping Clang/LLVM in sync, 
>> perhaps we should just put Clang and LLVM into a single git repository and 
>> add a CMake option to disable compilation of Clang (the same could be done 
>> for other LLVM sub-projects for which bisection and other nifty features 
>> require a single revision number to refer to code across projects).  Keeping 
>> these projects in separate repositories is just more work, and I don't see 
>> what we're getting out of that extra effort.

I'm not sure we will benefit from having *all* the subprojects in the
single repository. This might affect pull / clone time significantly.
Think about having lld, lldb along with llvm + clang in the single
main repo.

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev