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,
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
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
Dear All,
It is my pleasure to announce that LLVM Compiler Infrastructure was
accepted to participate in the Google Summer of Code program.
Just a reminder, the list of project ideas is available from
https://llvm.org/OpenProjects.html#gsoc21
--
With best regards, Anton Korobeynikov
Department
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/
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:
>
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 ho
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
w
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
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, Anto
> 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 d
> 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 wel
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.
> 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 subst
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 M
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 disc
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 over
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
> t
> 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, whi
> 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
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 -
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 he
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 shou
> > 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 'r
> 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
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
__
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,
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
> a
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
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
Dear prospective GSoC students,
This is a reminder that the deadline to submit the final versions of
your proposals is coming. In fact, will be less than in 24 hours. The
submission closes on March 27 16:00 UTC (this corresponds to 17:00 CET
and 9:00 Pacific Time, but please do not rely on my conv
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 "Ope
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 wou
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: Su
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
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/OpenProject
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 t
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
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
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, Janua
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:
>
> ---
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. Current
Dear All,
Due to increasing spam we temporary disabled new user registration on bugzilla.
--
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
> 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
>> I think that this is the right approach, and we happen to have a natural
>> forcing function here: opaque pointer types. I think we should increment the
>> major version number when opaque pointer types are here, as it will be a
>> major breaking change, and then we'll have a version 4.0. Until
Renato,
> Firstly, the responses were overwhelmingly positive (I counted 20 of
> the ~25 people strongly supporting and another 2~3 weakly supporting).
> This is a good indication that the move could be very beneficial to
> the community as a whole, including downstream infrastructure, not
> just
>> 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
47 matches
Mail list logo
