ah ok. when I want to organise I shouls subscriba aswell?
վարյաhas joined
goffihas left
goffihas joined
intosihas left
lskdjfhas joined
jcbrandhas left
marc0shas left
marc0shas joined
վարյաhas left
վարյաhas joined
florettahas left
millesimushas left
millesimushas joined
florettahas joined
soundconcepthas left
ti_gj06has left
matkorhas joined
ti_gj06has joined
soundconcepthas joined
intosihas joined
soundconcepthas left
soundconcepthas joined
debaclehas joined
Alexhas joined
goffihas left
chronosx88has left
chronosx88has joined
millesimushas left
marc0shas left
millesimushas joined
malthehas left
huhnhas joined
marc0shas joined
goffihas joined
ti_gj06has left
archas left
archas joined
jgarthas left
jcbrandhas joined
xsfhas left
wladmishas joined
adiaholichas joined
sonnyhas left
sonnyhas joined
վարյաhas left
վարյաhas joined
millesimushas left
chronosx88has left
archas left
Kevhas left
Kevhas joined
archas joined
Kev
emus: No, Mentors/Admins get added automatically.
robertooohas left
ti_gj06has joined
jinxdhas joined
sonnyhas left
sonnyhas joined
jgarthas joined
վարյաhas left
վարյաhas joined
emus
ah ok
atomicwatchhas joined
marc0shas left
marc0shas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
վարյաhas left
վարյաhas joined
Paganinihas joined
wladmishas left
florettahas left
վարյաhas left
վարյաhas joined
norkkihas joined
norkkihas left
rafasaurushas left
rafasaurushas joined
chronosx88has joined
florettahas joined
Kevhas left
Kevhas joined
soundconcepthas left
wladmishas joined
soundconcepthas joined
վարյաhas left
վարյաhas joined
mjkhas joined
ti_gj06has left
Kevhas left
Kevhas joined
Menelhas left
Menelhas joined
antranigvhas joined
goffi
hi jonas’ I see that https://github.com/xsf/xeps/pull/1124 is not in the council agenda, but I think it should be discussed there, shouldn't it?
jonas’
goffi, the mailing list thread is rather new and we have the policy (or try to...) to first let the list discussion settle
jonas’
hence I added ~"Needs List Discussion"
jonas’
I also replied to your thread on list while I was at it :)
jinxdhas left
goffi
jonas’: I've replied already to your email ;)
jonas’
ok, I didn't see that yet :)
goffi
jonas’: OK make sense, so I guess I'll have to wait, thanks!
wladmishas left
վարյաhas left
վարյաhas joined
adiaholichas left
inkyhas joined
mathieui
goffi: I have not received your message on list duo
adiaholichas joined
goffi
I haven't received the second one either, maybe there is some greylisting? It's on the archive though: https://mail.jabber.org/pipermail/standards/2021-November/038640.html
mathieui
Got it now
goffi
me too
jonas’
great, it's not just me who gets delayed by the list server for some reason ;)
Zash
I too received it just now
norkkihas joined
chronosx88has left
chronosx88has joined
norkkihas left
jonas’
goffi, I think the issue clearly points at why we cannot retrofit that requirement into XEP-0060 and should instead quite explicitly state that no ordering can be assumed and that '413 should be used when ordering is required.
jonas’
if '413 currently mandates keeping modification times and stuff, I suggest that it should be modified to make those optional and negotiated, to cover the minimum use case of having items in most-recent-first / least-recent-first order.
jonas’
but I'll put that into an email, later, too
goffi
jonas’: yes please, put into an email. I'm very unconfortable with unordered pubsub items, but if we have a consensus on that, I'll update 0413. Let see how the discussion evolves
վարյաhas left
վարյաhas joined
goffi
jonas’: also I'm worrying to see little adoption of 0413 before long, resulting in issues in Movim and Libervia use cases (and I'm pretty sure that most if not all pubsub implementation are already ordered, just not all at the same order). I'll put that in an email too.
jonas’
goffi, yup, let's move this to the list
chronosx88has left
chronosx88has joined
stphas left
adiaholichas left
adiaholichas joined
ti_gj06has joined
neshtaxmpphas left
inkyhas left
adiaholichas left
adiaholichas joined
etahas left
etahas joined
antranigvhas left
antranigvhas joined
adiaholichas left
adiaholichas joined
andrey.ghas joined
millesimushas joined
soundconcepthas left
andrey.ghas left
wladmishas joined
antranigvhas left
adiaholichas left
neshtaxmpphas joined
stphas joined
wladmishas left
adiaholichas joined
ti_gj06has left
kyemxdenhas left
inkyhas joined
kyemxdenhas joined
wladmishas joined
adiaholichas left
papatutuwawahas joined
chronosx88has left
chronosx88has joined
adiaholichas joined
Kevhas left
Kevhas joined
jgarthas left
harry837374884has left
harry837374884has joined
Holger
goffi: Is there value in supporting this things for retrieving PubSub items both with and without RSM?
վարյաhas left
վարյաhas joined
Holger
I.e. can't we just say "if you want sane behavior, use RSM" (and thereby kinda discourage the PubSub-specific mechanism, and kick it should we ever come up with a PubSub 2.0)?
jonas’
Holger, RSM is orthogonal to that
jonas’
RSM would only order relatively to the internal order of the pubsub storage, which is undefinde as per '60
jonas’
nothing says that it needs to be chronological or whatever
Holger
jonas’: I'm talking about '413. It currently extends both the' 60 mechanism and RSM.
jonas’
oh, sorry :)
jonas’
nvm me then, hopefully
Wojtekhas joined
Holger
I'm unhappy with having a generic mechanism plus specific mechanisms in at least '60 and now also '313.
Holger
For no good reason, AFAICS (and '313 is even Stable now).
millesimushas left
jonas’
why do 90% of people not understand how RSM works? :(
jonas’
I'm tired of explaining this.
jonas’
(and why whatever RSM does (except maybe reversal of ordering) is completely orthogonal to any selection features the underlying protocol may offer)
MattJsends hugs to jonas’
MattJ
It's okay
Holger
Flipping pages is "selecting"?
Zash
Hack!
Holger
How's it different from the ordering thing in 0413, which is supposed to be an RSM extension, no?
Holger
Ah "except reversal of ordering".
MattJ
Flipping pages is 1) not in RSM 2) not likely to be added to RSM 3) one of the most requested things "missing" from 313 (despite my disagreement)
Holger
MattJ, I'd never deny any of those 🙂
Holger
MattJ, the thing I don't get is how that's specific to MAM.
MattJ
MAM is (was?) the only thing that delivers results the way it does
MattJ
RSM was designed with things like disco in mind where results are a simple list embedded into a single stanza, and flipping makes zero sense
MattJ
The problem with MAM is that developers wanted to render/store results as they are received, instead of after the last result set is fully received
Holger
'413 seems to manage to extend RSM despite those original use cases, no?
inkyhas left
MattJ
and then they additionally wanted the last one first
MattJ
I can't comment on 413, I've neither fully reviewed it or implemented it
MattJ
It didn't exist at the time, and nobody proposed it at the time, and those are the root facts :)
Holger
Whatever, it's too late for MAM. But maybe not too late for '413 🙂
Kev
To be fair, RSM explicitly has text in it saying that people don't need to request the entire result set and may just want some pages of it based on UI actions.
Kev
So I don't think the assertion that people doing that was only imagined for MAM is true.
neshtaxmpphas left
MattJ
Maybe I missed it, but I didn't see anyone make such assertions
wladmishas left
Kev
Was that not what you meant by "The problem with MAM is that developers wanted to render/store results as they are received, instead of after the last result set is fully received"?
MattJ
I mean simply that MAM breaks the results (of a single page) into multiple stanzas
MattJ
and this leads to the apparent desire to control the order of results within a single page
Kev
Oh, you mean people want to renderer as they're received *within* a result page?✎
MattJ
(instead of within the full result set)
Kev
Oh, you mean people want to render as they're received *within* a result page? ✏
MattJ
Yes
Kev
It does simplify the client logic quite a lot if you only have to append/prepend to your chat log, rather than needing to inject in the middle.
neshtaxmpphas joined
soundconcepthas joined
Holger
I dunno maybe jonas’ is right and I'm just too stupid to understand the great picture. But in my book, (1) '313 extends RSM, but makes that extension specific to MAM for no reason obvious to me. And that (2) '413 extends RSM in the same way, just as a generic, reusable solution (yay). And that (3) '413 _also_ extends the PubSub-specific way for no reason obvious to me.
debaclehas left
jonas’
I didn't look at '413 beyond its title recently, so maybe (2) and (3) are right ;)
Holger
So we end up with at least three different solutions to the exact same problem, which doesn't seem like optimal protocol design to me.
Holger
(And apart from redundant code, you also end up having to think about how to handle conflicting requests and whatnot.)
Holger
I understand it's too late to avoid the duplication in '313, so my question simply was whether (2) vs. (3) could be avoided.
Sam
Hot take: if you're "tired of explaining this" and "90% of people [do not] understand how RSM works" then that's a good indication that the current state of the world is bad and should be changed.
Sam
Also +1 to everything Holger said, I get lost and confused all over again every time I look at any of this.
jonas’
Sam, it is so obvious and sensible to me though that I have absolutely no clue what to do about it.
jonas’
It needs someone who both understands why the current design is sensible *and* why people fail to understand it to make something better, and I don't know if anyone is in that place.
Sam
I think we need someone who understands *if* the current design is sensible *and* why people fail to understand it, but otherwise yah
Sam
But I dispute the assumption that because one person understands it it's sensible.
jonas’
it is very similar to how SQL works, fwiw, which is what I'd base the sensibility on. SQL is good at returning slices of data.
jonas’
well, not exactly *very good*, but RSM improves in exactly those areas where SQL lacks (by making "LIMIT" not based on indices but on opaque stable identifiers of the records), but yeah.
jonas’
tired, as I said
Holger
JFTR I think the question whether 0059 is sensible and generally well-understood is somewhat unrelated to my point. I was talking about duplication of the '413 functionality (Order-By) and jonas’ response was like "you're wrong (except maybe for the order-by thing you're talking about)" 😛
flow
> why people fail to understand it
probably due the lack of good documentation
sonnyhas left
sonnyhas joined
jonas’
I have a branch somewhere to improve it in '59, but I failed to find words which weren't already in there.
chronosx88has left
chronosx88has joined
flow
every improvement is good, but I was more thinking about examples and rationale provided in e.g. modernxmpp
Kev
ISTR not a misunderstanding of '59, but rather an ideological disagreement on the nature of the result set being managed.
soundconcepthas left
soundconcepthas joined
etahas left
etahas joined
Holger
jonas’, MattJ, just BTW, before-id and after-id might be filter criteria rather than paging tools, but I don't get how those are specific to MAM either. RSM is always operating on IDs, and other RSM users might be just as interested in those selection features, no?
jonas’
it's an implementation detail of MAM that the things used by RSM are the same as the things used by MAM
Holger
Yes. Seems unrelated to my point 🙂
Marandahas left
Mjolnir Archonhas left
jonas’
except for the fun wording in MAM (which, since before/after id makes no sense anymore), RSM could AES-encrypt the IDs and things should continue to work just as if it hadn't
adiaholichas left
Mjolnir Archonhas joined
Marandahas joined
mjkhas left
ti_gj06has joined
marc0shas left
marc0shas joined
Kev_has joined
Kev_has left
Kev_has joined
Kev_has left
Holger
Different topic:
> servers that understand the 'include-groupchat' field and store groupchat messages in the user's archive must advertise the 'urn:xmpp:mam:2#groupchat-available' feature
I'd assume a common configuration might be that servers store MIX but not MUC messages in user archives. In that case they'd probably just advertise #groupchat-available because clients expecting MUC messages won't fall apart if they receive an empty response, I guess?
antranigvhas joined
Holger
Or to put it differently, what's the point of the #groupchat-available feature? Allowing the client to decide whether it's necessary to query the room archive directly?
jonas’
Holger, no, for MIX that's covered by a different feature indicating MIX-PAM support I think
Holger
I see no such feature.
jonas’
sadface
Kev
Holger: Roughly speaking, it's to resolve a heisenstate so clients can know whether they *might* receive gc messages or not.
marc0shas left
marc0shas joined
alex11has left
alex11has joined
Kev
So a client can say "I'm happy to receive gc" or "I must never receive gc", and the server feature needs advertising because unless the server supports it the client including such a clause is illegal.
Holger
Kev, but there's the separate #groupchat-field feature for that.
Kev
Let me try to remind myself what I did, then.
marc0shas left
marc0shas joined
Kev
Oh, yes, you're right, this one is the one the server uses to announce that it does store gc messages in the archive.
Holger
jonas’, ah sorry there's 'urn:xmpp:mix:pam:2#archive', I failed at searching.
Holger
So for that MIX-only setup, the server would announce 'urn:xmpp:mix:pam:2#archive' but not #groupchat-available? I.e. the latter is really #muc-available?
kyemxdenhas left
kyemxdenhas joined
Kev
It's possibly of limited use, but the change did remove Council objections.
And for MIX there's no need for the client to explicitly ask for groupchat messages?
Kev
As-written #groupchat-available is any groupchat.
jonas’
Holger, good question
sonnyhas left
Kev
We could update the text for pam#archive so that something like "If MIX messages are the only groupchat messages stored in the archive, #archive may be advertised in stead of #groupchat-available" or somesuch.
sonnyhas joined
kyemxdenhas left
kyemxdenhas joined
Holger
Ok from reading the specs these things aren't clear to me. I think I mentioned on the list that "MUC vs. MIX" would be good to clarify during LC 😛
Holger
Yeah that would make sense IMO.
MattJ
People still think MIX in a user's MAM is a good thing?
Holger
Not me!
Kev
I do.
Holger
But from reading MIX specs I understand that's the recommended setup.
jonas’
Me neither.
Holger
I think at the very least, we need good dedup mechanisms, first.
Holger
Else we'll end up like Matrix, just MUCH worse.
MattJ
Agreed
jonas’
maybe gap filling before dedup.
jonas’
otherwise, where would the dups come from ;)
Holger
And that, yes. Again "like Matrix but worse".
adiaholichas joined
jonas’
it shouldn't be too hard in theory, given that we have a single source of truth regarding message order for each room :)
huhnhas left
xeckshas left
Kev
You say "Matrix but worse", but Matrix *does* have some nice properties.
soundconcepthas left
MattJ
We don't disagree :)
marc0shas left
marc0shas joined
Kev
So, any time we solve things in a different way to Matrix, it's likely to be worse in some ways, and hopefully better in others.
MattJ
But it's necessarily very complex to get those nice properties, while MIX (+ MIX messages in user MAM) is a half-baked incomplete solution to obtaining those properties in XMPP
Holger
Kev: Absolutely. We end up with their downsides (worse) while gaining little of their advantages.
Kev
Should we drop MIX and do MOX (Matrix over XMPP) instead, then? :)
MattJ
It doesn't remove the centralization of channels on a particular service, and it introduces inconsistent history upon any federation hiccups
antranigvhas left
Kev
The latter of those is fairly solvable, I believe. Solving the former would be so nice (and I think you end up with a Matrix model, more or less, when you do). FMUC solves it in the cheapest possible way (or at least close) for when bandwidth is heavily limited and intermittent, but there's a significant tradeoff because of that.
Holger
Well I guess we don't necessarily have to agree / solve these things immediately as long as we have proper MAM/PAM/MIX feature announcements (and no normative text towards user archives in MIX). With the downside that MIX client devs will have to implement different solutions if they want to support both models.
Rixon 👁🗨has left
homebeachhas left
Matthewhas left
uhoreghas left
Server Stats Discoverer (traveler bot)has left
Half-Shothas left
Server Stats Discoverer (traveler bot)has joined
Half-Shothas joined
Matthewhas joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
emushas left
Shackletonhas joined
antranigvhas joined
վարյաhas left
վարյաhas joined
wendyhas left
adiaholichas left
վարյաhas left
վարյաhas joined
adiaholichas joined
x51has joined
ti_gj06has left
norkkihas joined
millesimushas joined
norkkihas left
antranigvhas left
antranigvhas joined
ti_gj06has joined
papatutuwawahas left
Wojtek
quick question about https://xmpp.org/extensions/xep-0280.html#mandatory-support - should we advertise "urn:xmpp:carbons:rules:0" only if the exact set of rules is implemented (i.e. forwarding anything else on top of that set would mean no feature being advertised)?
Shackletonhas left
Kev
It's intended to be exact (the following bit says the client can assume it's the exact set).
marc0shas left
Holger
How does it help the client to be aware of the rules?
Wojtek
ok, thanks :-)
Kev
Holger: I'm not convinced that it does, but this was a compromise reached so we didn't hold up Carbons forever while waiting for the perfect immutable set of rules to be defined.
pasdesushihas left
adiaholichas left
adiaholichas joined
Marandahas left
Mjolnir Archonhas left
antranigvhas left
xeckshas joined
Mjolnir Archonhas joined
Marandahas joined
adiaholichas left
Calvinhas joined
pasdesushihas joined
ti_gj06has left
adiaholichas joined
harry837374884has left
harry837374884has joined
wladmishas joined
wladmishas left
adiaholichas left
x51has left
pasdesushihas left
pasdesushihas joined
emushas joined
adiaholichas joined
karoshihas left
karoshihas joined
marc0shas joined
x51has joined
neshtaxmpphas left
adiaholichas left
soundconcepthas joined
lorddavidiiihas left
intosihas left
adiaholichas joined
intosihas joined
x51has left
malthehas joined
neshtaxmpphas joined
Holger
> A Pubsub entity supporting Result Set Management (XEP-0059) [16] SHOULD include a feature of "http://jabber.org/protocol/pubsub#rsm" in its disco#info response, to make it clear that the RSM feature is for PubSub, and not for e.g., Message Archive Management (XEP-0313) [17].
[ https://xmpp.org/extensions/xep-0060.html#subscriber-retrieve-returnsome ]
This doesn't work for PEP, right ...
adiaholichas left
Holger
goffi, if a server supports e.g. '413 Order-By for PubSub, the server is supposed to announce *two* features, right? I.e.:
```
<feature var='urn:xmpp:order-by:1'/>
<feature var='urn:xmpp:order-by:1@http://jabber.org/protocol/pubsub'/>
```
What's the point of announcing the first one?
stpeterhas joined
stpeterhas left
goffi
Holger: yes. The first one makes it easy to check who supports order-by in any way.
Holger
Hmmm.
Holger
Who would want to check that, and why? 🙂
sonnyhas left
lovetoxhas left
florettahas left
sonnyhas joined
վարյաhas left
վարյաhas joined
goffi
statistics I guess. But feel free to send your concern on standard@, I may remove it from a future version if people doesn't see any point in that.
goffi
people don't*
sonnyhas left
sonnyhas joined
Holger
The idea behind my question was that this *could* be reserved for some generic '59 extension, such as omitting the `by` attribute and just reversing the default order of the result set by stating `<order-by desc='true'/>` or so. But of course this could always be done by bumping the namespace.
Holger
So, not important.
wladmishas joined
վարյաhas left
վարյաhas joined
lovetoxhas joined
malthehas left
adiaholichas joined
florettahas joined
intosihas left
intosihas joined
alex11has left
wladmishas left
Danielhas left
Danielhas joined
inkyhas joined
huhnhas joined
adiaholichas left
adiaholichas joined
ti_gj06has joined
malthehas joined
moparisthebest
> SQL is good at returning slices of data.
moparisthebestmumbles something about Oracle rownum before wandering off
chronosx88has left
chronosx88has joined
malthehas left
antranigvhas joined
norkkihas joined
norkkihas left
wendyhas joined
wendyhas left
soundconcepthas left
soundconcepthas joined
adiaholichas left
adiaholichas joined
antranigvhas left
antranigvhas joined
sonnyhas left
sonnyhas joined
adiaholichas left
sonnyhas left
sonnyhas joined
soundconcepthas left
adiaholichas joined
antranigvhas left
soundconcepthas joined
Apollohas left
վարյաhas left
վարյաhas joined
inkyhas left
վարյաhas left
վարյաhas joined
վարյաhas left
վարյաhas joined
qrpnxzhas left
qrpnxzhas joined
antranigvhas joined
qrpnxzhas left
qrpnxzhas joined
debaclehas joined
arcxihas left
me9has joined
atomicwatchhas left
adiaholichas left
arcxihas joined
Apollohas joined
adiaholichas joined
antranigvhas left
millesimushas left
Marandahas left
Mjolnir Archonhas left
inkyhas joined
millesimushas joined
lorddavidiiihas joined
lorddavidiiihas left
Shackletonhas joined
andrey.ghas joined
Mjolnir Archonhas joined
Marandahas joined
lorddavidiiihas joined
lorddavidiiihas left
belonghas joined
lorddavidiiihas joined
lorddavidiiihas left
Apollohas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
adiaholichas left
adiaholichas joined
lorddavidiiihas joined
lorddavidiiihas left
antranigvhas joined
lorddavidiiihas joined
adiaholichas left
adiaholichas joined
inkyhas left
sonnyhas left
antranigvhas left
sonnyhas joined
soundconcepthas left
soundconcepthas joined
belonghas left
belonghas joined
xsfhas joined
debaclehas left
antranigvhas joined
belonghas left
x51has joined
qrpnxzhas left
Shackletonhas left
qrpnxzhas joined
qrpnxzhas left
qrpnxzhas joined
goffihas left
qrpnxzhas left
qrpnxzhas joined
papatutuwawahas joined
nycohas left
wladmishas joined
harry837374884has left
harry837374884has joined
nycohas joined
x51has left
wladmishas left
wladmishas joined
BASSGODhas left
adiaholichas left
wladmishas left
BASSGODhas joined
soundconcepthas left
Kevhas left
Kevhas joined
qrpnxzhas left
qrpnxzhas joined
qrpnxzhas left
qrpnxzhas joined
Kevhas left
Kevhas joined
wladmishas joined
intosihas left
Kevhas left
Kevhas joined
belonghas joined
adiaholichas joined
Kevhas left
sanderhas joined
Kevhas joined
wladmishas left
wladmishas joined
adiaholichas left
me9has left
me9has joined
wladmishas left
wladmishas joined
Kevhas left
Apollohas joined
adiaholichas joined
Kevhas joined
Mikaelahas joined
intosihas joined
andrey.ghas left
wladmishas left
Kevhas left
Kevhas joined
adiaholichas left
inkyhas joined
belonghas left
millesimushas left
millesimushas joined
neshtaxmpphas left
neshtaxmpphas joined
intosihas left
wladmishas joined
samuelhas joined
intosihas joined
lorddavidiiihas left
djorzhas joined
belonghas joined
adiaholichas joined
xeckshas left
antranigvhas left
antranigvhas joined
adiaholichas left
wladmishas left
wladmishas joined
lorddavidiiihas joined
x51has joined
adiaholichas joined
soundconcepthas joined
beanhas joined
lorddavidiiihas left
norkkihas joined
me9has left
antranigvhas left
norkkihas left
lorddavidiiihas joined
lorddavidiiihas left
adiaholichas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
adiaholichas joined
Lopmenhas joined
inkyhas left
lorddavidiiihas joined
samuelhas left
lorddavidiiihas left
harry837374884has left
harry837374884has joined
lorddavidiiihas joined
xeckshas joined
lorddavidiiihas left
wladmishas left
BASSGODhas left
lorddavidiiihas joined
adiaholichas left
lorddavidiiihas left
adiaholichas joined
lorddavidiiihas joined
lorddavidiiihas left
intosihas left
lorddavidiiihas joined
lorddavidiiihas left
malthehas joined
intosihas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
millesimushas left
lorddavidiiihas joined
lorddavidiiihas left
adiaholichas left
qrpnxzhas left
qrpnxzhas joined
lorddavidiiihas joined
lorddavidiiihas left
Kevhas left
lorddavidiiihas joined
soundconcepthas left
lorddavidiiihas left
Yagizahas left
Kevhas joined
lorddavidiiihas joined
lorddavidiiihas left
inkyhas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
intosihas left
lorddavidiiihas joined
intosihas joined
lorddavidiiihas left
samuelhas joined
qrpnxzhas left
qrpnxzhas joined
qrpnxzhas left
qrpnxzhas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
papatutuwawahas left
lorddavidiiihas joined
lorddavidiiihas left
Kevhas left
lorddavidiiihas joined
lorddavidiiihas left
adiaholichas joined
Kevhas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
malthehas left
intosihas left
x51has left
adiaholichas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
marc0shas left
marc0shas joined
lorddavidiiihas left
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
adiaholichas joined
lorddavidiiihas joined
lorddavidiiihas left
xeckshas left
belonghas left
marc0shas left
marc0shas joined
lorddavidiiihas joined
lorddavidiiihas left
intosihas joined
debaclehas joined
lorddavidiiihas joined
lorddavidiiihas left
papatutuwawahas joined
adiaholichas left
xeckshas joined
lorddavidiiihas joined
millesimushas joined
kyemxdenhas left
lorddavidiiihas left
kyemxdenhas joined
x51has joined
lorddavidiiihas joined
lorddavidiiihas left
jgarthas joined
adiaholichas joined
lorddavidiiihas joined
lorddavidiiihas left
Wojtekhas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
belonghas joined
lorddavidiiihas left
adiaholichas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
antranigvhas joined
lorddavidiiihas joined
intosihas left
lorddavidiiihas left
Kevhas left
adiaholichas joined
archas left
archas joined
lorddavidiiihas joined
lorddavidiiihas left
Kevhas joined
lorddavidiiihas joined
lorddavidiiihas left
millesimushas left
adiaholichas left
lorddavidiiihas joined
malthehas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
Kevhas left
huhnhas left
lorddavidiiihas joined
lorddavidiiihas left
marc0shas left
marc0shas joined
Kevhas joined
lorddavidiiihas joined
malthehas left
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
neshtaxmpphas left
lorddavidiiihas joined
harry837374884has left
lorddavidiiihas left
marc0shas left
lorddavidiiihas joined
marc0shas joined
lorddavidiiihas left
Kevhas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
Kevhas joined
lorddavidiiihas left
marc0shas left
marc0shas joined
lorddavidiiihas joined
marc0shas left
marc0shas joined
lorddavidiiihas left
marc0shas left
marc0shas joined
lorddavidiiihas joined
lorddavidiiihas left
archas left
archas joined
archas left
mjkhas joined
archas joined
lorddavidiiihas joined
norkkihas joined
lorddavidiiihas left
lorddavidiiihas joined
norkkihas left
lorddavidiiihas left
archas left
archas joined
archas left
lorddavidiiihas joined
archas joined
lorddavidiiihas left
chronosx88has left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
antranigvhas left
Kevhas left
lorddavidiiihas joined
neshtaxmpphas joined
emushas left
lorddavidiiihas left
antranigvhas joined
jl4has joined
Kevhas joined
goffihas joined
վարյաhas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
jl4has left
lorddavidiiihas joined
lorddavidiiihas left
adiaholichas joined
lorddavidiiihas joined
lorddavidiiihas left
harry837374884has joined
lorddavidiiihas joined
lorddavidiiihas left
antranigvhas left
lorddavidiiihas joined
lorddavidiiihas left
intosihas joined
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
antranigvhas joined
lorddavidiiihas joined
lorddavidiiihas left
adiaholichas left
kyemxdenhas left
kyemxdenhas joined
lorddavidiiihas joined
lorddavidiiihas left
adiaholichas joined
lorddavidiiihas joined
lorddavidiiihas left
marc0shas left
marc0shas joined
lorddavidiiihas joined
lorddavidiiihas left
inkyhas left
intosihas left
lorddavidiiihas joined
adiaholichas left
jabberjockehas joined
jabberjockehas left
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
adiaholichas joined
chronosx88has joined
archas left
archas joined
lorddavidiiihas joined
lorddavidiiihas left
archas left
archas joined
lorddavidiiihas joined
lorddavidiiihas left
millesimushas joined
lorddavidiiihas joined
adiaholichas left
millesimushas left
emushas joined
Kevhas left
Kevhas joined
pasdesushihas left
pasdesushihas joined
belonghas left
COM8has joined
chronosx88has left
chronosx88has joined
վարյաhas joined
inkyhas joined
archas left
adiaholichas joined
jonathanhas joined
wladmishas joined
Titihas left
Titihas joined
belonghas joined
malthehas joined
adiaholichas left
lorddavidiiihas left
millesimushas joined
adiaholichas joined
MSavoritiashas left
millesimushas left
ti_gj06has left
adiaholichas left
Mikaelahas left
me9has joined
adiaholichas joined
intosihas joined
wladmishas left
wladmishas joined
adiaholichas left
adiaholichas joined
wladmishas left
Kev
GSoC has been announced, and it's quite different. Rough summary: Varying project lengths, people don't have to be students, but do have to be new (can't have existing contributors).
COM8has left
djorzhas left
x51has left
wladmishas joined
jinxdhas joined
qrpnxzhas left
qrpnxzhas joined
florettahas left
qrpnxzhas left
qrpnxzhas joined
qrpnxzhas left
qrpnxzhas joined
qrpnxzhas left
emus
But it is not yet on their website, right?
https://summerofcode.withgoogle.com/archive/
TL;DR
- newcomers of open source that are 18 years and older (can be student, but no need)
- support both medium sized projects (~175 hours) and large projects (~350 hours)
- mentors and their GSoC Contributors can decide together if they want to extend the deadline for the project up to 22 weeks (I think it has to start from June)
beanhas left
emus
Kev - I understand I have to work into two directions now:
- Apply as organization
- Prepare the community
CC: flow
sebastianhas left
sebastianhas joined
Kev
I've not checked when applications open, I'm afraid, but certainly I think we're now in a position we can prepare the community.
emus
Did not saw this yet
intosihas joined
emus
Mentoring organizations can begin submitting applications to Google (~2 weeks)