[lldb-dev] Are any LLVM components affected by the recent log4j issues?

[Kristof Beyls via lldb-dev]

As one of the points of contact at CERT for LLVM, I've received messages
from CERT asking if LLVM is affected by any of the recent log4j
vulnerabilities: *CVE-2021-45105*, *CVE-2021-4104*, *CVE-2021-45046* and
*CVE-2021-44228*. It seems CERT is reaching out to every single vendor
registered with them about these vulnerabilities.

As far as I know no LLVM sub-project uses Java, so LLVM should not be
vulnerable to any of the log4j issues.
Before I go ahead and record in the CERT database that LLVM is not
affected, I thought I'd just double check if anyone is aware of any use of
Java in LLVM and/or any potential way LLVM could be affected by the recent
log4j issues?

Thanks,

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

[lldb-dev] Overview of regular online sync-ups on specific topics

[Kristof Beyls via lldb-dev]

I thought it'd be useful to collect an overview of all regular sync-ups
that are organized in the LLVM community.
Therefore, I started a list with all sync-ups that I'm aware of at the
Getting Involved page at
https://llvm.org/docs/GettingInvolved.html#online-sync-ups
I hope it helps:
- advertising the existing sync-ups a bit more, making them a bit more
visible.
- making it a bit easier to start sync-ups on new topics, by having
examples of existing sync-ups in a single place, and a place to advertise
the new one.

I may have missed some regular meetups/sync-ups.
Please let me know if so and I'll add them; or add them yourself directly.

Thanks,

Kristof
___
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 security group sync-up call

[Kristof Beyls via lldb-dev]

Correct, the meeting was cancelled as there were no agenda items.
Next meeting will be on April 20th, usual time.
Please add agenda topics in the document at
https://docs.google.com/document/d/1GLCE8cl7goCaLSiM9j1eIq5IqeXt6_YTY2UEcC4jmsg/edit?usp=sharing

Thanks,

Kristof

Op di 16 mrt. 2021 om 16:40 schreef :

> I see no agenda items on the google doc, so I assume today’s meeting is
> cancelled.  Please let me know if I am wrong about this.
>
> Thanks,
>
> --paulr
>
>
>
> *From:* cfe-dev  *On Behalf Of *Kristof
> Beyls via cfe-dev
> *Sent:* Thursday, March 4, 2021 5:48 AM
> *To:* llvm-dev ; Clang Dev <
> cfe-...@lists.llvm.org>; lldb-dev@lists.llvm.org; libc-...@lists.llvm.org;
> openmp-...@lists.llvm.org
> *Subject:* Re: [cfe-dev] LLVM security group sync-up call
>
>
>
> Hi all,
>
>
>
> At the previous LLVM security group sync-up we decided to have regular,
> monthly sync-ups.
>
> On the third Tuesday of each month at 11am US pacific time.
>
> When there are no agenda items in the doc (see
> https://docs.google.com/document/d/1GLCE8cl7goCaLSiM9j1eIq5IqeXt6_YTY2UEcC4jmsg/edit?usp=sharing
> )
> the meeting gets cancelled.
>
>
>
> The next such meeting is therefore on Tuesday the 16th of March. Please
> find agenda topics and meeting details in the doc at
> https://docs.google.com/document/d/1GLCE8cl7goCaLSiM9j1eIq5IqeXt6_YTY2UEcC4jmsg/edit?usp=sharing
> 
> .
>
>
>
> Thanks,
>
>
>
> Kristof
>
>
>
>
>
> Op ma 8 feb. 2021 om 12:26 schreef Kristof Beyls  >:
>
> After the success of the LLVM security group round table at the virtual
> dev meeting, we are organizing another sync-up call to progress topics
> related to the LLVM security group
> 
> .
>
>
>
> This next sync-up call will take place on Tuesday the 16th of February, at
> 11am PST/7pm UTC/8pm CET.
>
>
>
> I've started a Google doc to keep agenda topics, minutes and details on
> how to join the call at
> https://docs.google.com/document/d/1GLCE8cl7goCaLSiM9j1eIq5IqeXt6_YTY2UEcC4jmsg/edit?usp=sharing
> 
>
>
>
> If you're interested in this, I hope to see you there!
>
>
>
> Thanks,
>
>
>
> Kristof
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLVM security group sync-up call

[Kristof Beyls via lldb-dev]

Hi all,

At the previous LLVM security group sync-up we decided to have regular,
monthly sync-ups.
On the third Tuesday of each month at 11am US pacific time.
When there are no agenda items in the doc (see
https://docs.google.com/document/d/1GLCE8cl7goCaLSiM9j1eIq5IqeXt6_YTY2UEcC4jmsg/edit?usp=sharing)
the meeting gets cancelled.

The next such meeting is therefore on Tuesday the 16th of March. Please
find agenda topics and meeting details in the doc at
https://docs.google.com/document/d/1GLCE8cl7goCaLSiM9j1eIq5IqeXt6_YTY2UEcC4jmsg/edit?usp=sharing
.

Thanks,

Kristof


Op ma 8 feb. 2021 om 12:26 schreef Kristof Beyls :

> After the success of the LLVM security group round table at the virtual
> dev meeting, we are organizing another sync-up call to progress topics
> related to the LLVM security group
> .
>
> This next sync-up call will take place on Tuesday the 16th of February, at
> 11am PST/7pm UTC/8pm CET.
>
> I've started a Google doc to keep agenda topics, minutes and details on
> how to join the call at
> https://docs.google.com/document/d/1GLCE8cl7goCaLSiM9j1eIq5IqeXt6_YTY2UEcC4jmsg/edit?usp=sharing
>
> If you're interested in this, I hope to see you there!
>
> Thanks,
>
> Kristof
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLVM security group sync-up call

[Kristof Beyls via lldb-dev]

After the success of the LLVM security group round table at the virtual dev
meeting, we are organizing another sync-up call to progress topics related
to the LLVM security group .

This next sync-up call will take place on Tuesday the 16th of February, at
11am PST/7pm UTC/8pm CET.

I've started a Google doc to keep agenda topics, minutes and details on how
to join the call at
https://docs.google.com/document/d/1GLCE8cl7goCaLSiM9j1eIq5IqeXt6_YTY2UEcC4jmsg/edit?usp=sharing

If you're interested in this, I hope to see you there!

Thanks,

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

[lldb-dev] FOSDEM 2021 LLVM dev room?

[Kristof Beyls via lldb-dev]

Hi,

LLVM has been present at FOSDEM with an LLVM dev room for many years.
The FOSDEM organizers have just put up a call for participation for the
next FOSDEM, on February 6th and 7th 2021. It's no surprise it's an
online-only event. See https://fosdem.org/2021/news/2020-10-26-devroom-cfp/

In the past few years, I've been the main organizer of the LLVM dev room at
FOSDEM, together with a number of other volunteers.
This year, it's looking like I will not have the time available to be the
main organizer on the day itself. Furthermore, with the conference moving
to an online event, it looks like at least 10 volunteers are needed to be
able to run the dev room, covering various roles as described below.

I've decided to not be the main organizer for the LLVM dev room at FOSDEM
myself for the 2021 edition.
That being said, I am more than happy to support a new main organizer if
someone steps up. If you're interested, please let me know.
If you're interested in any of the other volunteer support roles (described
below), please let me know too so that we can have a guess of whether
enough volunteers are available.
The deadline for proposing the dev room is really nearby: this coming
Friday. So if you're interested, please do reach out by Thursday at the
latest.

Please note that it should be expected that the dev room will run roughly
during day time Brussels time zone (CET).

Thanks,

Kristof


PS. Please see the below notes from the FOSDEM organizers on the volunteer
roles they expect are needed.






































































































*Our basic strategy is to replicate the various elements of the
physicalevent as closely as we can in an online environment.  (Well,
exceptfor the overcrowding!)The main thing to appreciate is that the
volunteer input requiredto produce a professional online event will be
significantly higher thanyou may be used to.  We expect a typical devroom
to need at least 10volunteers during the event so that people can take
breaks.Devroom managers will be responsible for finding and
schedulingvolunteers to perform the various roles needed for an online
conference.Until the end of this year, the input required will be similar
to normal- selecting and scheduling talks.  One thing to note here is that
use ofour systems (e.g. pentabarf) will be compulsory and this includes
callsfor papers.  Systems will change and adapt and we need to be able
tocontact all speakers directly whenever necessary.The changes will be
noticeable in January, when devroom managers willneed to assign specific
volunteers to work 1:1 with individual speakersto prepare recordings of
their talks.  All presentations will need to bepre-recorded and put into
our system at least a couple of weeks beforethe event.  We expect live
presentations to be a rarity, but even if aspeaker intends to deliver their
session live, there must be a recordingavailable to use as a fallback if
something goes wrong and the livepresentation can't be delivered for any
reason.As regards the features for devrooms, we are thinking along
thefollowing lines:- A main stream for each devroom.   Talks here will be
pre-recorded, but questions will be taken live.- A second stream for each
devroom representing hallway discussions  that may follow each talk.- A
facility for people watching to submit questions.- A facility for people
watching to chat between themselves.As such, we're thinking of the
following volunteer roles:Prior to the event:- A devroom manager and a
deputy responsible for everything below.  This includes finding, assigning
and scheduling all the volunteer  roles required.- A programme committee to
select and schedule the talks.  This is the same as a normal year.
Timeline: November/December- Reviewers to help the speakers produce their
pre-recorded content.  This is a new role.  Each speaker will need to be
assigned to a reviewer who will be  responsible for ensuring the content is
put into our system and ready  to be broadcast.   Timeline: January.During
the event itself:- Stream controllers, one per stream, responsible for the
content of  the outgoing stream at all times.  They will switch between
inputs (live video rooms, recordings)  according to the schedule and
intervene (sometimes on video) and make  decisions if there are problems.-
Chat moderators.  They will be responsible for monitoring the content of
the chat and  dealing with any problems that arise (including banning
people if  necessary).  There might also be people assigned to answering
questions about the devroom content.- Session moderators.  Every speaker
will be assigned a moderator who will be responsible  for accompanying that
speaker's session, including all the preparation  and hallway chat
afterwards, including checking the speaker's video  connection is working,
monitoring the chat and submitted questions  and asking them on video to
the speaker.  The moderator will have the speaker's private contact 

[lldb-dev] LLVM devroom at FOSDEM 2020

[Kristof Beyls via lldb-dev]

The program for the LLVM dev room at FOSDEM 2020 has now been completed and
published.
See https://fosdem.org/2020/schedule/track/llvm/.

I hope to see many of you there on the 1st of February!

Kristof

Op ma 18 nov. 2019 om 10:36 schreef Kristof Beyls :

> This is just a gentle reminder that the deadline for submission is coming
> Sunday, 24th of November.
>
> Thanks,
>
> Kristof
>
> Op di 8 okt. 2019 om 17:26 schreef Kristof Beyls  >:
>
>> CALL FOR PAPERS / PARTICIPATION
>>
>> At FOSDEM 2020, LLVM will again participate with a dedicated devroom, on
>> Saturday February 1st, in Brussels.
>>
>> As possibly the largest European Open Source Conference, FOSDEM attracts
>> more than 600 lectures and over 8000 hackers - many core contributors of
>> the world’s leading open source projects.
>>
>> Complementing the LLVM developer meetings, the devroom at FOSDEM provides
>> a great opportunity for LLVM developers and the wider open source community
>> to get together, connect and discuss.
>>
>> We invite academic, industrial and hobbyist speakers to present their
>> work on developing or using LLVM, Clang, LLDB, Compiler-rt, MLIR, flang, or
>> any of the other technologies in the LLVM project.
>>
>> We are looking for:
>>
>>-
>>
>>Keynote speakers.
>>-
>>
>>Technical presentations (default length of 40 minutes including
>>questions) related to the development of LLVM technologies or use of those
>>technologies in other projects.
>>-
>>
>>Tutorials.
>>-
>>
>>Lightning talks (default length of 5 minutes).
>>-
>>
>>Demos.
>>
>> The deadline for receiving proposals is Sunday November 24th, 2019.
>>
>> Speakers will be notified of acceptance or rejection by December 13th.
>> Please find some advice on what constitutes a good proposal at the end of
>> this CFP.
>>
>> To submit a proposal, please create an account on the FOSDEM interface (
>> https://penta.fosdem.org/user/new_account). If you already have an
>> account from previous years, please reuse that.
>>
>> Submit your proposal following
>> https://penta.fosdem.org/submission/FOSDEM20, “Create Event”.
>>
>> Please make sure you select "LLVM devroom" as the "Track”.
>>
>> Presentations will be recorded and streamed. Sending your proposal
>> implies giving permission to be recorded.
>>
>> Registration
>>
>> FOSDEM does not require any registration and is free of charge.
>>
>> Organization
>>
>> The mailing list llvm-devroom at lists.fosdem.org can be used to discuss
>> issues of general interest related to the conference organization. Please,
>> do not reply to this email, as it is cross posted to many lists.
>>
>> Financial support
>>
>> There may be a possibility of limited funding to help presenters who
>> could not otherwise attend the conference.
>>
>> If you need funding to be able to present at the meeting, or can help
>> provide sponsorship, please tell us on llvm-devroom at lists.fosdem.org.
>>
>> Guidance on writing a proposal for the LLVM Dev Room
>>
>> This is a guide to help you submit a good proposal and increase your
>> chances of your proposal being accepted.
>>
>> If you have never presented at an LLVM meeting, then do not fear this
>> process. We are actively looking for new speakers who are excited about
>> LLVM and helping grow the community through these educational talks! You do
>> not need to be a long time developer to submit a proposal.
>>
>> General Guidelines:
>>
>>-
>>
>>It should be clear from your abstract what your topic is, who your
>>target audience is, and what are the takeaways for attendees. The program
>>committee does not have time to read 10 page papers for each submission.
>>-
>>
>>Talks about the use of an LLVM technology should include details
>>about how LLVM is used and not only be about the resulting application.
>>-
>>
>>Tutorials on “how to use X” in LLVM (or other subproject) are greatly
>>desired and beneficial to many developers. Entry level topics are
>>encouraged as well.
>>-
>>
>>Typically a few paragraphs are sufficient.
>>
>>
>> Best regards,
>>
>> LLVM @ FOSDEM organisers
>>
>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Reminder: Deadline 11th of January - EuroLLVM 2020 - Call for presentations

[Kristof Beyls via lldb-dev]

This is just a gentle reminder that the deadline for submitting proposals
is Saturday 11th of January, in about 9 days.

Op vr 22 nov. 2019 om 15:52 schreef Kristof Beyls :

>  All developers and users of LLVM and related sub-projects are invited to
> present and discuss at the EuroLLVM'20 
> developers’ meeting in Paris, France.
>
> We are looking for the following proposals:
>
>1.
>
>Technical Talks (25 minutes + 5 minutes Q):
>-
>
>   On any llvm project such as the core libraries, clang, mlir, flang,
>   etc.
>   -
>
>   On uses of LLVM in academia or industry
>   -
>
>   On new projects using Clang or LLVM
>   -
>
>   On any other LLVM-related topic of interest to participants.
>   2.
>
>Tutorials (60 minutes): in depth talks focussed on helping less
>experienced people get up to speed on an aspect of the LLVM project, with
>in depth examples and explanations.
>3.
>
>Student Research Competition Technical Talks & Poster (25 minutes + 5
>minutes Q) : The SRC offers students doing LLVM related research a
>non-academic platform to announce and advertise their work as well as to
>discuss it with other researchers, developers and users of LLVM. Students
>are strongly encouraged to present a poster as well, as this will enable
>wider discussions with the audience. An embargo period to delay the
>publication of the abstract/talk/poster is possible. There will be a prize
>for the best SRC entry.
>4.
>
>Lightning Talks (5 minutes, no questions, no discussions)
>5.
>
>Panels / round tables (30-60 minutes) / Birds of a Feather
> (BoF)
>(30 minutes)
>
> These are all discussion formats. The best format is probably mostly
> dependent on the number of expected participants. For small group
> highly-engaged discussion, round tables are expected to work best. Round
> table topics can be proposed closer to the EuroLLVM meeting.
> For discussions that are expected to attract larger groups, either a BoF
> or Panel format is expected to work better. A BoF session is run in a
> presentation-like setup, and therefore is expected to have somewhat less
> free-flowing discussion than a round table.
>
> We encourage proposals for a panel format where several experts (and a
> moderator) on a topic get together and have an open discussion in front of
> an audience with prepared questions and also questions from the audience.
> The program committee will be looking for panel proposals and giving favor
> to them over more traditional BoF proposals.
>
>1.
>
>Posters (1 hour)
>
>
>
> Submission Requirements:
>
> The submission deadline is January 11, 2020 at 11:59PM AoE (Anywhere on
> Earth).
>
> Please submit your proposal to the EuroLLVM'20 submission site
> 
>
> For each proposal, please submit a title, short abstract, submission type,
> abstract for the website, and include who the speakers or panel
> member/moderators are. If you wish, you can provide a more detailed
> description of the talk through an extended PDF abstract. We highly
> recommend you consult and follow the guide at the end of this CFP when
> submitting your proposal.
>
> FAQ
>
> When will I be notified of acceptance?
>
> Our goal is to notify all submissions by January 24th, 2020.
>
> What are panels?
>
> Panels may discuss any topic as long as it’s relevant to LLVM or related
> sub-projects. Panels can take many forms, but a common format is to begin
> with short introductions from each panel member, and follow with an
> interactive dialogue among the panelists and audience members. Panels
> should consist of 3 to 6 people including a moderator.
>
> Should I register if I have submitted a proposal?
>
> We have 1 complimentary reserved registration for each accepted technical
> talk, BoF, or student research competition talk. Accepted tutorials have
> been reserved 2 complimentary registrations. Panels have up to 3 reserved
> registrations. There are no reserved registration spots for posters or
> lightning talks. So please register any additional speakers or if you do
> not have a reserved registration slot.
>
> What if I registered and my talk got accepted?
>
> We can refund your registration fee and instructions will be sent
> following notification.  If you plan to attend even if your proposal is not
> accepted and are worried about the event selling out, we suggest
> registering before notification of acceptance.
>
> What if I registered and my talk DID NOT get accepted?
>
> We can refund your registration fee if you no longer wish to attend if you
> contact the organizers by March 6th, 2020.
>
> What will be recorded?
>
> All technical talks, tutorials, SRC talks, panels, and lightning talks
> will be recorded and published. By submitting your proposal, you are giving
> us permission to record 

[lldb-dev] EuroLLVM 2020 - Program committee volunteers needed

[Kristof Beyls via lldb-dev]

Are you interested in being on the program committee for the EuroLLVM 2020
 developers’ meeting in Paris, France?

Please let me know by next Monday, December 9th.



I’m looking for people interested in volunteering their time to help review
proposals for the upcoming EuroLLVM 2020 developers’ meeting. You must be
able to commit time between January 12th and January 24th. How many
proposals you review really depends on the size of our program committee
and the number of proposals submitted. You will need to attend at least one
conference call after submitting your reviews to help finalize the program.



You don’t necessarily need to be a very publicly active member of the LLVM
community to volunteer, nor do you necessarily need years of experience
with LLVM. In order to make sure we have a balanced program committee, I
would appreciate if you could send me the following information:

1. What experience do you have serving on program committees? (no
experience is required, but we would like some experienced members on the
team as well as newer members)

2. What topic areas of the LLVM project do you feel comfortable reviewing
proposals for? What areas of LLVM do you have experience in yourself?
(i.e., clang, back-end, mid-level, debuggers, libc++, lld, integration of
LLVM in other projects, tutorials for newcomers, etc)

3. What is your background? (i.e. industry, academia, research, hobbyist,
...)



Thank you!

--

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

[lldb-dev] EuroLLVM 2020 - Call for presentations

[Kristof Beyls via lldb-dev]

 All developers and users of LLVM and related sub-projects are invited to
present and discuss at the EuroLLVM'20 
developers’ meeting in Paris, France.

We are looking for the following proposals:

   1.

   Technical Talks (25 minutes + 5 minutes Q):
   -

  On any llvm project such as the core libraries, clang, mlir, flang,
  etc.
  -

  On uses of LLVM in academia or industry
  -

  On new projects using Clang or LLVM
  -

  On any other LLVM-related topic of interest to participants.
  2.

   Tutorials (60 minutes): in depth talks focussed on helping less
   experienced people get up to speed on an aspect of the LLVM project, with
   in depth examples and explanations.
   3.

   Student Research Competition Technical Talks & Poster (25 minutes + 5
   minutes Q) : The SRC offers students doing LLVM related research a
   non-academic platform to announce and advertise their work as well as to
   discuss it with other researchers, developers and users of LLVM. Students
   are strongly encouraged to present a poster as well, as this will enable
   wider discussions with the audience. An embargo period to delay the
   publication of the abstract/talk/poster is possible. There will be a prize
   for the best SRC entry.
   4.

   Lightning Talks (5 minutes, no questions, no discussions)
   5.

   Panels / round tables (30-60 minutes) / Birds of a Feather
    (BoF) (30
   minutes)

These are all discussion formats. The best format is probably mostly
dependent on the number of expected participants. For small group
highly-engaged discussion, round tables are expected to work best. Round
table topics can be proposed closer to the EuroLLVM meeting.
For discussions that are expected to attract larger groups, either a BoF or
Panel format is expected to work better. A BoF session is run in a
presentation-like setup, and therefore is expected to have somewhat less
free-flowing discussion than a round table.

We encourage proposals for a panel format where several experts (and a
moderator) on a topic get together and have an open discussion in front of
an audience with prepared questions and also questions from the audience.
The program committee will be looking for panel proposals and giving favor
to them over more traditional BoF proposals.

   1.

   Posters (1 hour)



Submission Requirements:

The submission deadline is January 11, 2020 at 11:59PM AoE (Anywhere on
Earth).

Please submit your proposal to the EuroLLVM'20 submission site


For each proposal, please submit a title, short abstract, submission type,
abstract for the website, and include who the speakers or panel
member/moderators are. If you wish, you can provide a more detailed
description of the talk through an extended PDF abstract. We highly
recommend you consult and follow the guide at the end of this CFP when
submitting your proposal.

FAQ

When will I be notified of acceptance?

Our goal is to notify all submissions by January 24th, 2020.

What are panels?

Panels may discuss any topic as long as it’s relevant to LLVM or related
sub-projects. Panels can take many forms, but a common format is to begin
with short introductions from each panel member, and follow with an
interactive dialogue among the panelists and audience members. Panels
should consist of 3 to 6 people including a moderator.

Should I register if I have submitted a proposal?

We have 1 complimentary reserved registration for each accepted technical
talk, BoF, or student research competition talk. Accepted tutorials have
been reserved 2 complimentary registrations. Panels have up to 3 reserved
registrations. There are no reserved registration spots for posters or
lightning talks. So please register any additional speakers or if you do
not have a reserved registration slot.

What if I registered and my talk got accepted?

We can refund your registration fee and instructions will be sent following
notification.  If you plan to attend even if your proposal is not accepted
and are worried about the event selling out, we suggest registering before
notification of acceptance.

What if I registered and my talk DID NOT get accepted?

We can refund your registration fee if you no longer wish to attend if you
contact the organizers by March 6th, 2020.

What will be recorded?

All technical talks, tutorials, SRC talks, panels, and lightning talks will
be recorded and published. By submitting your proposal, you are giving us
permission to record and publish if you present at the meeting. For SRC
talks, you have the option to delay publication of the slides and video for
you talk for up to 12 months.

Who is on the program committee?

Our program committee chair is Kristof Beyls. The program committee is
composed of active developers of the LLVM, Clang, and related
sub-communities. The website will be updated with the list of 

Re: [lldb-dev] [CFP] LLVM devroom at FOSDEM 2020

[Kristof Beyls via lldb-dev]

This is just a gentle reminder that the deadline for submission is coming
Sunday, 24th of November.

Thanks,

Kristof

Op di 8 okt. 2019 om 17:26 schreef Kristof Beyls :

> CALL FOR PAPERS / PARTICIPATION
>
> At FOSDEM 2020, LLVM will again participate with a dedicated devroom, on
> Saturday February 1st, in Brussels.
>
> As possibly the largest European Open Source Conference, FOSDEM attracts
> more than 600 lectures and over 8000 hackers - many core contributors of
> the world’s leading open source projects.
>
> Complementing the LLVM developer meetings, the devroom at FOSDEM provides
> a great opportunity for LLVM developers and the wider open source community
> to get together, connect and discuss.
>
> We invite academic, industrial and hobbyist speakers to present their work
> on developing or using LLVM, Clang, LLDB, Compiler-rt, MLIR, flang, or any
> of the other technologies in the LLVM project.
>
> We are looking for:
>
>-
>
>Keynote speakers.
>-
>
>Technical presentations (default length of 40 minutes including
>questions) related to the development of LLVM technologies or use of those
>technologies in other projects.
>-
>
>Tutorials.
>-
>
>Lightning talks (default length of 5 minutes).
>-
>
>Demos.
>
> The deadline for receiving proposals is Sunday November 24th, 2019.
>
> Speakers will be notified of acceptance or rejection by December 13th.
> Please find some advice on what constitutes a good proposal at the end of
> this CFP.
>
> To submit a proposal, please create an account on the FOSDEM interface (
> https://penta.fosdem.org/user/new_account). If you already have an
> account from previous years, please reuse that.
>
> Submit your proposal following
> https://penta.fosdem.org/submission/FOSDEM20, “Create Event”.
>
> Please make sure you select "LLVM devroom" as the "Track”.
>
> Presentations will be recorded and streamed. Sending your proposal implies
> giving permission to be recorded.
>
> Registration
>
> FOSDEM does not require any registration and is free of charge.
>
> Organization
>
> The mailing list llvm-devroom at lists.fosdem.org can be used to discuss
> issues of general interest related to the conference organization. Please,
> do not reply to this email, as it is cross posted to many lists.
>
> Financial support
>
> There may be a possibility of limited funding to help presenters who could
> not otherwise attend the conference.
>
> If you need funding to be able to present at the meeting, or can help
> provide sponsorship, please tell us on llvm-devroom at lists.fosdem.org.
>
> Guidance on writing a proposal for the LLVM Dev Room
>
> This is a guide to help you submit a good proposal and increase your
> chances of your proposal being accepted.
>
> If you have never presented at an LLVM meeting, then do not fear this
> process. We are actively looking for new speakers who are excited about
> LLVM and helping grow the community through these educational talks! You do
> not need to be a long time developer to submit a proposal.
>
> General Guidelines:
>
>-
>
>It should be clear from your abstract what your topic is, who your
>target audience is, and what are the takeaways for attendees. The program
>committee does not have time to read 10 page papers for each submission.
>-
>
>Talks about the use of an LLVM technology should include details about
>how LLVM is used and not only be about the resulting application.
>-
>
>Tutorials on “how to use X” in LLVM (or other subproject) are greatly
>desired and beneficial to many developers. Entry level topics are
>encouraged as well.
>-
>
>Typically a few paragraphs are sufficient.
>
>
> Best regards,
>
> LLVM @ FOSDEM organisers
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [CFP] LLVM devroom at FOSDEM 2020

[Kristof Beyls via lldb-dev]

CALL FOR PAPERS / PARTICIPATION

At FOSDEM 2020, LLVM will again participate with a dedicated devroom, on
Saturday February 1st, in Brussels.

As possibly the largest European Open Source Conference, FOSDEM attracts
more than 600 lectures and over 8000 hackers - many core contributors of
the world’s leading open source projects.

Complementing the LLVM developer meetings, the devroom at FOSDEM provides a
great opportunity for LLVM developers and the wider open source community
to get together, connect and discuss.

We invite academic, industrial and hobbyist speakers to present their work
on developing or using LLVM, Clang, LLDB, Compiler-rt, MLIR, flang, or any
of the other technologies in the LLVM project.

We are looking for:

   -

   Keynote speakers.
   -

   Technical presentations (default length of 40 minutes including
   questions) related to the development of LLVM technologies or use of those
   technologies in other projects.
   -

   Tutorials.
   -

   Lightning talks (default length of 5 minutes).
   -

   Demos.

The deadline for receiving proposals is Sunday November 24th, 2019.

Speakers will be notified of acceptance or rejection by December 13th.
Please find some advice on what constitutes a good proposal at the end of
this CFP.

To submit a proposal, please create an account on the FOSDEM interface (
https://penta.fosdem.org/user/new_account). If you already have an account
from previous years, please reuse that.

Submit your proposal following https://penta.fosdem.org/submission/FOSDEM20,
“Create Event”.

Please make sure you select "LLVM devroom" as the "Track”.

Presentations will be recorded and streamed. Sending your proposal implies
giving permission to be recorded.

Registration

FOSDEM does not require any registration and is free of charge.

Organization

The mailing list llvm-devroom at lists.fosdem.org can be used to discuss
issues of general interest related to the conference organization. Please,
do not reply to this email, as it is cross posted to many lists.

Financial support

There may be a possibility of limited funding to help presenters who could
not otherwise attend the conference.

If you need funding to be able to present at the meeting, or can help
provide sponsorship, please tell us on llvm-devroom at lists.fosdem.org.

Guidance on writing a proposal for the LLVM Dev Room

This is a guide to help you submit a good proposal and increase your
chances of your proposal being accepted.

If you have never presented at an LLVM meeting, then do not fear this
process. We are actively looking for new speakers who are excited about
LLVM and helping grow the community through these educational talks! You do
not need to be a long time developer to submit a proposal.

General Guidelines:

   -

   It should be clear from your abstract what your topic is, who your
   target audience is, and what are the takeaways for attendees. The program
   committee does not have time to read 10 page papers for each submission.
   -

   Talks about the use of an LLVM technology should include details about
   how LLVM is used and not only be about the resulting application.
   -

   Tutorials on “how to use X” in LLVM (or other subproject) are greatly
   desired and beneficial to many developers. Entry level topics are
   encouraged as well.
   -

   Typically a few paragraphs are sufficient.


Best regards,

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

Re: [lldb-dev] [CFP] LLVM toolchain devroom CFP at FOSDEM 2019

[Kristof Beyls via lldb-dev]

This is just a gentle reminder that the deadline for submission is coming
Sunday, 25th of November.

Thanks,

Kristof

Op vr 12 okt. 2018 om 15:10 schreef Kristof Beyls :

> *CALL FOR PAPERS / PARTICIPATION*
>
> At FOSDEM 2019, LLVM will again participate with a dedicated devroom, on 
> February 3rd, in Brussels.
> As possibly the largest European Open Source Conference, FOSDEM attracts more 
> than 600 lectures and over 8000 hackers - many core contributors of the 
> worlds leading open source projects.
> Complementing the LLVM developer meetings, the devroom at FOSDEM provides a 
> great opportunity for LLVM developers and the wider open source community to 
> get together, connect and discuss.
>
> We invite academic, industrial and hobbyist speakers to present their work on 
> developing or using LLVM, Clang, LLDB, Polly, Compiler-rt, etc.
> We are looking for:
>
>- Keynote speakers.
>- Technical presentations (30 minutes plus questions and discussion) 
> related to development of LLVM, Clang etc.
>- Presentations about the use of LLVM, Clang in commercial, academic, 
> hobbyist and other projects.
>- Tutorials.
>- Lightning talks (5 minutes).
>- Demos.
>
> The deadline for receiving proposals is Sunday November 25th, 2018.
> Speakers will be notified of acceptance or rejection by December 11th. Please 
> find some advice on what constitutes a good proposal at the end of this CFP.
>
> To submit a proposal, please create an account on the FOSDEM interface 
> (https://penta.fosdem.org/user/new_account). If you already have an account 
> from previous years, please reuse that.
> Submit your proposal following https://penta.fosdem.org/submission/FOSDEM19, 
> “Create Event”.
> Please make sure you select "LLVM devroom" as the "Track”.
> Presentations will be recorded and streamed. Sending your proposal implies 
> giving permission to be recorded. However, exceptions can be made for 
> exceptional circumstances.
>
>
> *Registration*
> FOSDEM does not require any registration and is free of charge.
>
>
> *Organization*
> The mailing list llvm-devroom at lists.fosdem.org can be used to discuss 
> issues of general interest related to the conference organization. Please, do 
> not reply to this email, as it is cross posted to many lists.
>
>
> *Financial support*
> There may be a possibility of limited funding to help presenting students or 
> presenting contributors who could not otherwise attend the conference.
> If you need funding to be able to present at the meeting, or can help 
> sponsor, please tell us on llvm-devroom at lists.fosdem.org.
>
>
>
> *Guidance on writing a proposal for the LLVM Dev Room*
> This is a guide to help you submit a good proposal and increase your chances 
> of your proposal being accepted.
>
> If you have never presented at an LLVM meeting, then do not fear this 
> process. We are actively looking for new speakers who are excited about LLVM 
> and helping grow the community through these educational talks! You do not 
> need to be a long time developer to submit a proposal.
>
> General Guidelines:
>
>- It should be clear from your abstract what your topic is, who your 
> targeted audience is, and what are the takeaways for attendees. The program 
> committee does not have time to read 10 page papers for each submission.
>- Talks about a use of LLVM (etc) should include details about how LLVM is 
> used and not only be about the resulting application.
>- Tutorials on “how to use X” in LLVM (or other subproject) are greatly 
> desired and beneficial to many developers. Entry level topics are encouraged 
> as well.
>- Typically a few paragraphs are sufficient.
>
>
> Best regards,
>
> LLVM @ FOSDEM organisers
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [Call for Volunteers] Bug triaging

[Kristof Beyls via lldb-dev]

Hi Zach,

Thanks for elaborating.
I like your proposal. I agree it still groups per area of expertise. And it 
makes the set of components we have easier to manage.
Before making changes though I hope to hear opinions from others on this.
What do others think?

Thanks,

Kristof

On 9 Nov 2018, at 18:05, Zachary Turner 
mailto:ztur...@google.com>> wrote:

To elaborate, I didn't mean to group all components with less than 10 bugs into 
one massive component.  Rather, to do it separately for each subcomponent.  
Grouping by expertise is fine, but I would argue that a component with 2 or 3 
bugs filed per year is not a very useful component.  There has to be some kind 
of bar for having a component otherwise you end up in the situation we have now.

If you apply this algorithm to the existing set of components, you end up with 
something like this:

Clang:
* New Bugs
* C++
* Frontend
* Formatter
* LLVM Codegen
* Static Analyzer
* Driver
* Modules
* libclang
* Other

clang-tools
* clang-tidy
* Other

compiler-rt
* All Bugs

Documentation
* All Bugs

libc++
* All Bugs

libraries
* Backend:X86
* Scalar Optimizations
* Common Code Generator Code
* Backend:AMDGPU
* Loop Optimizer
* Backend:WebAssembly
* Backend:ARM
* DebugInfo
* Backend:AArch64
* MC
* GlobalISel
* Core LLVM classes
* Global Analyses
* Interprocedural Optimizations
* Support Libraries
* Backend:PowerPC
* Linker
* Transformation Utilities
* Other

lld
* ELF
* COFF
* Other

lldb
* All Bugs

LNT
* All Bugs

new-bugs
* All Bugs

OpenMP
* Clang Compiler Support
* Runtime Support

Packaging
* All Bugs

Phabricator
* All Bugs

Polly
* All Bugs

Runtime Libraries
* libprofile

Test Suite
* All Bugs

tools
* All Bugs

Website
* All Bugs

XRay
* All Bugs

I don't think it's helpful to have what essentially amounts to lots of dead 
components, because it causes confusion for bug reporters as well as triagers.  
I also don't think the above split is radically different than what is already 
there, and for the most part, it still *is* organized by expertise.  It also 
means you need to find less volunteers to add themselves to the cc list for 
various components.  Instead of needing to find a separate volunteer for 
Hexagon, MSP430, PTX, RISC-V, Sparc, Bitcode Writer, and MCJIT, each of which 
has only 1 bug each (so in each case you're looking for a needle in a haystack 
to find the right person and get them to volunteer), you only need to find 1 
for all of them, and there's a good chance that person will be at least 
somewhat familiar with backends in general and so know who the right person to 
talk to is in each case.

Anyway, just my thoughts.

On Fri, Nov 9, 2018 at 12:19 AM Kristof Beyls 
mailto:kristof.be...@arm.com>> wrote:
Hi Zach,

Thanks for putting the data in a spreadsheet - that’s easier to navigate.

And thanks for re-raising the question whether we have the right components in 
bugzilla.
As I think this could be an area for lots of different opinions, without any 
near-perfect solution, it has the potential to be a discussion that drags on 
for a long time.
I thought half of all bugs not getting triaged was a serious enough problem to 
try and tackle first (with this mail thread) before aiming to improve the 
component breakdown in bugzilla.
I think that setting default-cc lists on the components we have currently is 
largely orthogonal to reducing/merging components, as we can always merge 
default-cc lists when we merge components.


On actually coming up with a refined list of components: I think we’ll need to 
define/agree first on what guiding principles we follow when deciding something 
is worthwhile to be a separate component.
Over the past few weeks I’ve heard a number of different options, ranging over:


  *   Just make a component for every sub-directory in the source code.
  *   Just make a component for every library that gets build in the LLVM build.
  *   Make components so that each component has a significant enough number of 
issues raised against it (I’m trying to paraphrase what you’re proposing below).

In my mind, the guiding principle should be:

  *   Components should reflect an area of expertise, so that each component 
can have a set of recognised people that can triage and/or fix bugs against 
that component.

If we’d follow that principle, I think we should not merge all components with 
less than 10 bugs reported into an “Other” component.
I do agree that some merging could still probably be done. E.g. maybe all the 
“clang/C++11”, “clang/C++14”, “clang/C++17”, “clang/C++2a” could be merged into 
a single component.

So in summary:

  *   I don’t think we need to delay assigning 
volunteers-for-triaging/default-cc lists to components. If we merge components 
later on, we can merge cc lists, or asks the volunteers for the relevant 
components If they want to remain on the default-cc list for the merged 
component.
  *   My opinion is the we should define components based on areas of expertise.

Thanks,

Kristof

Re: [lldb-dev] [cfe-dev] [Call for Volunteers] Bug triaging

[Kristof Beyls via lldb-dev]

Hi Zach,

Thanks for putting the data in a spreadsheet - that’s easier to navigate.

And thanks for re-raising the question whether we have the right components in 
bugzilla.
As I think this could be an area for lots of different opinions, without any 
near-perfect solution, it has the potential to be a discussion that drags on 
for a long time.
I thought half of all bugs not getting triaged was a serious enough problem to 
try and tackle first (with this mail thread) before aiming to improve the 
component breakdown in bugzilla.
I think that setting default-cc lists on the components we have currently is 
largely orthogonal to reducing/merging components, as we can always merge 
default-cc lists when we merge components.


On actually coming up with a refined list of components: I think we’ll need to 
define/agree first on what guiding principles we follow when deciding something 
is worthwhile to be a separate component.
Over the past few weeks I’ve heard a number of different options, ranging over:


  *   Just make a component for every sub-directory in the source code.
  *   Just make a component for every library that gets build in the LLVM build.
  *   Make components so that each component has a significant enough number of 
issues raised against it (I’m trying to paraphrase what you’re proposing below).

In my mind, the guiding principle should be:

  *   Components should reflect an area of expertise, so that each component 
can have a set of recognised people that can triage and/or fix bugs against 
that component.

If we’d follow that principle, I think we should not merge all components with 
less than 10 bugs reported into an “Other” component.
I do agree that some merging could still probably be done. E.g. maybe all the 
“clang/C++11”, “clang/C++14”, “clang/C++17”, “clang/C++2a” could be merged into 
a single component.

So in summary:

  *   I don’t think we need to delay assigning 
volunteers-for-triaging/default-cc lists to components. If we merge components 
later on, we can merge cc lists, or asks the volunteers for the relevant 
components If they want to remain on the default-cc list for the merged 
component.
  *   My opinion is the we should define components based on areas of expertise.

Thanks,

Kristof

On 8 Nov 2018, at 20:39, Zachary Turner 
mailto:ztur...@google.com>> wrote:

Just so I'm clear, are we going to attempt to clean up and/or merge the 
components?  If we are, it makes sense to do that before we start putting 
ourselves as default CC's on the various components since they will just 
change.  If not, it would be nice to get some clarification on that now.

I've put the above list into a spreadsheet so people can sort / filter it as 
they see fit.  The link is here:

https://docs.google.com/spreadsheets/d/1aeU6P_vN2c63mpkilqni26U7XtEBDbzZYPFnovwr3FI/edit#gid=0

I think a good starting point would be to get rid of any component with less 
than 10 bugs reported so far this year and merge them all into an "Other" 
component.

On Thu, Nov 8, 2018 at 8:11 AM Kristof Beyls via cfe-dev 
mailto:cfe-...@lists.llvm.org>> wrote:
Hi,

Yesterday, I’ve landed a description for how reported bugs should be flowing 
through the various stages of a bug’s life (triage, fixing, closing, …) at 
http://llvm.org/docs/BugLifeCycle.html.
Thanks for the many many people who provided ideas and feedback for this!

With there now being a description of what is expected during bug triaging 
(http://llvm.org/docs/BugLifeCycle.html#triaging-bugs), we're looking for more 
volunteers to actually do the bug triaging.
About half of all raised bugs currently don’t seem to get triaged.

The idea is to have one or more volunteers for each of the well over 100 
different product/component combinations we have in bugzilla.
If you volunteer to help with triaging bugs against a specific component, we’ll 
add you to the default cc list for that component, so that when a new bug is 
raised against that component, you’ll get notified automatically through email. 
For components with few reported bugs, a single triager may suffice. For the 
high-traffic components, we’ll probably need multiple volunteers.
I’ve provided the list of product/components below that had bugs reported 
against in 2018, together with how many bugs were reported against them this 
year so far, as an indication for which components may need more volunteers.

I do want to highlight the “new-bugs/new bugs”, “clang/-New Bugs” components as 
those tend to be components people file bugs against if they don’t have a clue 
which part of clang/llvm is causing the issue they’re seeing. I believe that 
you don’t need to be an expert to be able to triage most of those bugs. If you 
want to learn more about llvm, volunteering to triage those bugs may be an 
interesting way to learn a lot more yourself.

How can you get added to the default cc list/volunteer?
* Preferred way: raise a bug against “Bugzilla Admin”/“Products” to get 
yourself added to the 

[lldb-dev] [Call for Volunteers] Bug triaging

[Kristof Beyls via lldb-dev]

Hi,

Yesterday, I’ve landed a description for how reported bugs should be flowing 
through the various stages of a bug’s life (triage, fixing, closing, …) at 
http://llvm.org/docs/BugLifeCycle.html.
Thanks for the many many people who provided ideas and feedback for this!

With there now being a description of what is expected during bug triaging 
(http://llvm.org/docs/BugLifeCycle.html#triaging-bugs), we're looking for more 
volunteers to actually do the bug triaging.
About half of all raised bugs currently don’t seem to get triaged.

The idea is to have one or more volunteers for each of the well over 100 
different product/component combinations we have in bugzilla.
If you volunteer to help with triaging bugs against a specific component, we’ll 
add you to the default cc list for that component, so that when a new bug is 
raised against that component, you’ll get notified automatically through email. 
For components with few reported bugs, a single triager may suffice. For the 
high-traffic components, we’ll probably need multiple volunteers.
I’ve provided the list of product/components below that had bugs reported 
against in 2018, together with how many bugs were reported against them this 
year so far, as an indication for which components may need more volunteers.

I do want to highlight the “new-bugs/new bugs”, “clang/-New Bugs” components as 
those tend to be components people file bugs against if they don’t have a clue 
which part of clang/llvm is causing the issue they’re seeing. I believe that 
you don’t need to be an expert to be able to triage most of those bugs. If you 
want to learn more about llvm, volunteering to triage those bugs may be an 
interesting way to learn a lot more yourself.

How can you get added to the default cc list/volunteer?
* Preferred way: raise a bug against “Bugzilla Admin”/“Products” to get 
yourself added to the default cc list of the components of your choice.
* Other way: email bugs-ad...@lists.llvm.org
* Yet another way: just reply to this mail.

Thanks,

Kristof


new-bugs/new bugs: 535 bugs raised in 2018 (so far)
clang/C++: 296 bugs raised in 2018 (so far)
clang/-New Bugs: 260 bugs raised in 2018 (so far)
libraries/Backend: X86: 202 bugs raised in 2018 (so far)
libraries/Scalar Optimizations: 152 bugs raised in 2018 (so far)
clang/Frontend: 120 bugs raised in 2018 (so far)
lld/ELF: 120 bugs raised in 2018 (so far)
clang/Formatter: 108 bugs raised in 2018 (so far)
lldb/All Bugs: 102 bugs raised in 2018 (so far)
clang/LLVM Codegen: 100 bugs raised in 2018 (so far)
clang-tools-extra/clang-tidy: 87 bugs raised in 2018 (so far)
clang/Static Analyzer: 84 bugs raised in 2018 (so far)
libraries/Common Code Generator Code: 78 bugs raised in 2018 (so far)
libc++/All Bugs: 67 bugs raised in 2018 (so far)
lld/COFF: 64 bugs raised in 2018 (so far)
libraries/Backend: AMDGPU: 60 bugs raised in 2018 (so far)
libraries/Loop Optimizer: 44 bugs raised in 2018 (so far)
lld/All Bugs: 30 bugs raised in 2018 (so far)
clang/Driver: 30 bugs raised in 2018 (so far)
Runtime Libraries/libprofile library: 29 bugs raised in 2018 (so far)
libraries/Backend: WebAssembly: 27 bugs raised in 2018 (so far)
libraries/Backend: ARM: 25 bugs raised in 2018 (so far)
clang-tools-extra/Other: 25 bugs raised in 2018 (so far)
libraries/DebugInfo: 25 bugs raised in 2018 (so far)
OpenMP/Clang Compiler Support: 23 bugs raised in 2018 (so far)
compiler-rt/compiler-rt: 21 bugs raised in 2018 (so far)
libraries/Backend: AArch64: 19 bugs raised in 2018 (so far)
clang/C++11: 19 bugs raised in 2018 (so far)
libraries/MC: 18 bugs raised in 2018 (so far)
Build scripts/cmake: 17 bugs raised in 2018 (so far)
clang/Modules: 17 bugs raised in 2018 (so far)
libraries/GlobalISel: 17 bugs raised in 2018 (so far)
OpenMP/Runtime Library: 15 bugs raised in 2018 (so far)
libraries/Global Analyses: 14 bugs raised in 2018 (so far)
libraries/Core LLVM classes: 14 bugs raised in 2018 (so far)
clang/libclang: 14 bugs raised in 2018 (so far)
Documentation/General docs: 13 bugs raised in 2018 (so far)
Packaging/deb packages: 13 bugs raised in 2018 (so far)
libraries/Support Libraries: 13 bugs raised in 2018 (so far)
libraries/Interprocedural Optimizations: 13 bugs raised in 2018 (so far)
libraries/Backend: PowerPC: 11 bugs raised in 2018 (so far)
libraries/Linker: 11 bugs raised in 2018 (so far)
libraries/Transformation Utilities: 11 bugs raised in 2018 (so far)
clang/C++14: 10 bugs raised in 2018 (so far)
clang/Headers: 10 bugs raised in 2018 (so far)
Test Suite/lit: 10 bugs raised in 2018 (so far)
compiler-rt/profile: 10 bugs raised in 2018 (so far)
tools/llvm-objdump: 9 bugs raised in 2018 (so far)
tools/llvm-ar: 8 bugs raised in 2018 (so far)
Polly/Other: 7 bugs raised in 2018 (so far)
Polly/Optimizer: 7 bugs raised in 2018 (so far)
libraries/Register Allocator: 7 bugs raised in 2018 (so far)
tools/llc: 7 bugs raised in 2018 (so far)
XRay/Runtime: 7 bugs raised in 2018 (so far)

Re: [lldb-dev] [llvm-dev] [cfe-dev] [RFC] LLVM bug lifecycle BoF - triaging

[Kristof Beyls via lldb-dev]

On 26 Oct 2018, at 17:26, Kristof Beyls 
mailto:kristof.be...@arm.com>> wrote:



On 26 Oct 2018, at 16:25, Kristof Beyls via llvm-dev 
mailto:llvm-...@lists.llvm.org>> wrote:



On 26 Oct 2018, at 04:26, Richard Smith 
mailto:rich...@metafoo.co.uk>> wrote:

On Thu, 25 Oct 2018 at 05:10, Kristof Beyls via cfe-dev 
mailto:cfe-...@lists.llvm.org>> wrote:
On 5 Oct 2018, at 07:04, Dean Michael Berris 
mailto:dean.ber...@gmail.com>> wrote:

Thank you for starting this conversation! I look forward to the results of the 
BoF discussion summarised as well.

Dean, all,

There was a lively discussion at the BoF; we’ve tried to take notes at 
https://etherpad.net/p/LLVMBugLifeCycleBoF but probably have failed to capture 
all the points. The slides used to kick start the discussion can be found at 
https://docs.google.com/presentation/d/1ERB9IQAjSwaNpEnlbchQzd_V9IQlLOojgo9J0_NXvYA/edit

Both at the BoF and in the mail thread, there have been many suggestions for 
improvements. So many that if we’d want to introduce all of them at once, we’d 
probably get stuck and not introduce any. To try and make progress on the ones 
I myself feel are most useful, I’ve volunteered for 2 actions:

1. Write up a proposal for documentation on what to do during bug 
triaging/closing/etc. I’ve just done so and put it up for review at 
https://reviews.llvm.org/D53691.
2. Write an email to the mailing lists to ask for volunteers for being on the 
“default-cc” list for components, implying you’re willing to triage bugs 
reported against those components. I’ve decided to first try and get consensus 
on what is expected when triaging a bug (see point above) before actively 
searching for volunteers for all components. That being said, both at the dev 
meeting and in the days after, I already received many requests from people to 
be added to the default-cc list for specific components. Of course, I’m very 
happy to add people volunteering to default-cc lists, so if you don’t want to 
wait to get added to a default-cc list, please email 
bugs-ad...@lists.llvm.org or raise it as a 
ticket in bugs.llvm.org under “Bugzilla 
Admin”/“Products”.

Furthermore, since the BoF, I’ve seen a quite a few requests to clean up and 
introduce new components in Bugzilla. We’ve implemented the changes quickly and 
will aim to continue to have a quick response time in the future. Please file a 
ticket in bugs.llvm.org under “Bugzilla 
Admin”/“Products” if you want to request a specific change.

For most of the other points that were raised: I don’t currently plan on acting 
on them immediately myself and hope to first see an impact of the above actions.

In the original post, there was a suggestion to bring back the "UNCONFIRMED" 
status. I think that'd be a great idea, as it both makes it easy to search for 
untriaged bugs and to give feedback to a reporter that their bug is real and 
acknowledged. Is that planned?

I hadn’t seen too much feedback on the idea for introducing (reintroducing?) 
the “UNCONFIRMED” status, so hadn’t planned on making changes to that now.
However, I also think it’s a good idea, so I’ll investigate in more detail now 
if it wouldn’t be overly hard on the Bugzilla admin side to do so (e.g. I 
believe I’ll have to give all existing users the rights to be able to confirm 
bugs). If the “UNCONFIRMED” status can be introduced relatively easily, I now 
plan to do so, and will adapt the proposed documentation at 
https://reviews.llvm.org/D53691 accordingly.
Thanks for pointing to this!

Just a status update on investigations to enable the UNCONFIRMED/CONFIRMED 
states: it seems that bugzilla by-default will put bugs in the “CONFIRMED” 
state when creating new bugs, if the reporter has “can-confirm” rights. I 
believe our de facto policy is for everyone with an account to be able to 
confirm bugs. Also, you need an account to be able to report a bug. The result 
is that all new bugs by default will go to status “CONFIRMED”, unless the 
reporter carefully remembers to change the default and select “UNCONFIRMED”. 
(Also see https://bugzilla.mozilla.org/show_bug.cgi?id=915682 which suggests 
this behaviour is not configurable).

Unless that can be solved, I fear that many bugs will be reported with the 
default “CONFIRMED” status even though they aren’t triaged yet. I believe that 
is worse than the current default “NEW” state.

The only work around for this behaviour where we still get a “to be triaged” 
state I can think of at the moment is to introduce a custom “CONFIRMED” status, 
not using bugzilla’s built-in special “UNCONFIRMED” support and have a flow 
that would allow something like:

NEW -> CONFIRMED -> ASSIGNED -> RESOLVED -> …

The advantage is we’d have separate states to represent “this bug was raised” 
(NEW) vs “this bug was triaged & confirmed” (CONFIRMED).
The disadvantage is that we’ll start deviating from the default bugzilla 
workflows.

Re: [lldb-dev] [cfe-dev] [RFC] LLVM bug lifecycle BoF - triaging

[Kristof Beyls via lldb-dev]

On 26 Oct 2018, at 04:26, Richard Smith 
mailto:rich...@metafoo.co.uk>> wrote:

On Thu, 25 Oct 2018 at 05:10, Kristof Beyls via cfe-dev 
mailto:cfe-...@lists.llvm.org>> wrote:
On 5 Oct 2018, at 07:04, Dean Michael Berris 
mailto:dean.ber...@gmail.com>> wrote:

Thank you for starting this conversation! I look forward to the results of the 
BoF discussion summarised as well.

Dean, all,

There was a lively discussion at the BoF; we’ve tried to take notes at 
https://etherpad.net/p/LLVMBugLifeCycleBoF but probably have failed to capture 
all the points. The slides used to kick start the discussion can be found at 
https://docs.google.com/presentation/d/1ERB9IQAjSwaNpEnlbchQzd_V9IQlLOojgo9J0_NXvYA/edit

Both at the BoF and in the mail thread, there have been many suggestions for 
improvements. So many that if we’d want to introduce all of them at once, we’d 
probably get stuck and not introduce any. To try and make progress on the ones 
I myself feel are most useful, I’ve volunteered for 2 actions:

1. Write up a proposal for documentation on what to do during bug 
triaging/closing/etc. I’ve just done so and put it up for review at 
https://reviews.llvm.org/D53691.
2. Write an email to the mailing lists to ask for volunteers for being on the 
“default-cc” list for components, implying you’re willing to triage bugs 
reported against those components. I’ve decided to first try and get consensus 
on what is expected when triaging a bug (see point above) before actively 
searching for volunteers for all components. That being said, both at the dev 
meeting and in the days after, I already received many requests from people to 
be added to the default-cc list for specific components. Of course, I’m very 
happy to add people volunteering to default-cc lists, so if you don’t want to 
wait to get added to a default-cc list, please email 
bugs-ad...@lists.llvm.org or raise it as a 
ticket in bugs.llvm.org under “Bugzilla 
Admin”/“Products”.

Furthermore, since the BoF, I’ve seen a quite a few requests to clean up and 
introduce new components in Bugzilla. We’ve implemented the changes quickly and 
will aim to continue to have a quick response time in the future. Please file a 
ticket in bugs.llvm.org under “Bugzilla 
Admin”/“Products” if you want to request a specific change.

For most of the other points that were raised: I don’t currently plan on acting 
on them immediately myself and hope to first see an impact of the above actions.

In the original post, there was a suggestion to bring back the "UNCONFIRMED" 
status. I think that'd be a great idea, as it both makes it easy to search for 
untriaged bugs and to give feedback to a reporter that their bug is real and 
acknowledged. Is that planned?

I hadn’t seen too much feedback on the idea for introducing (reintroducing?) 
the “UNCONFIRMED” status, so hadn’t planned on making changes to that now.
However, I also think it’s a good idea, so I’ll investigate in more detail now 
if it wouldn’t be overly hard on the Bugzilla admin side to do so (e.g. I 
believe I’ll have to give all existing users the rights to be able to confirm 
bugs). If the “UNCONFIRMED” status can be introduced relatively easily, I now 
plan to do so, and will adapt the proposed documentation at 
https://reviews.llvm.org/D53691 accordingly.
Thanks for pointing to this!

Also, a big problem with bugzilla as we have it configured today is that 
commenting on an existing bug often sends mail to literally no-one. Can we 
reconfigure this so that llvmbugs gets mail for comments on bugs, not just for 
opening and closing bugs?

I see you’ve created https://bugs.llvm.org/show_bug.cgi?id=39445 for this in 
the mean time, and that a bit of discussion has started there - including 
whether sending an email on all comments wouldn’t result in too much spam on 
the llvmbugs mailing list. I don’t have a strong opinion either way myself. I 
hope that making sure that there is at least someone on the default-cc list for 
every component will result in comments on bugs being emailed to at least one 
person.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [RFC] LLVM bug lifecycle BoF - triaging

[Kristof Beyls via lldb-dev]

On 5 Oct 2018, at 07:04, Dean Michael Berris 
mailto:dean.ber...@gmail.com>> wrote:

Thank you for starting this conversation! I look forward to the results of the 
BoF discussion summarised as well.

Dean, all,

There was a lively discussion at the BoF; we’ve tried to take notes at 
https://etherpad.net/p/LLVMBugLifeCycleBoF but probably have failed to capture 
all the points. The slides used to kick start the discussion can be found at 
https://docs.google.com/presentation/d/1ERB9IQAjSwaNpEnlbchQzd_V9IQlLOojgo9J0_NXvYA/edit

Both at the BoF and in the mail thread, there have been many suggestions for 
improvements. So many that if we’d want to introduce all of them at once, we’d 
probably get stuck and not introduce any. To try and make progress on the ones 
I myself feel are most useful, I’ve volunteered for 2 actions:

1. Write up a proposal for documentation on what to do during bug 
triaging/closing/etc. I’ve just done so and put it up for review at 
https://reviews.llvm.org/D53691.
2. Write an email to the mailing lists to ask for volunteers for being on the 
“default-cc” list for components, implying you’re willing to triage bugs 
reported against those components. I’ve decided to first try and get consensus 
on what is expected when triaging a bug (see point above) before actively 
searching for volunteers for all components. That being said, both at the dev 
meeting and in the days after, I already received many requests from people to 
be added to the default-cc list for specific components. Of course, I’m very 
happy to add people volunteering to default-cc lists, so if you don’t want to 
wait to get added to a default-cc list, please email 
bugs-ad...@lists.llvm.org or raise it as a 
ticket in bugs.llvm.org under “Bugzilla Admin”/“Products”.

Furthermore, since the BoF, I’ve seen a quite a few requests to clean up and 
introduce new components in Bugzilla. We’ve implemented the changes quickly and 
will aim to continue to have a quick response time in the future. Please file a 
ticket in bugs.llvm.org under “Bugzilla Admin”/“Products” 
if you want to request a specific change.

For most of the other points that were raised: I don’t currently plan on acting 
on them immediately myself and hope to first see an impact of the above actions.

Thanks,

Kristof

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

Re: [lldb-dev] [cfe-dev] [RFC] LLVM bug lifecycle BoF - triaging

[Kristof Beyls via lldb-dev]

On 6 Oct 2018, at 23:50, Alex Rønne Petersen 
mailto:a...@alexrp.com>> wrote:

Hello,

I am not a frequent poster on the LLVM mailing lists, but I happened to notice 
this thread and thought I'd weigh in.

Over 2 years ago, I reported this bug: 
https://bugs.llvm.org/show_bug.cgi?id=29102

We had to add a pretty ugly workaround in Mono to deal with that, and the 
workaround is still to this day written to apply to *all* Clang versions on 
ARM64 because we've gotten no response to the bug. This is what we're doing 
currently: https://github.com/mono/mono/blob/master/mono/utils/atomic.h#L209

I think this looks to be a pretty serious bug that shouldn't have gone 
unacknowledged for so long. If there had been any kind of response to the bug, 
I would've even been happy to cook up a patch. But, frankly, without any 
confirmation that a bug is valid, very few potential contributors are going to 
put in the time and effort to write and submit a patch and risk that it gets 
rejected because the issue it's trying to address isn't even considered a bug 
by the project maintainers.

Don't get me wrong, though - I understand from experience that "triage all the 
bugs" is much easier said than done, especially in an open source project. I 
just wanted to back up Kristof's feeling that the project is losing potential 
contributions with a concrete example of such, for what it's worth.

Thank you very much, Alex. I assume that most people who reported a bug and 
never got a reaction on it may not have seen this mail thread. It’s comforting 
to know that at least some people are in a situation like you describe above. 
And therefore, improving the bug lifecycle should increase getting 
contributions from “fresh blood”.


Regards,
Alex

On Thu, Oct 4, 2018 at 11:55 AM Kristof Beyls via cfe-dev 
mailto:cfe-...@lists.llvm.org>> wrote:
Hi all,

I’d like to share a few thoughts and analysis results on the LLVM bug life 
cycle, especially the reporting/triaging part.

As one of the few people creating llvm bugzilla accounts when people request an 
account, I started to have a feel that many reported bugs, especially by 
first-time reporters, never get any reply or feedback, let alone be acted on.
If people go through the effort of requesting an account, and then reporting 
the bug, they show motivation to contribute to the project. However, if then 
they see zero return on their effort spent, even if it’s just a confirmation of 
the bug indeed being real or an explanation of what they thought to be a bug 
isn’t actually a bug, I fear as a community we disincentify a large number of 
potential long-term contributors.

The above was all based on gut feel, so I tried to gather a bit more data to 
see if my feel was correct or not.
I scraped the bugs in bugzilla and post-processed them a bit. Below is a chart 
showing, year by year, how long it takes for a reported bug to get any comment 
from anyone besides to original reporter. If the bug is still open and didn’t 
have any reaction after half a year the chart categorizes is as an “infinite” 
response time.

 [cid:DC7C978D-FC04-470F-BAAE-CC5C623999F0]
It shows that in recent years the chance of never getting a response to a bug 
report has been increasing.
For some bugs - e.g. an experienced LLVM developer records a not-that-important 
bug in bugzilla - that may be just fine.
However, I assume that for people reporting a bug for the first time, the 
majority may look at least for confirmation that what they reported is actually 
a bug.
The chart shows (blue bars) that about 50% of first-time bug reporters never 
get any reply.

I also plotted which components get the most reported bugs that don’t get any 
reaction and remain open:
[cid:130482D2-6DEF-4796-84EC-2968F16B635C]
The percentage at the top of the bars is the percentage of bugs against that 
component that never get any reaction. The bar height shows the absolute 
numbers.


I hope that at the “Lifecycle of LLVM bug reports” BoF at the upcoming dev 
meeting in San Jose (https://llvmdev18.sched.com/event/H2T3, 17th of October, 
10.30am), we can discuss what could be done to improve the experience for 
first-time reporters and also to reduce the number of bug reports that 
seemingly get ignored completely.
By sending this email, I hope to trigger discussion before the BoF, both by 
attendees and non-attendees, so that we have a more fruitful outcome.

At first sight, to me, it seems that the following actions would help:

  *   Let’s introduce some form of “triaged” state in bugzilla, to represent 
that a bug report has been accepted as describing a real problem; able to be 
acted on (e.g. has a suitable reproducer); and not being a duplicate of another 
bug report. Looking at 
https://bugzilla.readthedocs.io/en/5.0/using/editing.html#life-cycle-of-a-bug, 
maybe the best way to achieve this would be for newly raised bugs to by default 
go to an “UNCONFIRMED” state instead of “NEW”? Moving the status to “NEW” or 

Re: [lldb-dev] [cfe-dev] [RFC] LLVM bug lifecycle BoF - triaging

[Kristof Beyls via lldb-dev]

Hi Tamas,

Thanks for highlighting this - it shows that at least we should have a 
description of what it means for a bug to be assigned to someone. Your 
interpretation of a bug being “locked” doesn’t sound unreasonable to me without 
any other description being available.

For the clang static analyser component, it is configured in bugzilla that when 
a new bug is raised against it, there is a default assignee. My guess is that 
most bugs reported against that component just keep on having that default 
assignee.
I think it’d be an improvement to move default assignees (for the components 
that have them) to the “default cc” list. That way, the same people still get 
notified when a bug is raised, but bugs don’t get automatically assigned to 
them. It’ll take an actual conscious action to assign a bug - so hopefully a 
bug being assigned to someone can become more meaningful. Or in short, a setup 
that is somewhat similar to what you describe the LibreOffice project has 
indeed seems better.

Thanks!

Kristof


On 6 Oct 2018, at 22:53, Tamás Zolnai 
mailto:zolnaitamas2...@gmail.com>> wrote:

Hi all,

Just a short feedback about my first impression of the llvm bugzilla. I just 
requested an account for bugzilla and I just did some browsing the bugs. I 
checked static analyzer related bugs and as I see almost all bugs are assigned, 
which is a bit strange to me. Also most of the assigned bugs were assigned to 
two assignees, so I expect that these two people don't actually work on that 
~600 bugs.

So I'm a bit confused now what assigning means in llvm bugzilla. In general for 
me assigning means the bug is "locked", somebody is working on that issue, so I 
should not pick it up for working on it. Which means that by now almost every 
static analyzer related bugs are locked in bugzilla, so I need to find a task 
somewhere else.

In LibreOffice project we also use bugzilla and only assign a bug if the 
assignee is actually working on that issue or he/she is planning to work on it 
soon. Also we reset assignee back to "non" after some months of inactivity. 
Which means that most of the bugs are unassinged so new contributors can pick 
them up (also can filter for unassigned bugs). If a bug is related to an area 
which has an "owner" or expert, we add the expert to the "CC" list so he/she 
get notified.

I did not find any information about that what assigning means in llvm 
bugzilla, so I don't know whether it have a different meaning what I expected 
and described above.

Best Regards,
Tamás Zolnai


Kristof Beyls via cfe-dev 
mailto:cfe-...@lists.llvm.org>> ezt írta (időpont: 
2018. okt. 4., Cs, 11:55):
Hi all,

I’d like to share a few thoughts and analysis results on the LLVM bug life 
cycle, especially the reporting/triaging part.

As one of the few people creating llvm bugzilla accounts when people request an 
account, I started to have a feel that many reported bugs, especially by 
first-time reporters, never get any reply or feedback, let alone be acted on.
If people go through the effort of requesting an account, and then reporting 
the bug, they show motivation to contribute to the project. However, if then 
they see zero return on their effort spent, even if it’s just a confirmation of 
the bug indeed being real or an explanation of what they thought to be a bug 
isn’t actually a bug, I fear as a community we disincentify a large number of 
potential long-term contributors.

The above was all based on gut feel, so I tried to gather a bit more data to 
see if my feel was correct or not.
I scraped the bugs in bugzilla and post-processed them a bit. Below is a chart 
showing, year by year, how long it takes for a reported bug to get any comment 
from anyone besides to original reporter. If the bug is still open and didn’t 
have any reaction after half a year the chart categorizes is as an “infinite” 
response time.

 [X]
It shows that in recent years the chance of never getting a response to a bug 
report has been increasing.
For some bugs - e.g. an experienced LLVM developer records a not-that-important 
bug in bugzilla - that may be just fine.
However, I assume that for people reporting a bug for the first time, the 
majority may look at least for confirmation that what they reported is actually 
a bug.
The chart shows (blue bars) that about 50% of first-time bug reporters never 
get any reply.

I also plotted which components get the most reported bugs that don’t get any 
reaction and remain open:
[X]
The percentage at the top of the bars is the percentage of bugs against that 
component that never get any reaction. The bar height shows the absolute 
numbers.


I hope that at the “Lifecycle of LLVM bug reports” BoF at the upcoming dev 
meeting in San Jose (https://llvmdev18.sched.com/event/H2T3, 17th of October, 
10.30am), we can discuss what could be done to improve the experience for 
first-time reporters and also to reduce the number of bug reports that 
seemingly get ignored completely.
By 

[lldb-dev] [RFC] LLVM bug lifecycle BoF - triaging

[Kristof Beyls via lldb-dev]

Hi all,

I’d like to share a few thoughts and analysis results on the LLVM bug life 
cycle, especially the reporting/triaging part.

As one of the few people creating llvm bugzilla accounts when people request an 
account, I started to have a feel that many reported bugs, especially by 
first-time reporters, never get any reply or feedback, let alone be acted on.
If people go through the effort of requesting an account, and then reporting 
the bug, they show motivation to contribute to the project. However, if then 
they see zero return on their effort spent, even if it’s just a confirmation of 
the bug indeed being real or an explanation of what they thought to be a bug 
isn’t actually a bug, I fear as a community we disincentify a large number of 
potential long-term contributors.

The above was all based on gut feel, so I tried to gather a bit more data to 
see if my feel was correct or not.
I scraped the bugs in bugzilla and post-processed them a bit. Below is a chart 
showing, year by year, how long it takes for a reported bug to get any comment 
from anyone besides to original reporter. If the bug is still open and didn’t 
have any reaction after half a year the chart categorizes is as an “infinite” 
response time.

 [cid:DC7C978D-FC04-470F-BAAE-CC5C623999F0]
It shows that in recent years the chance of never getting a response to a bug 
report has been increasing.
For some bugs - e.g. an experienced LLVM developer records a not-that-important 
bug in bugzilla - that may be just fine.
However, I assume that for people reporting a bug for the first time, the 
majority may look at least for confirmation that what they reported is actually 
a bug.
The chart shows (blue bars) that about 50% of first-time bug reporters never 
get any reply.

I also plotted which components get the most reported bugs that don’t get any 
reaction and remain open:
[cid:130482D2-6DEF-4796-84EC-2968F16B635C]
The percentage at the top of the bars is the percentage of bugs against that 
component that never get any reaction. The bar height shows the absolute 
numbers.


I hope that at the “Lifecycle of LLVM bug reports” BoF at the upcoming dev 
meeting in San Jose (https://llvmdev18.sched.com/event/H2T3, 17th of October, 
10.30am), we can discuss what could be done to improve the experience for 
first-time reporters and also to reduce the number of bug reports that 
seemingly get ignored completely.
By sending this email, I hope to trigger discussion before the BoF, both by 
attendees and non-attendees, so that we have a more fruitful outcome.

At first sight, to me, it seems that the following actions would help:

  *   Let’s introduce some form of “triaged” state in bugzilla, to represent 
that a bug report has been accepted as describing a real problem; able to be 
acted on (e.g. has a suitable reproducer); and not being a duplicate of another 
bug report. Looking at 
https://bugzilla.readthedocs.io/en/5.0/using/editing.html#life-cycle-of-a-bug, 
maybe the best way to achieve this would be for newly raised bugs to by default 
go to an “UNCONFIRMED” state instead of “NEW”? Moving the status to “NEW” or 
“CONFIRMED” would indicate the bug has been triaged.
  *   Would it help to have one or multiple people per component that volunteer 
to triage new bugs?
  *   With the majority of developers being part of a team working on a product 
based on LLVM, I would assume that it is in the interest of most that reported 
bugs at least get evaluated/triaged? What is stopping those developers to find 
the time to do some triaging? Would a better notification mechanism be useful 
to notify when new bugs on a specific component come in that you could triage? 
Maybe per component try to have a few people on the “default CC list”, which 
seems easy to set up as a bugzilla administrator.
  *   Should we get rid of the "new-bugs/new bugs” component if we won’t have 
people triaging them?
  *   Should we have some description of what a reasonable triage of a bug 
looks like? If we write such a page, we could also use that page to describe 
what we think should get recorded when closing bugs.

Thanks,

Kristof

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

Re: [lldb-dev] [CFP] LLVM toolchain devroom CFP at FOSDEM 2018

[Kristof Beyls via lldb-dev]

This is just a gentle reminder that the deadline for submission is coming
Sunday, 26th of November.

Thanks,

Kristof

2017-10-13 10:51 GMT+02:00 Kristof Beyls :

> *CALL FOR PAPERS / PARTICIPATION*
>
> At FOSDEM 2018, LLVM will again participate with a dedicated devroom, on
> February 4th, in Brussels.
> As possibly the largest European Open Source Conference, FOSDEM attracts
> more than 400 lectures and over 5000 hackers - many core contributors of
> the worlds leading open source projects.
> Complementing the LLVM developer meetings, the devroom at FOSDEM provides
> a great opportunity for LLVM developers and the wider open source community
> to get together, connect and discuss.
>
> We invite academic, industrial and hobbyist speakers to present their work
> on developing or using LLVM, Clang, LLDB, Polly, Compiler-rt, etc.
> We are looking for:
>
>- Keynote speakers.
>- Technical presentations (30 minutes plus questions and discussion)
>related to development of LLVM, Clang etc.
>- Presentations about the use of LLVM, Clang in commercial, academic,
>hobbyist and other projects.
>- Tutorials.
>- Lightning talks (5 minutes).
>- Demos.
>
> The deadline for receiving proposals is November 26th, 2017.
> Speakers will be notified of acceptance or rejection by December 12th.
> Please find some advice on what constitutes a good proposal at the end of
> this CFP.
>
> To submit a proposal, please create an account on the FOSDEM interface (
> https://penta.fosdem.org/user/new_account). If you already have an
> account from previous years, please reuse that.
> Submit your proposal following https://penta.fosdem.org/
> submission/FOSDEM18, “Create Event”.
> Please make sure you select "LLVM toolchain devroom" as the "Track”.
> Presentations will be recorded and streamed. Sending your proposal implies
> giving permission to be recorded. However, exceptions can be made for
> exceptional circumstances.
>
>
> *Registration*
> FOSDEM does not require any registration and is free of charge.
>
>
> *Organization*
> The mailing list llvm-devroom at lists.fosdem.org can be used to discuss
> issues of general interest related to the conference organization. Please,
> do not reply to this email, as it is cross posted to many lists.
>
>
> *Financial support*
> There may be a possibility of limited funding to help presenting students
> or presenting contributors who could not otherwise attend the conference.
> If you need funding to be able to present at the meeting, or can help
> sponsor, please tell us on llvm-devroom at lists.fosdem.org.
>
>
> *Guidance on writing a proposal for the LLVM Dev Room*
> This is a guide to help you submit a good proposal and increase your
> chances of your proposal being accepted.
>
> If you have never presented at an LLVM meeting, then do not fear this
> process. We are actively looking for new speakers who are excited about
> LLVM and helping grow the community through these educational talks! You do
> not need to be a long time developer to submit a proposal.
>
> General Guidelines:
>
>- It should be clear from your abstract what your topic is, who your
>targeted audience is, and what are the takeaways for attendees. The program
>committee does not have time to read 10 page papers for each submission.
>- Talks about a use of LLVM (etc) should include details about how
>LLVM is used and not only be about the resulting application.
>- Tutorials on “how to use X” in LLVM (or other subproject) are
>greatly desired and beneficial to many developers. Entry level topics are
>encouraged as well.
>- Typically a few paragraphs are sufficient.
>
>
> Best regards,
>
> LLVM @ FOSDEM organisers
>
>
>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [CFP] LLVM toolchain devroom CFP at FOSDEM 2018

[Kristof Beyls via lldb-dev]

*CALL FOR PAPERS / PARTICIPATION*

At FOSDEM 2018, LLVM will again participate with a dedicated devroom, on
February 4th, in Brussels.
As possibly the largest European Open Source Conference, FOSDEM attracts
more than 400 lectures and over 5000 hackers - many core contributors of
the worlds leading open source projects.
Complementing the LLVM developer meetings, the devroom at FOSDEM provides a
great opportunity for LLVM developers and the wider open source community
to get together, connect and discuss.

We invite academic, industrial and hobbyist speakers to present their work
on developing or using LLVM, Clang, LLDB, Polly, Compiler-rt, etc.
We are looking for:

   - Keynote speakers.
   - Technical presentations (30 minutes plus questions and discussion)
   related to development of LLVM, Clang etc.
   - Presentations about the use of LLVM, Clang in commercial, academic,
   hobbyist and other projects.
   - Tutorials.
   - Lightning talks (5 minutes).
   - Demos.

The deadline for receiving proposals is November 26th, 2017.
Speakers will be notified of acceptance or rejection by December 12th.
Please find some advice on what constitutes a good proposal at the end of
this CFP.

To submit a proposal, please create an account on the FOSDEM interface (
https://penta.fosdem.org/user/new_account). If you already have an account
from previous years, please reuse that.
Submit your proposal following https://penta.fosdem.org/submission/FOSDEM18,
“Create Event”.
Please make sure you select "LLVM toolchain devroom" as the "Track”.
Presentations will be recorded and streamed. Sending your proposal implies
giving permission to be recorded. However, exceptions can be made for
exceptional circumstances.


*Registration*
FOSDEM does not require any registration and is free of charge.


*Organization*
The mailing list llvm-devroom at lists.fosdem.org can be used to discuss
issues of general interest related to the conference organization. Please,
do not reply to this email, as it is cross posted to many lists.


*Financial support*
There may be a possibility of limited funding to help presenting students
or presenting contributors who could not otherwise attend the conference.
If you need funding to be able to present at the meeting, or can help
sponsor, please tell us on llvm-devroom at lists.fosdem.org.


*Guidance on writing a proposal for the LLVM Dev Room*
This is a guide to help you submit a good proposal and increase your
chances of your proposal being accepted.

If you have never presented at an LLVM meeting, then do not fear this
process. We are actively looking for new speakers who are excited about
LLVM and helping grow the community through these educational talks! You do
not need to be a long time developer to submit a proposal.

General Guidelines:

   - It should be clear from your abstract what your topic is, who your
   targeted audience is, and what are the takeaways for attendees. The program
   committee does not have time to read 10 page papers for each submission.
   - Talks about a use of LLVM (etc) should include details about how LLVM
   is used and not only be about the resulting application.
   - Tutorials on “how to use X” in LLVM (or other subproject) are greatly
   desired and beneficial to many developers. Entry level topics are
   encouraged as well.
   - Typically a few paragraphs are sufficient.


Best regards,

LLVM @ FOSDEM organisers
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev