emusah 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
Kevemus: No, Mentors/Admins get added automatically.
robertooohas left
ti_gj06has joined
jinxdhas joined
sonnyhas left
sonnyhas joined
jgarthas joined
վարյաhas left
վարյաhas joined
emusah 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
goffihi 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
goffijonas’: I've replied already to your email ;)
jonas’ok, I didn't see that yet :)
goffijonas’: OK make sense, so I guess I'll have to wait, thanks!
wladmishas left
վարյաhas left
վարյաhas joined
adiaholichas left
inkyhas joined
mathieuigoffi: I have not received your message on list duo
adiaholichas joined
goffiI 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
mathieuiGot it now
goffime too
jonas’great, it's not just me who gets delayed by the list server for some reason ;)
ZashI 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
goffijonas’: 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
goffijonas’: 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
Holgergoffi: Is there value in supporting this things for retrieving PubSub items both with and without RSM?
վարյաhas left
վարյաhas joined
HolgerI.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
Holgerjonas’: I'm talking about '413. It currently extends both the' 60 mechanism and RSM.
jonas’oh, sorry :)
jonas’nvm me then, hopefully
Wojtekhas joined
HolgerI'm unhappy with having a generic mechanism plus specific mechanisms in at least '60 and now also '313.
HolgerFor 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’
MattJIt's okay
HolgerFlipping pages is "selecting"?
ZashHack!
HolgerHow's it different from the ordering thing in 0413, which is supposed to be an RSM extension, no?
HolgerAh "except reversal of ordering".
MattJFlipping 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)
HolgerMattJ, I'd never deny any of those 🙂
HolgerMattJ, the thing I don't get is how that's specific to MAM.
MattJMAM is (was?) the only thing that delivers results the way it does
MattJRSM was designed with things like disco in mind where results are a simple list embedded into a single stanza, and flipping makes zero sense
MattJThe 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
MattJand then they additionally wanted the last one first
MattJI can't comment on 413, I've neither fully reviewed it or implemented it
MattJIt didn't exist at the time, and nobody proposed it at the time, and those are the root facts :)
HolgerWhatever, it's too late for MAM. But maybe not too late for '413 🙂
KevTo 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.
KevSo I don't think the assertion that people doing that was only imagined for MAM is true.
neshtaxmpphas left
MattJMaybe I missed it, but I didn't see anyone make such assertions
wladmishas left
KevWas 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"?
MattJI mean simply that MAM breaks the results (of a single page) into multiple stanzas
MattJand this leads to the apparent desire to control the order of results within a single page
KevOh, you mean people want to renderer as they're received *within* a result page?✎
MattJ(instead of within the full result set)
KevOh, you mean people want to render as they're received *within* a result page? ✏
MattJYes
KevIt 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
HolgerI 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 ;)
HolgerSo 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.)
HolgerI understand it's too late to avoid the duplication in '313, so my question simply was whether (2) vs. (3) could be avoided.
SamHot 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.
SamAlso +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.
SamI think we need someone who understands *if* the current design is sensible *and* why people fail to understand it, but otherwise yah
SamBut 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
HolgerJFTR 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
flowevery improvement is good, but I was more thinking about examples and rationale provided in e.g. modernxmpp
KevISTR 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
Holgerjonas’, 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
HolgerYes. 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
HolgerDifferent 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
HolgerOr 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
HolgerI see no such feature.
jonas’sadface
KevHolger: 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
KevSo 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.
HolgerKev, but there's the separate #groupchat-field feature for that.
KevLet me try to remind myself what I did, then.
marc0shas left
marc0shas joined
KevOh, yes, you're right, this one is the one the server uses to announce that it does store gc messages in the archive.
Holgerjonas’, ah sorry there's 'urn:xmpp:mix:pam:2#archive', I failed at searching.
HolgerSo 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
KevIt's possibly of limited use, but the change did remove Council objections.
HolgerAnd for MIX there's no need for the client to explicitly ask for groupchat messages?
KevAs-written #groupchat-available is any groupchat.
jonas’Holger, good question
sonnyhas left
KevWe 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
HolgerOk 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 😛
HolgerYeah that would make sense IMO.
MattJPeople still think MIX in a user's MAM is a good thing?
HolgerNot me!
KevI do.
HolgerBut from reading MIX specs I understand that's the recommended setup.
jonas’Me neither.
HolgerI think at the very least, we need good dedup mechanisms, first.
HolgerElse we'll end up like Matrix, just MUCH worse.
MattJAgreed
jonas’maybe gap filling before dedup.
jonas’otherwise, where would the dups come from ;)
HolgerAnd 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
KevYou say "Matrix but worse", but Matrix *does* have some nice properties.
soundconcepthas left
MattJWe don't disagree :)
marc0shas left
marc0shas joined
KevSo, 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.
MattJBut 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
HolgerKev: Absolutely. We end up with their downsides (worse) while gaining little of their advantages.
KevShould we drop MIX and do MOX (Matrix over XMPP) instead, then? :)
MattJIt doesn't remove the centralization of channels on a particular service, and it introduces inconsistent history upon any federation hiccups
antranigvhas left
KevThe 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.
HolgerWell 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
Wojtekquick 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
KevIt's intended to be exact (the following bit says the client can assume it's the exact set).
marc0shas left
HolgerHow does it help the client to be aware of the rules?
Wojtekok, thanks :-)
KevHolger: 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
Holgergoffi, 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
goffiHolger: yes. The first one makes it easy to check who supports order-by in any way.
HolgerHmmm.
HolgerWho would want to check that, and why? 🙂
sonnyhas left
lovetoxhas left
florettahas left
sonnyhas joined
վարյաhas left
վարյաhas joined
goffistatistics 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.
goffipeople don't*
sonnyhas left
sonnyhas joined
HolgerThe 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.
HolgerSo, 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
KevGSoC 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
emusBut it is not yet on their website, right?
https://summerofcode.withgoogle.com/archive/
emusTL;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
emusKev - I understand I have to work into two directions now:
- Apply as organization
- Prepare the community
CC: flow
sebastianhas left
sebastianhas joined
KevI've not checked when applications open, I'm afraid, but certainly I think we're now in a position we can prepare the community.
emusDid not saw this yet
intosihas joined
emusMentoring organizations can begin submitting applications to Google (~2 weeks)