Re: [xwiki-devs] [xwiki-users] Lots of disabled Yahoo email addresses on the xwiki.org lists

[Sergiu Dumitriu]

By the way, all of Pascal's and Julio's emails (and other yahoo users)
end up in my spam folder because of the broken DKIM signatures.

On 11/07/2016 09:24 AM, Sergiu Dumitriu wrote:
> This is partially XWiki's infrastructure fault, too.
> 
> DMARC doesn't work well with mailing lists, since they tend to break
> DKIM signatures. The only way to fix the problem (at least for the
> majority of emails) is to remove the footer from the configuration.
> 
> So, options:
> 
> - remove the footer, which means that "incompetent" users will have a
> hard time finding information about unsubscribing, but allows users from
> modern email providers to subscribe
> - keep the footer, which makes it harder for legitimate users to stay
> subscribed
> 
> On 11/02/2016 07:57 AM, Vincent Massol wrote:
>> Hi everyone,
>>
>> Just to let you know that on the 28th of October, there were 234 members of 
>> the xwiki users list who’ve been automatically disabled (ie they’re not 
>> going to receive mails). This is apparently caused by a change in Yahoo’s 
>> email policy:
>>
>> : host gmail-smtp-in.l.google.com[74.125.133.27] said:
>>550-5.7.1 Unauthenticated email from yahoo.com.br is not accepted due to
>>550-5.7.1 domain's DMARC policy. Please contact the administrator of
>>550-5.7.1 yahoo.com.br domain if this was a legitimate mail. Please visit
>>550-5.7.1  https://support.google.com/mail/answer/2451690 to learn about
>>the 550 5.7.1 DMARC initiative. o3si17254181wjx.109 - gsmtp (in reply to
>>end of DATA command)
>>
>> So if you’re in that case, please contact Yahoo as mentioned in the message 
>> above.
>>
>> Thanks
>> -Vincent
> 
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [xwiki-users] Lots of disabled Yahoo email addresses on the xwiki.org lists

[Sergiu Dumitriu]

Forgot to mention the second component of DMARC, SPF, which is also
partially broken by XWiki's infrastructure. The problem with SPF is that
mails for @xwiki.org are forwarded by xwiki.org to xwiki.com
(gmail.com in reality), and this forwarding isn't allowed by a strictly
configured SPF domain. There's no easy fix for this, the only solution
would be to replace self-hosted mailing lists with Google Groups, so
that xwiki.org also becomes an alias for gmail.com

On 11/07/2016 09:24 AM, Sergiu Dumitriu wrote:
> This is partially XWiki's infrastructure fault, too.
> 
> DMARC doesn't work well with mailing lists, since they tend to break
> DKIM signatures. The only way to fix the problem (at least for the
> majority of emails) is to remove the footer from the configuration.
> 
> So, options:
> 
> - remove the footer, which means that "incompetent" users will have a
> hard time finding information about unsubscribing, but allows users from
> modern email providers to subscribe
> - keep the footer, which makes it harder for legitimate users to stay
> subscribed
> 
> On 11/02/2016 07:57 AM, Vincent Massol wrote:
>> Hi everyone,
>>
>> Just to let you know that on the 28th of October, there were 234 members of 
>> the xwiki users list who’ve been automatically disabled (ie they’re not 
>> going to receive mails). This is apparently caused by a change in Yahoo’s 
>> email policy:
>>
>> : host gmail-smtp-in.l.google.com[74.125.133.27] said:
>>550-5.7.1 Unauthenticated email from yahoo.com.br is not accepted due to
>>550-5.7.1 domain's DMARC policy. Please contact the administrator of
>>550-5.7.1 yahoo.com.br domain if this was a legitimate mail. Please visit
>>550-5.7.1  https://support.google.com/mail/answer/2451690 to learn about
>>the 550 5.7.1 DMARC initiative. o3si17254181wjx.109 - gsmtp (in reply to
>>end of DATA command)
>>
>> So if you’re in that case, please contact Yahoo as mentioned in the message 
>> above.
>>
>> Thanks
>> -Vincent
> 
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [xwiki-users] Lots of disabled Yahoo email addresses on the xwiki.org lists

[Sergiu Dumitriu]

This is partially XWiki's infrastructure fault, too.

DMARC doesn't work well with mailing lists, since they tend to break
DKIM signatures. The only way to fix the problem (at least for the
majority of emails) is to remove the footer from the configuration.

So, options:

- remove the footer, which means that "incompetent" users will have a
hard time finding information about unsubscribing, but allows users from
modern email providers to subscribe
- keep the footer, which makes it harder for legitimate users to stay
subscribed

On 11/02/2016 07:57 AM, Vincent Massol wrote:
> Hi everyone,
> 
> Just to let you know that on the 28th of October, there were 234 members of 
> the xwiki users list who’ve been automatically disabled (ie they’re not going 
> to receive mails). This is apparently caused by a change in Yahoo’s email 
> policy:
> 
> : host gmail-smtp-in.l.google.com[74.125.133.27] said:
>550-5.7.1 Unauthenticated email from yahoo.com.br is not accepted due to
>550-5.7.1 domain's DMARC policy. Please contact the administrator of
>550-5.7.1 yahoo.com.br domain if this was a legitimate mail. Please visit
>550-5.7.1  https://support.google.com/mail/answer/2451690 to learn about
>the 550 5.7.1 DMARC initiative. o3si17254181wjx.109 - gsmtp (in reply to
>end of DATA command)
> 
> So if you’re in that case, please contact Yahoo as mentioned in the message 
> above.
> 
> Thanks
> -Vincent


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Brainstorming] XWiki Architecture after 10+ years: what's next?

[Caleb James DeLisle]

Well this is a very interesting topic of discusssion and me and the XWiki SAS 
Research team
would like to do whatever we can to help evolve XWiki forward (but don't let us 
get in the way!)


On 04/11/16 14:34, Vincent Massol wrote:

Hi devs,

We’ve been developing XWiki over 10 years now. I’d like to start a discussion 
about major architecture changes we may want to do in the coming 5 years.

With this discussion I have 2 goals in mind:
* Prepare XWiki for the challenges ahead (prevent it from being obsolete, have 
an architecture that can adapt to changes, etc)
* Make XWiki an interesting project to develop on for its developers 
(interesting technologies, interesting intellectual challenges, etc)



The futurist in me sees an ongoing struggle between hot new technologies and 
good working systems
as a reflection of the struggle between engineers who love to play and learn 
vs. managers who
have to balance budget. Of course we want something of a middle road where we 
pluck out the good
*ideas* from modern technologies without being swept up in every fad.




Let me start with a few large architecture items I can think about:

* Polyglotism for the front end. This is the ability to code the XWiki UI in 
any language (PHP, Node.js, javascript, native applications, etc). Right now 
XWiki UIs are coded mostly using Velocity (and a bit of javascript). It would 
be nice to be more agnostic and to attract non java developers. The core 
(Server part) could still be in Java but it would be nice that UIs and 
extensions could be developed in any language. One architecture that could 
achieve this would be to have a Core Server exposing all operations as REST 
APIs. This would decouple the Server part from the Client part. It also means 
having all XWiki API modules offering REST APIs and making it extra easy to add 
new REST APIs.



I agree with the thinking because I feel Velocity has lived out it's useful 
life, it drops all of
its variables to the global scope and doesn't have functions which makes 
debugging terrible and
it is positively alien to almost everyone who comes to XWiki.

That said, I want to caution about the lure of anything-anywhere-polyglotism. 
Each language has
it's own ecosystem. Virt.x project made a system where they advertized you 
could program in Java,
Javascript, Groovy, Ruby or Ceylon. As far as I know, this project has not 
gotten any significant
traction and I think this is because their Javascript is still alien to the 
Nodejs community,
their Ruby is still alien to the Rails community, etc.

My opinion is we must choose between being a little piece of a bigger ecosystem 
(node, php, etc.)
or we must build our own ecosystem (what we have been doing so far). That said, 
I still think we
should begin phasing out Velocity.

My recommendation is we pick a language which works reasonably well for our 
needs yet has
significant familiarity and then begin to make this language the Lingua franca 
of XWiki and begin
porting our Velocity code and documentation over to it.




* Greatly simplify development of XWiki Extensions. There are several 
directions that I can think of:
** Direction 1: Expose the resources making up an Extension on the file system 
and let users use their favorite tools to write the content (web IDEs, text 
editors, etc)
** Direction 2: Develop an IDE in the cloud. Again there are 2 options here:
*** Take ownership of the XWiki Web IDE application  and push it much further
*** Go in the direction of integrating with a well-known cloud IDE such as 
Eclipse Che/CodeEnvy (with pre-built workspaces, docker VMs and one click 
deploy to test your extension, direct deployment of extensions to e.x.o, etc).
** Other: In general, make it faster to develop extensions. The advantage of 
the Cloud IDE or Web IDE is that it removes the burden of setting up the tools 
on your local machine (maven, java, etc) so someone new to XWiki should be 
operational under 5 minutes to run the first tutorial.



From observation of the patterns which engineers choose to take when not 
pushed, I find that they
are generally more comfortable with direction 1. Obviously we in the Research 
team would be thrilled
to see WebIDE take on a new life as an XWiki product but I find that engineers 
will go to war for
their text editor and prefer a process which is more inline with what they know 
from nodejs, php or
ruby on rails.

The issues which I have observed blocking people who come to the platform from 
outside are:
* APIs are complex and undiscoverable, it's ok to put them on the website (php, 
nodejs do this) but they need to be first on google when you search XWiki API.
* No clear connection between development and github.
* Release process is crazy: requires maven flags, settings.xml, PGP keys, java 
versions. Compared to `npm publish` or bower where you need only git tag and 
you're done, this is stone age.
* Fragility because of layers of legacy code: for people used to throwing 
things 

Re: [xwiki-devs] Postpone the 8.4 release

[Vincent Massol]

> On 07 Nov 2016, at 10:16, Marius Dumitru Florea 
>  wrote:
> 
> Hi devs,
> 
> The 8.4 release is planned for today but I would like to postpone it for 2
> days, so for Wednesday 9 November, in order to finish:
> 
> * http://jira.xwiki.org/browse/XWIKI-13761
> * http://jira.xwiki.org/browse/XWIKI-13360
> * https://jira.xwiki.org/browse/CKEDITOR-68
> 
> which I believe are very important.
> 
> I hope this is fine with you.

ok for me but Wednesday should be the last delay we do because otherwise we 
might impact too much 8.4.1 which is planned in 2 weeks from today.

Thanks
-Vincent

> Thanks,
> Marius

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] Postpone the 8.4 release

[Marius Dumitru Florea]

Hi devs,

The 8.4 release is planned for today but I would like to postpone it for 2
days, so for Wednesday 9 November, in order to finish:

* http://jira.xwiki.org/browse/XWIKI-13761
* http://jira.xwiki.org/browse/XWIKI-13360
* https://jira.xwiki.org/browse/CKEDITOR-68

which I believe are very important.

I hope this is fine with you.

Thanks,
Marius
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs