Ils oublient que 99,9% des packages n'ont aucune vocation commerciale (sauf plex bien evidemment)

Je leur préciserai les chiffres

Limite, hésite pas a m'envoyer un doc avec les grosses stats importantes

(Qu'ils voient qu'on est pas des rigolos non plus )

Et aussi, je n'ai pas pu vérifier les données envoyées par le Package Center au Package Server.

Je laisse le DS411+II du taf en 3.2 (aucun intérêt à migrer), et je n'ai pas de switch chez moi qui fasse du port-mirroring (il est un encore peu cher le Cisco SG 300-10).

Donc je n'ai aucun moyen de voir si Synology a rajouté des variables ou non aux requêtes de Package Center.

Pour l'instant j'utilise ce qui existe en 3.2 :

• timezone
  
• language
  
• unique
  
• arch
  
• major
  
• minor
  
• build
  

En espérant qu'ils comprendront la demande... (TOI DONNER MOI VARIABLES HTTP POST PACKAGE CENTER)

Tu peux sniffer ton réseau sans routeur je pense non? Si c'est du HTTP les paquets sont dispo sur tout le réseau en clair

Modifié le 23 mai 201213 a par Diaoul

Suis pas sur d'avoir tout compris Piwi

Ils ont rajouté une notion de SDK dans leurs packages

Et tu aimerais savoir si il y a des requêtes supplémentaires concernant ce SDK lors des requêtes HTTP du package center ?

Si c'est du HTTP les paquets sont dispo sur tout le réseau en clair

Ah bah heureusement que ce n'est plus le cas, sinon les réseaux d'entreprise actuels seraient ingérables.

Ça existait au temps des hubs, aujourd'hui on n'utilise plus que des switches donc le traffic n'est pas floodé vers toutes les machines du réseau mais dirigé uniquement vers la destination (switching niveau 2).

Laisse tomber Bud, j'ai un autre moyen auquel je n'avais pas pensé pou récupérer mes variables : Package Server (j'aime bien justifier mon pseudo ).

Demande simplement à Synology s'ils ont prévu de fournir un SDK aux développeurs de la communauté ou s'ils comptent se le gardent pour eux.

Et donne leur au passage les 3 variables que j'ai trouvées comme preuve de notre bonne foi.

Yep, je package tout çà ce soir

Mail envoyé :

Hi Chad,

We will wait for your news then

One last question :

One dev noticed something new on Synology package, in the INFO :

For instance, in Media Server, he saw this:

sdkmodversion="1.0"

sdkshareversion="2.0"

sdknetifnameversion="1.0"

So he was wondering if you are planning on releasing a SDK for the community developers, or if it is only for internal purpose

Modifié le 23 mai 201213 a par bud77

@Bud: tu peux aussi leur parler de ça : https://github.com/SynoCommunity/spksrc/issues/81 ?

S'ils veulent mettre yenc dans Python il faudra qu'ils résolvent ce problème.

Je lui pousse çà dès qu'il m'aura répondu

Réponse de ce matin :

Dear Anthony,

We will consider to add them into next python release.

However, lxml module has already installed, so could you check again on this module, it should be there.

For the folder naming, we won't consider the conflict with 3rd party package since we are providing our own package.

The user can choose the package which they like better, such as the 3rd party Python packages, or our Python packages.

All the packages developed by us will not be depended on any 3rd party packages, it's simply our quality control policy, we won't take this risk. But we appreciate the offering.

For the folder naming, we won't consider the conflict with 3rd party package since we are providing our own package.

Traduction : "On est incohérents dans le nommage de nos paquets et on vous emmerde."

Je maintiens l'idée qui consiste à préfixer les paquets (sc_python, sc_umurmur, ...).

Ça va être chiant pour les utilisateurs actuels, mais ça évitera qu'on rencontre à nouveau le problème.

The user can choose the package which they like better, such as the 3rd party Python packages, or our Python packages.

Le paquet Python de Synology était bien présenté dans le Centre de paquets comme une mise à jour de celui de SynoCommuntity, non ?

Mais ça aussi ils ont l'air de s'en foutre complètement.

You :

• Package name : "Python"
  
• Package folder : "/var/packages/Python"
  
• Symlink in "/usr/local/python"
  

Us :

• Package name : "python"
  
• Package folder : "/var/packages/python"
  
• Symlink in "/usr/local/python"
  

We do follow your original convention on this one which is to create a symlink un /usr/local with the same name of the package (you can check your other packages like VPNCenter, etc.)

As a result, upon installation the Package Center does not see any conflict because of the different package names but installing your SPK breaks ours as the symlink in /usr/local/ to our python now points to yours. That is done during the post-install script and/or start-stop-status.

The user ends up with two python packages installed but one broken (ours).

As mentioned previously, sadly, we cannot use your Python package that lacks 12/13 modules (true, lxml is there) and isn't up to date.

So let me sum up :

• You do not want to work with your community on a tool (https://github.com/S...ommunity/spksrc) to provide better packages
  
• You do not want to correct your Python SPKs that doesn't follow your own convention for other SPKs you provided until now. There is no mention of case in your developer guide http://download.syno...er Guide_V2.pdf page 13 but this is implied IMO
  
• You do not fix any of reported bugs here https://github.com/S...ge=1&state=open (some have been discussed by email, some not yet)
  

Python SPK apart, I think this is going in the wrong direction as you reject all possibilities of working together and advices to improve Synology products. I do this myself for free and make SPKs for more that a year and a half now, starting with my DS-207+. This is also the case of superzebulon.

At least, have a little consideration for our work.

Je vais lui envoyer ça. C'est gentil comme mail. C'est quoi son adresse stp bud?

Modifié le 31 mai 201213 a par Diaoul

Chad Jiang chchiang@synology.com

Par contre, rajoute un peu de texte au début, qu'il situe bien le truc

Sure

Par contre je ferai le mail que ce soir.

Modifié le 31 mai 201213 a par Diaoul

Pas de pb, je vais lui répondre ce soir aussi, sur les derniers pb qu'on a eu, mais çà sera un peu très tard, journée et soirée chargée

Bravo pour les détails Diaoul, mais précise-leur quand même que l'incohérence (avec leurs propres specs.) vient d'un problème de casse dans leur lien symbolique.

Mets en forme les lettre P pour que ça soit le plus explicite possible.

Sinon ils vont encore répondre que les problèmes avec des paquets tiers ne les concernent pas alors que c'est leur paquet qui a un problème.

J'ai édité mon post de mail pour être sûr de pas oublier ce soir

Je pense que c'est assez clair maintenant

Rajoute quand même qui tu es et comment tu as eu son mail

Hi,

I am Diaoul and this mail follows SynoCommunity's issue with your recent Python SPK.

FYI SynoCommunity has 3000+ downloads of its Python and SABnzbd SPKs, followed by other Python-based SPKs.

You :

• Package name : "Python"
  
• Package folder : "/var/packages/Python"
  
• Symlink in "/usr/local/python"
  

Us :

• Package name : "python"
  
• Package folder : "/var/packages/python"
  
• Symlink in "/usr/local/python"
  

We do follow your original convention on this one which is to create a symlink un /usr/local with the same name of the package (you can check your other packages like VPNCenter, etc.)

As a result, upon installation the Package Center does not see any conflict because of the different package names but installing your SPK breaks ours as the symlink in /usr/local/ to our python now points to yours. That is done during the post-install script and/or start-stop-status.

The user ends up with two python packages installed but one broken (ours).

As mentioned previously, sadly, we cannot use your Python package that lacks 12/13 modules (true, lxml is there) and isn't up to date.

So let me sum up :

• You do not want to work with your community on a tool (https://github.com/S...ommunity/spksrc) to provide better packages
  
• You do not want to correct your Python SPKs that doesn't follow your own convention for other SPKs you provided until now. There is no mention of case in your developer guide http://download.syno...er Guide_V2.pdf page 13 but this is implied IMO
  
• You do not fix any of reported bugs here https://github.com/S...ge=1&state=open (some have been discussed by email, some not yet)
  
• You do not want to benefit from our knowledge because of a "quality control policy". I think quality is something you can easily check on an open source SPK built with SPKSRC. You can even build your own with it and check it if you like.
  

Python SPK apart, I think this is going in the wrong direction as you reject all possibilities of working together and advices to improve Synology products. I do this myself for free and make SPKs for almost two years now, starting with my DS-207+. This is also the case of superzebulon.

At least, have a little consideration for our work. That'd be good to feel we're heard.

Thanks & Regards,

Diaoul

Dear Diaoul,

Thank you for your feedback, and I think there must be some misunderstanding. We never rejected any cooperation opportunity from our community in the past. I will discuss your feedback with our development team today and hopefully get back to you next Monday. Please stay tuned.

Yours Sincerely,

Modifié le 31 mai 201213 a par Diaoul

Dear Diaoul,

Sorry for the late reply as we have a major Computex show in Taipei, it kept us very busy the past week.

While packing our Python package, I have tried to install your package and make sure that nothing in your package is overlapped.

Some of your information may not be accurate, for example, the folder and binary naming should be:

Synology Python Package:

• Package Name: "Python"
  
• Package Folder: "/var/package/Python"
  
• Symlink in: "/usr/bin/python"
  

Python packages from SynoCommunity:

• Package Name: "python"
  
• Package Folder: "/var/package/python"
  
• Symlink in: "/usr/local/python"
  

As you see above, we didn't really overwrite it, but it will search /usr/bin first, so Synology Python package will be located first.

These 2 python packages play the same role on the system, but they have different external modules.

So, currently users can only choose one of them now. But we are now discussing internally whether we should probably just contribute our codes and merge them into your Community package, so OpenERP can depend on it.

It's good to know our own community, and we are willing to provide any resource/support to help our developer community. For Synology packages, we might need to depend on packages developed by our own at this stage, just for now. I think we will discuss this a little bit more with you down the road. The contribution of the community is very valuable to us, especially like you and "superzebulon", we are hoping you could have a direct communication with our RD engineer, if this is okay with you. Since we are not familiar how SPKSRC works, we are willing to learn about it and find out how to use this system. We will need your help on this.

Voilà le mail que j'ai reçu aujourd'hui. C'est plutôt encourageant.

Modifié le 9 juin 201213 a par Diaoul

Voilà mon nouveau mail, avec un peu de retard

Hi Chad !

Sorry for the very late reply, as I've been pretty busy the past few weeks

I heard Diaoul has mailed you about python, and I'm glad of the outcome

I'm sending you this mail as we have encountered 2 bugs (one of which is already known tho), and we have "small" request

1) When upgrading a package, there is no check for dependency

We updated our python package a few weeks ago, and several of our packages depends on it

We updated 2 others packages, with the dependency on the new python package, but users could still upgrade the packages, while the python wasn't upgraded

There was no big issue, since the python upgrade was just minor.

2) When upgrading a package, the " install_ui_file " are run, while it should only be during the first install

3) One great feature we are currently missing for packages, is an interface during the installation/upgrade of packages, where the user would be prompt to pick a folder

For instance, when installing a package, a popup would appear, to select a folder on the volumes available, which would return the value for the installation/upgrade process

We have many "system unfriendly" users would do not understand that part, and fail to read the help provided

SuperZebulon decided to force users into a single folder, but we decided otherwise, and let the user choose which folder

I've read you are currently on a Computex show, so take your time answering this mail

Again, thanks for your time Chad

Anthony

Réponse (je met le header pour plus de clarté)

from: Chad Jiang chchiang@synology.com

to: Anthony bud <generation.manga@gmail.com>

cc: Synology/Diesel Tsao <dieselt@synology.com>,

Synology/Darren Lin <darrenlin@synology.com>

date:12 June 2012 07:09

Dear Anthony,

Let me introduce you our RD manager, Diesel, and PM, Darren, they will help you answer these questions.

Yours Sincerely,

Modifié le 12 juin 201213 a par bud77

@bud: Le "bug" de Python n'en était pas un. Par manque de Syno pour tester et suite à un long weekend j'avais mal lu le lien symbolique qui a été créé dans le SPKs. Je suis étonné que l'on nous ait remonté des bugs sur ce point alors que visiblement ça devrait pas poser de problème.

Il faudrait vraiment que quelqu'un puisse tester les bugs que l'on nous remonte... C'est assez handicapant.

Perso, j'utilise la majorité de mes SPKs donc quand quelqu'un report que l'installation d'un autre SPK fait tout péter, j'évite de tester sur mon seul Syno

J'ai Diesel et PM dans la boucle moi aussi, je vais faire un peu de documentation pour spksrc et les contacter pour leur présenter.

Diaoul, t'as eu des news de la team R&D ?

Moi absolument aucune depuis le mail que j'ai posté plus haut