Today, I saw the below -1 by Thomas, https://github.com/apache/apex-malhar/pull/666 without the technical justification.
Saumya, PR Author, has created a mail thread to discuss the justification, but there was no comment in the mail thread. So should we consider this as invalid -1? On Thu, Aug 24, 2017 at 10:08 AM Vlad Rozov <vro...@apache.org> wrote: > For -1 to be valid there *must* be *technical* justification(s) not to > proceed with the code change. Without such justification -1 is > considered to be void/invalid [1]. > > I don't see any possible *technical* justification not to proceed with > the package rename as it was done in the past by a large number of > Apache (and not only Apache) projects and nothing bad happened (no > performance degradation, no introduction of security vulnerability) and > projects remained usable by their users. With the current IDEs, it is a > question of 5 minutes to complete necessary modifications. > > Both Apache Felix and Apache Groovy (as well as Apache Apex) are split > package projects. There is mix and match of org.apache.* and other > package names (org.osgi, groovy, com.datatorrent). IMO, this is a bad > practice and I don't think that Apex community should use those projects > as a best practice examples. Majority of Apache projects consistently > use org.apache package and IMO that simplifies user and community > experience. > > Majority of malhar library classes are excluded from semantic versioning > check and are not subject of backward compatibility/stable API > guarantee. Due to that there never be a good reason to change major > version as backward incompatible changes are introduced silently and > without proper semantic versioning. > > Thank you, > > Vlad > > [1] https://www.apache.org/foundation/voting.html > > On 8/23/17 15:17, Sergey Golovko wrote: > > -1 for the option 2 > > > > I don't think it makes sense to rush to rename the package name. There > are > > Apache Java projects that use the original package names after migration > to > > Apache Software Foundation. For instance, > > > > Apache Felix <https://projects.apache.org/project.html?felix> (org.osgi) > > Apache Groovy <https://projects.apache.org/project.html?groovy> (groovy) > > > > Personally I don't like the idea to rename package names for any existing > > tools and applications. It can just be a big confusion for users without > > any real benefits. > > > > -1 for the option 1 > > > > I see only one valid reason to change the major version now. It is the > full > > refactoring of the code without supporting of any backward compatibility. > > If we are going to make the package refactoring we need to change the > major > > version. If we are not going to do it now, it does not make sense to > > change the major version. I don't think it makes sense to vote for the > two > > options separately. > > > > Thanks, > > Sergey > > > > > > On Wed, Aug 23, 2017 at 6:39 AM, Thomas Weise <t...@apache.org> wrote: > > > >> So far everyone else has voted +1 on option 1. Your -1 is not a veto > >> (unlike your previous -1 on a pull request), but your response also > states > >> "I am for option 1" and that you want to have the branch release-3 > >> included. So why don't you include that into your vote for option 1 as a > >> condition, since that's what is going to happen anyways. > >> > >> Thomas > >> > >> > >> On Tue, Aug 22, 2017 at 6:17 PM, Amol Kekre <a...@datatorrent.com> > wrote: > >> > >>> On just voting part, I remain -1 on both options > >>> > >>> Thks > >>> Amol > >>> > >>> > >>> > >> On Tue, Aug 22, 2017 at 10:03 AM, Amol Kekre <a...@datatorrent.com> > wrote: > >> > >>> I am -1 on option 2. There is no need to do so, as going back on > versions > >>> at this stage has consequences to Apex users. > >>> > >>> I am for option 1, but I want to propose explicit change to the text. > >> Based > >>> on verbatim text, I am voting -1 on option 1. I believe in the original > >>> discussion thread there was talk about continuing release-3 that should > >> be > >>> explicit in the vote. > >>> > >>> > > > Thank you, > > Vlad >
