Fwd: [GSoC Mentors] GSoC 2020 Organization Applications are now open (and close on February 5th)

[Jackson Isaac]

Hi,

GSoC 2020 org applications are now open.

Let's participate again this year, we have some ideas on wiki, maybe they
need some refinement ? Also, buildbot mentors are happy to collaborate
again this year with us.

If any of the previous year students want to become the Org Admin/Mentor,
let us know :)

Regards,
Jackson Isaac




-- Forwarded message -
From: 'sttaylor' via Google Summer of Code Mentors List <
google-summer-of-code-mentors-l...@googlegroups.com>
Date: Tue 14 Jan, 2020, 23:22
Subject: [GSoC Mentors] GSoC 2020 Organization Applications are now open
(and close on February 5th)
To: Google Summer of Code Mentors List <
google-summer-of-code-mentors-l...@googlegroups.com>


*Open Source Organizations* that wish to be mentoring orgs for GSoC 2020
can now apply. Orgs please remember the organization application period
will close on Wednesday, February 5th. You can go to g.co/gsoc to complete
your organization's application.

*Students*- if you are interested in participating in GSoC 2020 *s**tudent
applications open March 16-31*.

The GSoC 2020 program announcement

, timeline , marketing
materials
 (slide
deck, flyers), FAQs ,
and short videos 
about the program and tips for mentors and students are all available.

Thinking about being a mentor for GSoC 2020? Reach out to the organization
you'd like to work with in the next couple of months and let them know, I'm
sure they'd be thrilled to have you as a mentor!

We are looking forward to another exciting year of GSoC.

For any questions about the programs please email us at
gsoc-supp...@google.com

Best,

Stephanie Taylor

-- 
You received this message because you are subscribed to the Google Groups
"Google Summer of Code Mentors List" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-summer-of-code-mentors-list+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-summer-of-code-mentors-list/7ea5c97b-7467-4787-82af-5cb8c425f5d5%40googlegroups.com

.

Re: renaming llvm/clang/lldb from llvm-N.0 to llvm-N or llvmN ?

[Chris Jones]

Hi,

> On 14 Jan 2020, at 10:39 pm, Ryan Schmidt  wrote:
> 
> The gcc and postgresql ports are named correctly, both before and after 
> their version numbering scheme changed. If llvm/clang's version numbering 
> scheme changed, it would be good if the port names agreed with the scheme as 
> well. I agree this has the potential to cause breakage which should be 
> handled carefully.

Its not really that the version number format has changed, more different 
emphasis is placed on the major and minor versions. Like with gcc, clang has 
effectively decided to make more regular (yearly) major version updates for a 
while now, and for the minor and patch sub versions to mean just that, ‘minor’ 
changes. Given this, its now more natural for macports to just label its clang 
ports, as with gcc, by only the major version, and not as before major.minor.

One other thing to note, as I comment in 

https://github.com/macports/macports-ports/commit/9af0eda5b1e6ee80e8f1c7b9836a6256c95cfc44#commitcomment-36798493

Is when clang 10 comes out we anyway will have issues with the logic in a few 
places, regardless of if we drop the .0 from the port name, as there is 
hardcoded logic in a few places that will break once we have a major version 
with two digits in it... so seeing as we have to do something regardless, we 
should drop the .0 at the same time, as it probably adds little additional work.

Chris

Re: renaming llvm/clang/lldb from llvm-N.0 to llvm-N or llvmN ?

[Ryan Schmidt]

The gcc and postgresql ports are named correctly, both before and after their 
version numbering scheme changed. If llvm/clang's version numbering scheme 
changed, it would be good if the port names agreed with the scheme as well. I 
agree this has the potential to cause breakage which should be handled 
carefully.

Re: renaming llvm/clang/lldb from llvm-N.0 to llvm-N or llvmN ?

[Chris Jones]

Hi,

I think we should definitively switch to llvm-10 for the next release, and just 
sort out whatever issues that causes. We should not perpetuate the mistake, now 
its know, and I suspect it won’t actually be that bad to deal with it. 

As for back porting that to the current versions, I agree this might require a 
bit more work to fix all references, but I personally still would probably look 
into doing it, as I think long term having everything from 5 on onwards using 
the same scheme would ultimately simplify things.

Chris

> On 14 Jan 2020, at 6:29 pm, Ken Cunningham  
> wrote:
> 
> We finally had a situation where the llvm-N.0 naming convention did not work 
> out, and we have a port named llvm-7.0 now actually being llvm-7.1.0. This 
> inaccuracy generates a "disturbance in the force”. AFAICT, this has not ever 
> happened before, so we always got away with it.
> 
> We can just live with this, probably, as it is so rare, at least so far. Or 
> we can rename all the llvm/clang/lldb ports from 5 onwards to llvm-5 instead 
> of llvm-5.0, etc. This would be more accurate, technically, but otherwise 
> meaningless in practice. However, there are so many Portfiles, PortGroups, 
> and base references that I’m rather fearful of the fallout from doing that at 
> this point in time.
> 
> Whether we do that or not, the new llvm 10 series is going to be out soon. We 
> can name that llvm-10, and deal with the differences that name might trigger 
> somehow, if there are any, in the Portfiles, PortGroups, and base — or we can 
> just call it llvm-10.0, clang-10.0, and lldb-10.0, and suck it up. That would 
> likely cause less widespread wreckage in the many files that depend on these 
> names, but might again come up with another slightly misnamed port in the 
> future, where some future port named llvm-12.0 is actually llvm-12.2.0 or 
> similar.
> 
> Either way, we either get a (possibly) less accurate portname, or we risk 
> unexpected wreckage.
> 
> 
> Open to opinions.
> 
> Ken

renaming llvm/clang/lldb from llvm-N.0 to llvm-N or llvmN ?

[Ken Cunningham]

We finally had a situation where the llvm-N.0 naming convention did not work 
out, and we have a port named llvm-7.0 now actually being llvm-7.1.0. This 
inaccuracy generates a "disturbance in the force”. AFAICT, this has not ever 
happened before, so we always got away with it.

We can just live with this, probably, as it is so rare, at least so far. Or we 
can rename all the llvm/clang/lldb ports from 5 onwards to llvm-5 instead of 
llvm-5.0, etc. This would be more accurate, technically, but otherwise 
meaningless in practice. However, there are so many Portfiles, PortGroups, and 
base references that I’m rather fearful of the fallout from doing that at this 
point in time.

Whether we do that or not, the new llvm 10 series is going to be out soon. We 
can name that llvm-10, and deal with the differences that name might trigger 
somehow, if there are any, in the Portfiles, PortGroups, and base — or we can 
just call it llvm-10.0, clang-10.0, and lldb-10.0, and suck it up. That would 
likely cause less widespread wreckage in the many files that depend on these 
names, but might again come up with another slightly misnamed port in the 
future, where some future port named llvm-12.0 is actually llvm-12.2.0 or 
similar.

Either way, we either get a (possibly) less accurate portname, or we risk 
unexpected wreckage.


Open to opinions.

Ken