Re: Please don't merge mspec changes if you haven't built with all languages enabled
Hi Cesar, No worries. I know how things are. I also commented out some tests in order to get the ads port implemented and forgot to fix that. Actually the c Version is not affected as much (I already fixed it), as the c driver used way less features in order to be smaller. No worries about that. Currently working on getting the Java Tests working again. Then I was planning on adding some more tests based on you pcaps and then fixing the go version. Chris Gesendet von Outlook für Android<https://aka.ms/AAb9ysg> From: Cesar Garcia Sent: Thursday, May 4, 2023 8:14:02 PM To: Apache PLC4X Subject: Re: Please don't merge mspec changes if you haven't built with all languages enabled greetings to all, First of all, sorry for the problem caused by the modifications in the mspec, but I needed to incorporate those modifications to continue with the improvements of the S7 driver in its Java version. I see that the best solution is to separate the project as Luck points out, it would be in the medium term. Now, as a team, I can support Chris with the C version, for which I would need your guidance. Awaiting your comments and guidance. Best regards, El jue, 4 de may de 2023, 1:14 a. m., Christofer Dutz < christofer.d...@c-ware.de> escribió: > And in general your idea is not bad... About releasing mspecs separately. > The only fear I have with this, it's that if we don't want or repo to > become a mess, like that of apache cocoon, we would need to split it up > into many smaller repos and do a LOT more releases. > > Given the current activity here, not sure we want to do that. > > Chris > > Gesendet von Outlook für Android<https://aka.ms/AAb9ysg> > > From: Łukasz Dywicki > Sent: Wednesday, May 3, 2023 4:56:23 PM > To: dev@plc4x.apache.org > Subject: Re: Please don't merge mspec changes if you haven't built with > all languages enabled > > Hello Chris, > What you asking for might effectively stop any contributions to protocol > updates for entire project. There are very few people who can do Java, > C, Go and eventually Python. I know one of goals of Apache PLC4X is > supporting variety of languages, but what you suggest mean that less > and less people will be able contribute mspec fixes. There will be even > less of them with each next language we introduce.. > While I understand it is important to keep consistency, reality is we > have far less people working on C than on Java. Some of languages we > have code generators and drivers for, did and will fall behind. > I'd rather opt for keeping mspecs releases separate from drivers so > plc4j/plc4c and plc4go can pick version they support and stick with it. > This is the way in which we can avoid troubles with new changes which > are implemented in one language but not others. What do you think about > that? > > Best, > Łukasz > > > On 3.05.2023 16:42, Christofer Dutz wrote: > > Hi all, > > > > we’re currently trying to get the S7 driver back working ... even if it > seems as if it is working (When running the ManualS7Test) ... None of the > Integration-Tests are running, because all are disabled. > > This makes quality assurance quite difficult. > > > > Also, the fact that the changes broke the C and the Go versions is > “sub-ideal”. > > > > We’ll try to fix the problems, but I guess it’s going to consume a lot > of time to do so. > > > > But in the future ... if you change mspecs for drivers, you might break > things in other languages, so It’s super important to ensure stuff is > working in all languages. > > > > Also please don’t comment out tests ... I know I found a place where I > did so too and I promise to not do it again. > > > > We really have to pay a bit more attention on not reducing more and more > of our tests. > > > > Chris > > > > > > >
Re: Please don't merge mspec changes if you haven't built with all languages enabled
greetings to all, First of all, sorry for the problem caused by the modifications in the mspec, but I needed to incorporate those modifications to continue with the improvements of the S7 driver in its Java version. I see that the best solution is to separate the project as Luck points out, it would be in the medium term. Now, as a team, I can support Chris with the C version, for which I would need your guidance. Awaiting your comments and guidance. Best regards, El jue, 4 de may de 2023, 1:14 a. m., Christofer Dutz < christofer.d...@c-ware.de> escribió: > And in general your idea is not bad... About releasing mspecs separately. > The only fear I have with this, it's that if we don't want or repo to > become a mess, like that of apache cocoon, we would need to split it up > into many smaller repos and do a LOT more releases. > > Given the current activity here, not sure we want to do that. > > Chris > > Gesendet von Outlook für Android<https://aka.ms/AAb9ysg> > > From: Łukasz Dywicki > Sent: Wednesday, May 3, 2023 4:56:23 PM > To: dev@plc4x.apache.org > Subject: Re: Please don't merge mspec changes if you haven't built with > all languages enabled > > Hello Chris, > What you asking for might effectively stop any contributions to protocol > updates for entire project. There are very few people who can do Java, > C, Go and eventually Python. I know one of goals of Apache PLC4X is > supporting variety of languages, but what you suggest mean that less > and less people will be able contribute mspec fixes. There will be even > less of them with each next language we introduce.. > While I understand it is important to keep consistency, reality is we > have far less people working on C than on Java. Some of languages we > have code generators and drivers for, did and will fall behind. > I'd rather opt for keeping mspecs releases separate from drivers so > plc4j/plc4c and plc4go can pick version they support and stick with it. > This is the way in which we can avoid troubles with new changes which > are implemented in one language but not others. What do you think about > that? > > Best, > Łukasz > > > On 3.05.2023 16:42, Christofer Dutz wrote: > > Hi all, > > > > we’re currently trying to get the S7 driver back working ... even if it > seems as if it is working (When running the ManualS7Test) ... None of the > Integration-Tests are running, because all are disabled. > > This makes quality assurance quite difficult. > > > > Also, the fact that the changes broke the C and the Go versions is > “sub-ideal”. > > > > We’ll try to fix the problems, but I guess it’s going to consume a lot > of time to do so. > > > > But in the future ... if you change mspecs for drivers, you might break > things in other languages, so It’s super important to ensure stuff is > working in all languages. > > > > Also please don’t comment out tests ... I know I found a place where I > did so too and I promise to not do it again. > > > > We really have to pay a bit more attention on not reducing more and more > of our tests. > > > > Chris > > > > > > >
Re: Please don't merge mspec changes if you haven't built with all languages enabled
And in general your idea is not bad... About releasing mspecs separately. The only fear I have with this, it's that if we don't want or repo to become a mess, like that of apache cocoon, we would need to split it up into many smaller repos and do a LOT more releases. Given the current activity here, not sure we want to do that. Chris Gesendet von Outlook für Android<https://aka.ms/AAb9ysg> From: Łukasz Dywicki Sent: Wednesday, May 3, 2023 4:56:23 PM To: dev@plc4x.apache.org Subject: Re: Please don't merge mspec changes if you haven't built with all languages enabled Hello Chris, What you asking for might effectively stop any contributions to protocol updates for entire project. There are very few people who can do Java, C, Go and eventually Python. I know one of goals of Apache PLC4X is supporting variety of languages, but what you suggest mean that less and less people will be able contribute mspec fixes. There will be even less of them with each next language we introduce.. While I understand it is important to keep consistency, reality is we have far less people working on C than on Java. Some of languages we have code generators and drivers for, did and will fall behind. I'd rather opt for keeping mspecs releases separate from drivers so plc4j/plc4c and plc4go can pick version they support and stick with it. This is the way in which we can avoid troubles with new changes which are implemented in one language but not others. What do you think about that? Best, Łukasz On 3.05.2023 16:42, Christofer Dutz wrote: > Hi all, > > we’re currently trying to get the S7 driver back working ... even if it seems > as if it is working (When running the ManualS7Test) ... None of the > Integration-Tests are running, because all are disabled. > This makes quality assurance quite difficult. > > Also, the fact that the changes broke the C and the Go versions is > “sub-ideal”. > > We’ll try to fix the problems, but I guess it’s going to consume a lot of > time to do so. > > But in the future ... if you change mspecs for drivers, you might break > things in other languages, so It’s super important to ensure stuff is working > in all languages. > > Also please don’t comment out tests ... I know I found a place where I did so > too and I promise to not do it again. > > We really have to pay a bit more attention on not reducing more and more of > our tests. > > Chris > > >
Re: Please don't merge mspec changes if you haven't built with all languages enabled
I'm not saying to not work on mspec changes. Just to not merge them back to develop before all languages are ok again. If changes break something, then we need to fix them on a branch, by getting help and then merge them as soon as that's done. Currently, I have no chance of working on any of the things I was planning to, as I need to get the s7 I've working again... And other things. Admittedly this is slightly frustrating, as I had no say in deciding when I'm going to do that. Chris Gesendet von Outlook für Android<https://aka.ms/AAb9ysg> From: Łukasz Dywicki Sent: Wednesday, May 3, 2023 4:56:23 PM To: dev@plc4x.apache.org Subject: Re: Please don't merge mspec changes if you haven't built with all languages enabled Hello Chris, What you asking for might effectively stop any contributions to protocol updates for entire project. There are very few people who can do Java, C, Go and eventually Python. I know one of goals of Apache PLC4X is supporting variety of languages, but what you suggest mean that less and less people will be able contribute mspec fixes. There will be even less of them with each next language we introduce.. While I understand it is important to keep consistency, reality is we have far less people working on C than on Java. Some of languages we have code generators and drivers for, did and will fall behind. I'd rather opt for keeping mspecs releases separate from drivers so plc4j/plc4c and plc4go can pick version they support and stick with it. This is the way in which we can avoid troubles with new changes which are implemented in one language but not others. What do you think about that? Best, Łukasz On 3.05.2023 16:42, Christofer Dutz wrote: > Hi all, > > we’re currently trying to get the S7 driver back working ... even if it seems > as if it is working (When running the ManualS7Test) ... None of the > Integration-Tests are running, because all are disabled. > This makes quality assurance quite difficult. > > Also, the fact that the changes broke the C and the Go versions is > “sub-ideal”. > > We’ll try to fix the problems, but I guess it’s going to consume a lot of > time to do so. > > But in the future ... if you change mspecs for drivers, you might break > things in other languages, so It’s super important to ensure stuff is working > in all languages. > > Also please don’t comment out tests ... I know I found a place where I did so > too and I promise to not do it again. > > We really have to pay a bit more attention on not reducing more and more of > our tests. > > Chris > > >
Re: Please don't merge mspec changes if you haven't built with all languages enabled
Hello Chris, What you asking for might effectively stop any contributions to protocol updates for entire project. There are very few people who can do Java, C, Go and eventually Python. I know one of goals of Apache PLC4X is supporting variety of languages, but what you suggest mean that less and less people will be able contribute mspec fixes. There will be even less of them with each next language we introduce.. While I understand it is important to keep consistency, reality is we have far less people working on C than on Java. Some of languages we have code generators and drivers for, did and will fall behind. I'd rather opt for keeping mspecs releases separate from drivers so plc4j/plc4c and plc4go can pick version they support and stick with it. This is the way in which we can avoid troubles with new changes which are implemented in one language but not others. What do you think about that? Best, Łukasz On 3.05.2023 16:42, Christofer Dutz wrote: Hi all, we’re currently trying to get the S7 driver back working ... even if it seems as if it is working (When running the ManualS7Test) ... None of the Integration-Tests are running, because all are disabled. This makes quality assurance quite difficult. Also, the fact that the changes broke the C and the Go versions is “sub-ideal”. We’ll try to fix the problems, but I guess it’s going to consume a lot of time to do so. But in the future ... if you change mspecs for drivers, you might break things in other languages, so It’s super important to ensure stuff is working in all languages. Also please don’t comment out tests ... I know I found a place where I did so too and I promise to not do it again. We really have to pay a bit more attention on not reducing more and more of our tests. Chris
Please don't merge mspec changes if you haven't built with all languages enabled
Hi all, we’re currently trying to get the S7 driver back working ... even if it seems as if it is working (When running the ManualS7Test) ... None of the Integration-Tests are running, because all are disabled. This makes quality assurance quite difficult. Also, the fact that the changes broke the C and the Go versions is “sub-ideal”. We’ll try to fix the problems, but I guess it’s going to consume a lot of time to do so. But in the future ... if you change mspecs for drivers, you might break things in other languages, so It’s super important to ensure stuff is working in all languages. Also please don’t comment out tests ... I know I found a place where I did so too and I promise to not do it again. We really have to pay a bit more attention on not reducing more and more of our tests. Chris
