You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Joe Witt <jo...@gmail.com> on 2014/11/27 16:05:58 UTC
Establish [draft] project bylaws, release guide
Folks,
Would like to establish and follow very early on the bylaws under which we
will operate. Projects such as Accumulo, CloudStack, Pig, and Kafka have
very similar bylaws with minor differences:
[References]
https://accumulo.apache.org/bylaws.html
http://hadoop.apache.org/bylaws.html
https://cwiki.apache.org/confluence/display/KAFKA/Bylaws
http://cloudstack.apache.org/bylaws.html
http://pig.apache.org/bylaws.html
[My opinion]
I think we should adopt Accumulo's bylaws almost directly. What I would
suggest we remove is the custom to have committers invited to the PMC. I
think the staged progression to the PMC is important.
Recommend we also do the same for a release guide. Again Accumulo offers a
very good example:
https://accumulo.apache.org/governance/releasing.html
And finally we should clearly define a few terms:
API:
We should clearly call out what is the public API and the internal API.
Changes to the public API are very sensitive in nature as they can disturb
the user base. Changes to the private/internal API however are important
to allow internal implementation to evolve.
Versioning Scheme:
x.y.z Where X = Massive? Y = Major Z = Minor
Look forward to any thoughts. None of this needs to be solidified at this
very early stage for our project. But it is important to establish
something as a basis of further discussion and iteration.
Happy Thanksgiving.
Joe
Re: Establish [draft] project bylaws, release guide
Posted by Joe Witt <jo...@gmail.com>.
Regarding versioning:
To Adam's point and Mark's concession consistency in approach is the key
here. I am strongly in favor of purely adopting the letter of the law for
semantic versions 2.0.0. Why? It is documented and consistent with the
spirit of our intent to date. We just need to be disciplined. This gives
us a guide for folks to follow. "Patch" is totally fine as a replacement
for "Incremental". The phrasing of incremental only existed because that
is what it was called in Maven quite honestly.
I do agree that in component X if you change dependency Y that the change
doesn't necessarily mean the same version component (major/minor/patch)
must change in X as it did in Y. It totally depends on the situation. As
long as the consistent approach is semver2.0 then we should be ok.
Regarding public/private:
The most important point here are points of designed extension and points
of inter-process communication. Those are the boundaries at which we must
be extremely honorable in not breaking things. For everything else...if
folks are tinkering then they're going off the charted safe paths and while
that should not be discouraged or prevented they should also know they
might run into a tree.
Thanks
Joe
On Fri, Nov 28, 2014 at 2:44 PM, Mark Payne <ma...@hotmail.com> wrote:
> Personally, I don't like the Major.Minor.Patch as well as
> Major.Minor.Incremental, because often the changes are not patches. For
> example, if we modify a Processor to now add a new attribute to outbound
> FlowFiles, it's not really a patch - it's a new minor/incremental feature.
> But I don't feel particularly strong about this issue so if others prefer
> 'patch' over 'incremental' it's fine.
> Regarding rollup versioning: I think the version change shouldn't depend
> on dependency version changes. For example, if libfoo moves from 1.2.0 to
> 2.0.0, then nifi-module-1.0.0 could go to nifi-module-2.0.0 or
> nifi-module-1.1.0 or 1.0.1, depending on the change. So if libfoo were the
> Expression Language and that was rewritten for performance reasons so that
> the api is completely different but the DSL remains unchanged, that would
> be nifi-module-1.1.0 (minor increment because a presumably significant
> feature of performance improvement). If the DSL changed, though, and this
> affects end users, this is a nifi-module-2.0.0 and maybe this can't be
> released until the next major release of NiFi. Along the same lines, if
> it's a new underlying API just because the old API was confusing, maybe
> it's nifi-module-1.0.1.
> re: public/private API, my take on this topic is this:
> FlowFile, for instance, is a private API because only the framework should
> instantiate it. Therefore, we can add methods to it and increment minor
> version. Removal of a method or changing a method signature would require a
> Major release. However, Processor is an interface and is part of the
> public API because extensions extend/implement it. As a result, adding a
> new method breaks backward compatibility and cannot be done without a major
> release. Also, AbstractProcessor is also extended but since it is not an
> interface, we can add a method as long as it is not abstract.
> If this is what we want to go with, I recommend we create two annotations
> in the API module: @PublicAPI and @PrivateAPI (or simply @Public and
> @Private) that we would add to the different interfaces/classes so that it
> is very clear what can and cannot be changed for a minor/incremental/patch
> release.
>
> > Date: Fri, 28 Nov 2014 13:00:54 -0500
> > Subject: Re: Establish [draft] project bylaws, release guide
> > From: adam@adamtaft.com
> > To: dev@nifi.incubator.apache.org
> >
> > Yes, semver.org is awesome. Cheers for the reference. We should
> > definitely stick with their literal terms: MAJOR, MINOR, PATCH.
> >
> > Just to add to the discussion... When we apply version numbers to our
> the
> > underlying libraries, traditional versioning makes a lot of sense.
> Seeing
> > libfoo go from foo-1.2.3 to 1.3.0 when a new minor feature is added makes
> > sense and is intuitive.
> >
> > Our problem for versioning is not the underlying libraries, it's the
> rollup
> > versioning for all of the modules and components that build into a final
> > release. It's not uncommon to have a major change in a module dependency
> > not necessarily reflected in the final release numbering.
> >
> > As an example, to complicate things, given:
> > nifi-module-1.0.0
> > foo-1.2.3 (module dependency)
> > bar-2.4.0 (module dependency)
> > baz-0.2.8 (module dependency)
> >
> > What is the appropriate version number for nifi-module when foo goes to
> > foo-2.0.0? How about if two deps go to bar-2.4.1 and baz-0.3.0 at the
> same
> > time? nifi-module doesn't have an "API" in the traditional sense; it's
> > just a container for the underlying dependencies.
> >
> > Our answer, to date, is all over the board. Sometimes we only bump the
> > patch version number, other times we bump the minor. Rarely do we bump
> the
> > major, even if underlying dependency had a major change. There's no good
> > consistency (or advice) that I've seen for this situation.
> >
> > This is the same problem that Linux distributors have. The GNU libc, for
> > example, has gone through many changes over the years -- some back
> > breaking, others only minor. Does Redhat, for example, base their
> > versioning numbers on the underlying libc? What about the Linux kernel?
> > What if something else in Redhat changes, like Apache httpd, or a
> > filesystem, etc.
> >
> > I'm not offering any solutions, just bringing up the point. The "public"
> > API for NiFi is difficult to define. Is this the core framework api?
> > standard services api? framework nar? standard nar? user interface?
> > configuration schema? Combination of all the above?
> >
> > It might be better to consider a versioning scheme for the higher level
> > releases and modules reflect the fact there's no good way to "rollup"
> > dependency changes. Linux distros, for example, tend to use regular
> > calendar (quarterly) or "cover term" based names for their higher level
> > release products. Maybe that's a reasonable approach.
> >
> > Adam
> >
> > p.s. per Tony's comment, note this is why Accummulo has a "marketing"
> > version number. In many ways, our major version number for higher level
> > releases is as much for marketing purposes as for actual API
> > compatibilities. We tout the current release more for its speed and user
> > interface than the underlying API changes that affect a developer.
> >
> >
> > On Fri, Nov 28, 2014 at 3:56 AM, Sergio Fernández <wi...@apache.org>
> wrote:
> >
> > > exactly, just follow the semantic versioning schema: http://semver.org
> > >
> > > On 28/11/14 03:28, Tony Kurc wrote:
> > >
> > >> Joe,
> > >> You use "the API" in the Major and Minor definitions, then break down
> > >> public and private in the commentary. Is "the API" both public and
> > >> private?
> > >> I interpreted your definitions as "Between minor revisions, both
> public
> > >> APIs and private will be expected to be backwards compatible"? For a
> major
> > >> release, both are up for change, and I inferred "but changes to public
> > >> APIs
> > >> are scrutinized more".
> > >>
> > >> Tony
> > >>
> > >>
> > >> On Thu, Nov 27, 2014 at 8:50 PM, Joe Witt <jo...@gmail.com> wrote:
> > >>
> > >> I propose the following rather typical/conventional version scheme
> for
> > >>> our
> > >>> artifacts:
> > >>>
> > >>> [Major].[Minor].[Incremental]
> > >>>
> > >>> Definitions:
> > >>>
> > >>> 'Major' releases are reserved for changes that alter the API in
> > >>> non-backward compatible ways or changes in function of the
> application or
> > >>> components which could break existing configured data flows.
> > >>>
> > >>> 'Minor' releases are reserved for the addition of significant new
> > >>> features
> > >>> or backward compatible changes of the API.
> > >>>
> > >>> 'Incremental' releases are reserved for bug fixes, documentation
> changes,
> > >>> the inclusion of features or enhancements to existing features which
> are
> > >>> deemed routine.
> > >>>
> > >>> Commentary:
> > >>>
> > >>> These definitions are imprecise (significant/routine) but perhaps
> > >>> sufficient at this early stage. We must also be clear about what we
> > >>> mean
> > >>> by API. We should as mentioned previously clearly articulate that
> which
> > >>> the public API and which we will defend aggressively on behalf of the
> > >>> users
> > >>> versus the 'private API' which we should be free to adjust
> internally as
> > >>> needed. We also have to consider that our API is more than the
> > >>> traditionally considered 'code API' and also includes the web-based
> > >>> interface to command and control the application. Developers
> building
> > >>> extensions should feel confident that their developed capabilities
> will
> > >>> work forever within a given major release.
> > >>>
> > >>> Thanks
> > >>> Joe
> > >>>
> > >>>
> > >>> On Thu, Nov 27, 2014 at 8:25 PM, Mark Payne <ma...@hotmail.com>
> > >>> wrote:
> > >>>
> > >>> I like the major, minor, incremental terminology. But I think we
> need to
> > >>>> provide clear guidance on what qualifies as major and minor. I think
> > >>>> this
> > >>>> is much more important than the terminology.
> > >>>>
> > >>>> Sent from my iPhone
> > >>>>
> > >>>> On Nov 27, 2014, at 8:21 PM, Joe Witt <jo...@gmail.com> wrote:
> > >>>>>
> > >>>>> I feel like 'major, minor, incremental' is sufficient for our
> purposes.
> > >>>>>
> > >>>> No?
> > >>>>
> > >>>>>
> > >>>>> On Thu, Nov 27, 2014 at 3:53 PM, Tony Kurc <tr...@gmail.com>
> wrote:
> > >>>>>>
> > >>>>>> I think the ? is "marketing"
> > >>>>>>
> > >>>>>> On Thu, Nov 27, 2014 at 1:16 PM, Joe Witt <jo...@gmail.com>
> > >>>>>>>
> > >>>>>> wrote:
> > >>>
> > >>>>
> > >>>>>>> on the versioning scheme i should clarify that the
> > >>>>>>>
> > >>>>>>> x.y.z where X= ? , Y = Major, Z = Minor is based on what accumulo
> > >>>>>>>
> > >>>>>> appears
> > >>>>
> > >>>>> to do. I am personally more familiar with
> > >>>>>>>
> > >>>>>>> x.y.z where X = Major, Y = Minor, Z = incremental
> > >>>>>>>
> > >>>>>>> On Thu, Nov 27, 2014 at 10:05 AM, Joe Witt <jo...@gmail.com>
> > >>>>>>>>
> > >>>>>>> wrote:
> > >>>>
> > >>>>>
> > >>>>>>>> Folks,
> > >>>>>>>>
> > >>>>>>>> Would like to establish and follow very early on the bylaws
> under
> > >>>>>>>>
> > >>>>>>> which
> > >>>>
> > >>>>> we
> > >>>>>>>
> > >>>>>>>> will operate. Projects such as Accumulo, CloudStack, Pig, and
> Kafka
> > >>>>>>>>
> > >>>>>>> have
> > >>>>>>
> > >>>>>>> very similar bylaws with minor differences:
> > >>>>>>>>
> > >>>>>>>> [References]
> > >>>>>>>> https://accumulo.apache.org/bylaws.html
> > >>>>>>>> http://hadoop.apache.org/bylaws.html
> > >>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/Bylaws
> > >>>>>>>> http://cloudstack.apache.org/bylaws.html
> > >>>>>>>> http://pig.apache.org/bylaws.html
> > >>>>>>>>
> > >>>>>>>> [My opinion]
> > >>>>>>>> I think we should adopt Accumulo's bylaws almost directly.
> What I
> > >>>>>>>>
> > >>>>>>> would
> > >>>>>>
> > >>>>>>> suggest we remove is the custom to have committers invited to the
> > >>>>>>>>
> > >>>>>>> PMC. I
> > >>>>>>
> > >>>>>>> think the staged progression to the PMC is important.
> > >>>>>>>>
> > >>>>>>>> Recommend we also do the same for a release guide. Again
> Accumulo
> > >>>>>>>>
> > >>>>>>> offers
> > >>>>>>
> > >>>>>>> a very good example:
> > >>>>>>>>
> > >>>>>>>> https://accumulo.apache.org/governance/releasing.html
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> And finally we should clearly define a few terms:
> > >>>>>>>>
> > >>>>>>>> API:
> > >>>>>>>>
> > >>>>>>>> We should clearly call out what is the public API and the
> internal
> > >>>>>>>>
> > >>>>>>> API.
> > >>>>
> > >>>>> Changes to the public API are very sensitive in nature as they can
> > >>>>>>>>
> > >>>>>>> disturb
> > >>>>>>>
> > >>>>>>>> the user base. Changes to the private/internal API however are
> > >>>>>>>>
> > >>>>>>> important
> > >>>>>>
> > >>>>>>> to allow internal implementation to evolve.
> > >>>>>>>>
> > >>>>>>>> Versioning Scheme:
> > >>>>>>>>
> > >>>>>>>> x.y.z Where X = Massive? Y = Major Z = Minor
> > >>>>>>>>
> > >>>>>>>> Look forward to any thoughts. None of this needs to be
> solidified
> > >>>>>>>>
> > >>>>>>> at
> > >>>
> > >>>> this
> > >>>>>>>
> > >>>>>>>> very early stage for our project. But it is important to
> establish
> > >>>>>>>> something as a basis of further discussion and iteration.
> > >>>>>>>>
> > >>>>>>>> Happy Thanksgiving.
> > >>>>>>>>
> > >>>>>>>> Joe
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>
> > >>>
> > >>
> > > --
> > > Sergio Fernández
> > > Partner Technology Manager
> > > Redlink GmbH
> > > m: +43 660 2747 925
> > > e: sergio.fernandez@redlink.co
> > > w: http://redlink.co
> > >
>
>
RE: Establish [draft] project bylaws, release guide
Posted by Mark Payne <ma...@hotmail.com>.
Personally, I don't like the Major.Minor.Patch as well as Major.Minor.Incremental, because often the changes are not patches. For example, if we modify a Processor to now add a new attribute to outbound FlowFiles, it's not really a patch - it's a new minor/incremental feature. But I don't feel particularly strong about this issue so if others prefer 'patch' over 'incremental' it's fine.
Regarding rollup versioning: I think the version change shouldn't depend on dependency version changes. For example, if libfoo moves from 1.2.0 to 2.0.0, then nifi-module-1.0.0 could go to nifi-module-2.0.0 or nifi-module-1.1.0 or 1.0.1, depending on the change. So if libfoo were the Expression Language and that was rewritten for performance reasons so that the api is completely different but the DSL remains unchanged, that would be nifi-module-1.1.0 (minor increment because a presumably significant feature of performance improvement). If the DSL changed, though, and this affects end users, this is a nifi-module-2.0.0 and maybe this can't be released until the next major release of NiFi. Along the same lines, if it's a new underlying API just because the old API was confusing, maybe it's nifi-module-1.0.1.
re: public/private API, my take on this topic is this:
FlowFile, for instance, is a private API because only the framework should instantiate it. Therefore, we can add methods to it and increment minor version. Removal of a method or changing a method signature would require a Major release. However, Processor is an interface and is part of the public API because extensions extend/implement it. As a result, adding a new method breaks backward compatibility and cannot be done without a major release. Also, AbstractProcessor is also extended but since it is not an interface, we can add a method as long as it is not abstract.
If this is what we want to go with, I recommend we create two annotations in the API module: @PublicAPI and @PrivateAPI (or simply @Public and @Private) that we would add to the different interfaces/classes so that it is very clear what can and cannot be changed for a minor/incremental/patch release.
> Date: Fri, 28 Nov 2014 13:00:54 -0500
> Subject: Re: Establish [draft] project bylaws, release guide
> From: adam@adamtaft.com
> To: dev@nifi.incubator.apache.org
>
> Yes, semver.org is awesome. Cheers for the reference. We should
> definitely stick with their literal terms: MAJOR, MINOR, PATCH.
>
> Just to add to the discussion... When we apply version numbers to our the
> underlying libraries, traditional versioning makes a lot of sense. Seeing
> libfoo go from foo-1.2.3 to 1.3.0 when a new minor feature is added makes
> sense and is intuitive.
>
> Our problem for versioning is not the underlying libraries, it's the rollup
> versioning for all of the modules and components that build into a final
> release. It's not uncommon to have a major change in a module dependency
> not necessarily reflected in the final release numbering.
>
> As an example, to complicate things, given:
> nifi-module-1.0.0
> foo-1.2.3 (module dependency)
> bar-2.4.0 (module dependency)
> baz-0.2.8 (module dependency)
>
> What is the appropriate version number for nifi-module when foo goes to
> foo-2.0.0? How about if two deps go to bar-2.4.1 and baz-0.3.0 at the same
> time? nifi-module doesn't have an "API" in the traditional sense; it's
> just a container for the underlying dependencies.
>
> Our answer, to date, is all over the board. Sometimes we only bump the
> patch version number, other times we bump the minor. Rarely do we bump the
> major, even if underlying dependency had a major change. There's no good
> consistency (or advice) that I've seen for this situation.
>
> This is the same problem that Linux distributors have. The GNU libc, for
> example, has gone through many changes over the years -- some back
> breaking, others only minor. Does Redhat, for example, base their
> versioning numbers on the underlying libc? What about the Linux kernel?
> What if something else in Redhat changes, like Apache httpd, or a
> filesystem, etc.
>
> I'm not offering any solutions, just bringing up the point. The "public"
> API for NiFi is difficult to define. Is this the core framework api?
> standard services api? framework nar? standard nar? user interface?
> configuration schema? Combination of all the above?
>
> It might be better to consider a versioning scheme for the higher level
> releases and modules reflect the fact there's no good way to "rollup"
> dependency changes. Linux distros, for example, tend to use regular
> calendar (quarterly) or "cover term" based names for their higher level
> release products. Maybe that's a reasonable approach.
>
> Adam
>
> p.s. per Tony's comment, note this is why Accummulo has a "marketing"
> version number. In many ways, our major version number for higher level
> releases is as much for marketing purposes as for actual API
> compatibilities. We tout the current release more for its speed and user
> interface than the underlying API changes that affect a developer.
>
>
> On Fri, Nov 28, 2014 at 3:56 AM, Sergio Fernández <wi...@apache.org> wrote:
>
> > exactly, just follow the semantic versioning schema: http://semver.org
> >
> > On 28/11/14 03:28, Tony Kurc wrote:
> >
> >> Joe,
> >> You use "the API" in the Major and Minor definitions, then break down
> >> public and private in the commentary. Is "the API" both public and
> >> private?
> >> I interpreted your definitions as "Between minor revisions, both public
> >> APIs and private will be expected to be backwards compatible"? For a major
> >> release, both are up for change, and I inferred "but changes to public
> >> APIs
> >> are scrutinized more".
> >>
> >> Tony
> >>
> >>
> >> On Thu, Nov 27, 2014 at 8:50 PM, Joe Witt <jo...@gmail.com> wrote:
> >>
> >> I propose the following rather typical/conventional version scheme for
> >>> our
> >>> artifacts:
> >>>
> >>> [Major].[Minor].[Incremental]
> >>>
> >>> Definitions:
> >>>
> >>> 'Major' releases are reserved for changes that alter the API in
> >>> non-backward compatible ways or changes in function of the application or
> >>> components which could break existing configured data flows.
> >>>
> >>> 'Minor' releases are reserved for the addition of significant new
> >>> features
> >>> or backward compatible changes of the API.
> >>>
> >>> 'Incremental' releases are reserved for bug fixes, documentation changes,
> >>> the inclusion of features or enhancements to existing features which are
> >>> deemed routine.
> >>>
> >>> Commentary:
> >>>
> >>> These definitions are imprecise (significant/routine) but perhaps
> >>> sufficient at this early stage. We must also be clear about what we
> >>> mean
> >>> by API. We should as mentioned previously clearly articulate that which
> >>> the public API and which we will defend aggressively on behalf of the
> >>> users
> >>> versus the 'private API' which we should be free to adjust internally as
> >>> needed. We also have to consider that our API is more than the
> >>> traditionally considered 'code API' and also includes the web-based
> >>> interface to command and control the application. Developers building
> >>> extensions should feel confident that their developed capabilities will
> >>> work forever within a given major release.
> >>>
> >>> Thanks
> >>> Joe
> >>>
> >>>
> >>> On Thu, Nov 27, 2014 at 8:25 PM, Mark Payne <ma...@hotmail.com>
> >>> wrote:
> >>>
> >>> I like the major, minor, incremental terminology. But I think we need to
> >>>> provide clear guidance on what qualifies as major and minor. I think
> >>>> this
> >>>> is much more important than the terminology.
> >>>>
> >>>> Sent from my iPhone
> >>>>
> >>>> On Nov 27, 2014, at 8:21 PM, Joe Witt <jo...@gmail.com> wrote:
> >>>>>
> >>>>> I feel like 'major, minor, incremental' is sufficient for our purposes.
> >>>>>
> >>>> No?
> >>>>
> >>>>>
> >>>>> On Thu, Nov 27, 2014 at 3:53 PM, Tony Kurc <tr...@gmail.com> wrote:
> >>>>>>
> >>>>>> I think the ? is "marketing"
> >>>>>>
> >>>>>> On Thu, Nov 27, 2014 at 1:16 PM, Joe Witt <jo...@gmail.com>
> >>>>>>>
> >>>>>> wrote:
> >>>
> >>>>
> >>>>>>> on the versioning scheme i should clarify that the
> >>>>>>>
> >>>>>>> x.y.z where X= ? , Y = Major, Z = Minor is based on what accumulo
> >>>>>>>
> >>>>>> appears
> >>>>
> >>>>> to do. I am personally more familiar with
> >>>>>>>
> >>>>>>> x.y.z where X = Major, Y = Minor, Z = incremental
> >>>>>>>
> >>>>>>> On Thu, Nov 27, 2014 at 10:05 AM, Joe Witt <jo...@gmail.com>
> >>>>>>>>
> >>>>>>> wrote:
> >>>>
> >>>>>
> >>>>>>>> Folks,
> >>>>>>>>
> >>>>>>>> Would like to establish and follow very early on the bylaws under
> >>>>>>>>
> >>>>>>> which
> >>>>
> >>>>> we
> >>>>>>>
> >>>>>>>> will operate. Projects such as Accumulo, CloudStack, Pig, and Kafka
> >>>>>>>>
> >>>>>>> have
> >>>>>>
> >>>>>>> very similar bylaws with minor differences:
> >>>>>>>>
> >>>>>>>> [References]
> >>>>>>>> https://accumulo.apache.org/bylaws.html
> >>>>>>>> http://hadoop.apache.org/bylaws.html
> >>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/Bylaws
> >>>>>>>> http://cloudstack.apache.org/bylaws.html
> >>>>>>>> http://pig.apache.org/bylaws.html
> >>>>>>>>
> >>>>>>>> [My opinion]
> >>>>>>>> I think we should adopt Accumulo's bylaws almost directly. What I
> >>>>>>>>
> >>>>>>> would
> >>>>>>
> >>>>>>> suggest we remove is the custom to have committers invited to the
> >>>>>>>>
> >>>>>>> PMC. I
> >>>>>>
> >>>>>>> think the staged progression to the PMC is important.
> >>>>>>>>
> >>>>>>>> Recommend we also do the same for a release guide. Again Accumulo
> >>>>>>>>
> >>>>>>> offers
> >>>>>>
> >>>>>>> a very good example:
> >>>>>>>>
> >>>>>>>> https://accumulo.apache.org/governance/releasing.html
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> And finally we should clearly define a few terms:
> >>>>>>>>
> >>>>>>>> API:
> >>>>>>>>
> >>>>>>>> We should clearly call out what is the public API and the internal
> >>>>>>>>
> >>>>>>> API.
> >>>>
> >>>>> Changes to the public API are very sensitive in nature as they can
> >>>>>>>>
> >>>>>>> disturb
> >>>>>>>
> >>>>>>>> the user base. Changes to the private/internal API however are
> >>>>>>>>
> >>>>>>> important
> >>>>>>
> >>>>>>> to allow internal implementation to evolve.
> >>>>>>>>
> >>>>>>>> Versioning Scheme:
> >>>>>>>>
> >>>>>>>> x.y.z Where X = Massive? Y = Major Z = Minor
> >>>>>>>>
> >>>>>>>> Look forward to any thoughts. None of this needs to be solidified
> >>>>>>>>
> >>>>>>> at
> >>>
> >>>> this
> >>>>>>>
> >>>>>>>> very early stage for our project. But it is important to establish
> >>>>>>>> something as a basis of further discussion and iteration.
> >>>>>>>>
> >>>>>>>> Happy Thanksgiving.
> >>>>>>>>
> >>>>>>>> Joe
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>
> >>
> > --
> > Sergio Fernández
> > Partner Technology Manager
> > Redlink GmbH
> > m: +43 660 2747 925
> > e: sergio.fernandez@redlink.co
> > w: http://redlink.co
> >
Re: Establish [draft] project bylaws, release guide
Posted by Adam Taft <ad...@adamtaft.com>.
Yes, semver.org is awesome. Cheers for the reference. We should
definitely stick with their literal terms: MAJOR, MINOR, PATCH.
Just to add to the discussion... When we apply version numbers to our the
underlying libraries, traditional versioning makes a lot of sense. Seeing
libfoo go from foo-1.2.3 to 1.3.0 when a new minor feature is added makes
sense and is intuitive.
Our problem for versioning is not the underlying libraries, it's the rollup
versioning for all of the modules and components that build into a final
release. It's not uncommon to have a major change in a module dependency
not necessarily reflected in the final release numbering.
As an example, to complicate things, given:
nifi-module-1.0.0
foo-1.2.3 (module dependency)
bar-2.4.0 (module dependency)
baz-0.2.8 (module dependency)
What is the appropriate version number for nifi-module when foo goes to
foo-2.0.0? How about if two deps go to bar-2.4.1 and baz-0.3.0 at the same
time? nifi-module doesn't have an "API" in the traditional sense; it's
just a container for the underlying dependencies.
Our answer, to date, is all over the board. Sometimes we only bump the
patch version number, other times we bump the minor. Rarely do we bump the
major, even if underlying dependency had a major change. There's no good
consistency (or advice) that I've seen for this situation.
This is the same problem that Linux distributors have. The GNU libc, for
example, has gone through many changes over the years -- some back
breaking, others only minor. Does Redhat, for example, base their
versioning numbers on the underlying libc? What about the Linux kernel?
What if something else in Redhat changes, like Apache httpd, or a
filesystem, etc.
I'm not offering any solutions, just bringing up the point. The "public"
API for NiFi is difficult to define. Is this the core framework api?
standard services api? framework nar? standard nar? user interface?
configuration schema? Combination of all the above?
It might be better to consider a versioning scheme for the higher level
releases and modules reflect the fact there's no good way to "rollup"
dependency changes. Linux distros, for example, tend to use regular
calendar (quarterly) or "cover term" based names for their higher level
release products. Maybe that's a reasonable approach.
Adam
p.s. per Tony's comment, note this is why Accummulo has a "marketing"
version number. In many ways, our major version number for higher level
releases is as much for marketing purposes as for actual API
compatibilities. We tout the current release more for its speed and user
interface than the underlying API changes that affect a developer.
On Fri, Nov 28, 2014 at 3:56 AM, Sergio Fernández <wi...@apache.org> wrote:
> exactly, just follow the semantic versioning schema: http://semver.org
>
> On 28/11/14 03:28, Tony Kurc wrote:
>
>> Joe,
>> You use "the API" in the Major and Minor definitions, then break down
>> public and private in the commentary. Is "the API" both public and
>> private?
>> I interpreted your definitions as "Between minor revisions, both public
>> APIs and private will be expected to be backwards compatible"? For a major
>> release, both are up for change, and I inferred "but changes to public
>> APIs
>> are scrutinized more".
>>
>> Tony
>>
>>
>> On Thu, Nov 27, 2014 at 8:50 PM, Joe Witt <jo...@gmail.com> wrote:
>>
>> I propose the following rather typical/conventional version scheme for
>>> our
>>> artifacts:
>>>
>>> [Major].[Minor].[Incremental]
>>>
>>> Definitions:
>>>
>>> 'Major' releases are reserved for changes that alter the API in
>>> non-backward compatible ways or changes in function of the application or
>>> components which could break existing configured data flows.
>>>
>>> 'Minor' releases are reserved for the addition of significant new
>>> features
>>> or backward compatible changes of the API.
>>>
>>> 'Incremental' releases are reserved for bug fixes, documentation changes,
>>> the inclusion of features or enhancements to existing features which are
>>> deemed routine.
>>>
>>> Commentary:
>>>
>>> These definitions are imprecise (significant/routine) but perhaps
>>> sufficient at this early stage. We must also be clear about what we
>>> mean
>>> by API. We should as mentioned previously clearly articulate that which
>>> the public API and which we will defend aggressively on behalf of the
>>> users
>>> versus the 'private API' which we should be free to adjust internally as
>>> needed. We also have to consider that our API is more than the
>>> traditionally considered 'code API' and also includes the web-based
>>> interface to command and control the application. Developers building
>>> extensions should feel confident that their developed capabilities will
>>> work forever within a given major release.
>>>
>>> Thanks
>>> Joe
>>>
>>>
>>> On Thu, Nov 27, 2014 at 8:25 PM, Mark Payne <ma...@hotmail.com>
>>> wrote:
>>>
>>> I like the major, minor, incremental terminology. But I think we need to
>>>> provide clear guidance on what qualifies as major and minor. I think
>>>> this
>>>> is much more important than the terminology.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Nov 27, 2014, at 8:21 PM, Joe Witt <jo...@gmail.com> wrote:
>>>>>
>>>>> I feel like 'major, minor, incremental' is sufficient for our purposes.
>>>>>
>>>> No?
>>>>
>>>>>
>>>>> On Thu, Nov 27, 2014 at 3:53 PM, Tony Kurc <tr...@gmail.com> wrote:
>>>>>>
>>>>>> I think the ? is "marketing"
>>>>>>
>>>>>> On Thu, Nov 27, 2014 at 1:16 PM, Joe Witt <jo...@gmail.com>
>>>>>>>
>>>>>> wrote:
>>>
>>>>
>>>>>>> on the versioning scheme i should clarify that the
>>>>>>>
>>>>>>> x.y.z where X= ? , Y = Major, Z = Minor is based on what accumulo
>>>>>>>
>>>>>> appears
>>>>
>>>>> to do. I am personally more familiar with
>>>>>>>
>>>>>>> x.y.z where X = Major, Y = Minor, Z = incremental
>>>>>>>
>>>>>>> On Thu, Nov 27, 2014 at 10:05 AM, Joe Witt <jo...@gmail.com>
>>>>>>>>
>>>>>>> wrote:
>>>>
>>>>>
>>>>>>>> Folks,
>>>>>>>>
>>>>>>>> Would like to establish and follow very early on the bylaws under
>>>>>>>>
>>>>>>> which
>>>>
>>>>> we
>>>>>>>
>>>>>>>> will operate. Projects such as Accumulo, CloudStack, Pig, and Kafka
>>>>>>>>
>>>>>>> have
>>>>>>
>>>>>>> very similar bylaws with minor differences:
>>>>>>>>
>>>>>>>> [References]
>>>>>>>> https://accumulo.apache.org/bylaws.html
>>>>>>>> http://hadoop.apache.org/bylaws.html
>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/Bylaws
>>>>>>>> http://cloudstack.apache.org/bylaws.html
>>>>>>>> http://pig.apache.org/bylaws.html
>>>>>>>>
>>>>>>>> [My opinion]
>>>>>>>> I think we should adopt Accumulo's bylaws almost directly. What I
>>>>>>>>
>>>>>>> would
>>>>>>
>>>>>>> suggest we remove is the custom to have committers invited to the
>>>>>>>>
>>>>>>> PMC. I
>>>>>>
>>>>>>> think the staged progression to the PMC is important.
>>>>>>>>
>>>>>>>> Recommend we also do the same for a release guide. Again Accumulo
>>>>>>>>
>>>>>>> offers
>>>>>>
>>>>>>> a very good example:
>>>>>>>>
>>>>>>>> https://accumulo.apache.org/governance/releasing.html
>>>>>>>>
>>>>>>>>
>>>>>>>> And finally we should clearly define a few terms:
>>>>>>>>
>>>>>>>> API:
>>>>>>>>
>>>>>>>> We should clearly call out what is the public API and the internal
>>>>>>>>
>>>>>>> API.
>>>>
>>>>> Changes to the public API are very sensitive in nature as they can
>>>>>>>>
>>>>>>> disturb
>>>>>>>
>>>>>>>> the user base. Changes to the private/internal API however are
>>>>>>>>
>>>>>>> important
>>>>>>
>>>>>>> to allow internal implementation to evolve.
>>>>>>>>
>>>>>>>> Versioning Scheme:
>>>>>>>>
>>>>>>>> x.y.z Where X = Massive? Y = Major Z = Minor
>>>>>>>>
>>>>>>>> Look forward to any thoughts. None of this needs to be solidified
>>>>>>>>
>>>>>>> at
>>>
>>>> this
>>>>>>>
>>>>>>>> very early stage for our project. But it is important to establish
>>>>>>>> something as a basis of further discussion and iteration.
>>>>>>>>
>>>>>>>> Happy Thanksgiving.
>>>>>>>>
>>>>>>>> Joe
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 660 2747 925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co
>
Re: Establish [draft] project bylaws, release guide
Posted by Sergio Fernández <wi...@apache.org>.
exactly, just follow the semantic versioning schema: http://semver.org
On 28/11/14 03:28, Tony Kurc wrote:
> Joe,
> You use "the API" in the Major and Minor definitions, then break down
> public and private in the commentary. Is "the API" both public and private?
> I interpreted your definitions as "Between minor revisions, both public
> APIs and private will be expected to be backwards compatible"? For a major
> release, both are up for change, and I inferred "but changes to public APIs
> are scrutinized more".
>
> Tony
>
>
> On Thu, Nov 27, 2014 at 8:50 PM, Joe Witt <jo...@gmail.com> wrote:
>
>> I propose the following rather typical/conventional version scheme for our
>> artifacts:
>>
>> [Major].[Minor].[Incremental]
>>
>> Definitions:
>>
>> 'Major' releases are reserved for changes that alter the API in
>> non-backward compatible ways or changes in function of the application or
>> components which could break existing configured data flows.
>>
>> 'Minor' releases are reserved for the addition of significant new features
>> or backward compatible changes of the API.
>>
>> 'Incremental' releases are reserved for bug fixes, documentation changes,
>> the inclusion of features or enhancements to existing features which are
>> deemed routine.
>>
>> Commentary:
>>
>> These definitions are imprecise (significant/routine) but perhaps
>> sufficient at this early stage. We must also be clear about what we mean
>> by API. We should as mentioned previously clearly articulate that which
>> the public API and which we will defend aggressively on behalf of the users
>> versus the 'private API' which we should be free to adjust internally as
>> needed. We also have to consider that our API is more than the
>> traditionally considered 'code API' and also includes the web-based
>> interface to command and control the application. Developers building
>> extensions should feel confident that their developed capabilities will
>> work forever within a given major release.
>>
>> Thanks
>> Joe
>>
>>
>> On Thu, Nov 27, 2014 at 8:25 PM, Mark Payne <ma...@hotmail.com> wrote:
>>
>>> I like the major, minor, incremental terminology. But I think we need to
>>> provide clear guidance on what qualifies as major and minor. I think this
>>> is much more important than the terminology.
>>>
>>> Sent from my iPhone
>>>
>>>> On Nov 27, 2014, at 8:21 PM, Joe Witt <jo...@gmail.com> wrote:
>>>>
>>>> I feel like 'major, minor, incremental' is sufficient for our purposes.
>>> No?
>>>>
>>>>> On Thu, Nov 27, 2014 at 3:53 PM, Tony Kurc <tr...@gmail.com> wrote:
>>>>>
>>>>> I think the ? is "marketing"
>>>>>
>>>>>> On Thu, Nov 27, 2014 at 1:16 PM, Joe Witt <jo...@gmail.com>
>> wrote:
>>>>>>
>>>>>> on the versioning scheme i should clarify that the
>>>>>>
>>>>>> x.y.z where X= ? , Y = Major, Z = Minor is based on what accumulo
>>> appears
>>>>>> to do. I am personally more familiar with
>>>>>>
>>>>>> x.y.z where X = Major, Y = Minor, Z = incremental
>>>>>>
>>>>>>> On Thu, Nov 27, 2014 at 10:05 AM, Joe Witt <jo...@gmail.com>
>>> wrote:
>>>>>>>
>>>>>>> Folks,
>>>>>>>
>>>>>>> Would like to establish and follow very early on the bylaws under
>>> which
>>>>>> we
>>>>>>> will operate. Projects such as Accumulo, CloudStack, Pig, and Kafka
>>>>> have
>>>>>>> very similar bylaws with minor differences:
>>>>>>>
>>>>>>> [References]
>>>>>>> https://accumulo.apache.org/bylaws.html
>>>>>>> http://hadoop.apache.org/bylaws.html
>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/Bylaws
>>>>>>> http://cloudstack.apache.org/bylaws.html
>>>>>>> http://pig.apache.org/bylaws.html
>>>>>>>
>>>>>>> [My opinion]
>>>>>>> I think we should adopt Accumulo's bylaws almost directly. What I
>>>>> would
>>>>>>> suggest we remove is the custom to have committers invited to the
>>>>> PMC. I
>>>>>>> think the staged progression to the PMC is important.
>>>>>>>
>>>>>>> Recommend we also do the same for a release guide. Again Accumulo
>>>>> offers
>>>>>>> a very good example:
>>>>>>>
>>>>>>> https://accumulo.apache.org/governance/releasing.html
>>>>>>>
>>>>>>>
>>>>>>> And finally we should clearly define a few terms:
>>>>>>>
>>>>>>> API:
>>>>>>>
>>>>>>> We should clearly call out what is the public API and the internal
>>> API.
>>>>>>> Changes to the public API are very sensitive in nature as they can
>>>>>> disturb
>>>>>>> the user base. Changes to the private/internal API however are
>>>>> important
>>>>>>> to allow internal implementation to evolve.
>>>>>>>
>>>>>>> Versioning Scheme:
>>>>>>>
>>>>>>> x.y.z Where X = Massive? Y = Major Z = Minor
>>>>>>>
>>>>>>> Look forward to any thoughts. None of this needs to be solidified
>> at
>>>>>> this
>>>>>>> very early stage for our project. But it is important to establish
>>>>>>> something as a basis of further discussion and iteration.
>>>>>>>
>>>>>>> Happy Thanksgiving.
>>>>>>>
>>>>>>> Joe
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>
--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 660 2747 925
e: sergio.fernandez@redlink.co
w: http://redlink.co
Re: Establish [draft] project bylaws, release guide
Posted by Tony Kurc <tr...@gmail.com>.
Joe,
You use "the API" in the Major and Minor definitions, then break down
public and private in the commentary. Is "the API" both public and private?
I interpreted your definitions as "Between minor revisions, both public
APIs and private will be expected to be backwards compatible"? For a major
release, both are up for change, and I inferred "but changes to public APIs
are scrutinized more".
Tony
On Thu, Nov 27, 2014 at 8:50 PM, Joe Witt <jo...@gmail.com> wrote:
> I propose the following rather typical/conventional version scheme for our
> artifacts:
>
> [Major].[Minor].[Incremental]
>
> Definitions:
>
> 'Major' releases are reserved for changes that alter the API in
> non-backward compatible ways or changes in function of the application or
> components which could break existing configured data flows.
>
> 'Minor' releases are reserved for the addition of significant new features
> or backward compatible changes of the API.
>
> 'Incremental' releases are reserved for bug fixes, documentation changes,
> the inclusion of features or enhancements to existing features which are
> deemed routine.
>
> Commentary:
>
> These definitions are imprecise (significant/routine) but perhaps
> sufficient at this early stage. We must also be clear about what we mean
> by API. We should as mentioned previously clearly articulate that which
> the public API and which we will defend aggressively on behalf of the users
> versus the 'private API' which we should be free to adjust internally as
> needed. We also have to consider that our API is more than the
> traditionally considered 'code API' and also includes the web-based
> interface to command and control the application. Developers building
> extensions should feel confident that their developed capabilities will
> work forever within a given major release.
>
> Thanks
> Joe
>
>
> On Thu, Nov 27, 2014 at 8:25 PM, Mark Payne <ma...@hotmail.com> wrote:
>
> > I like the major, minor, incremental terminology. But I think we need to
> > provide clear guidance on what qualifies as major and minor. I think this
> > is much more important than the terminology.
> >
> > Sent from my iPhone
> >
> > > On Nov 27, 2014, at 8:21 PM, Joe Witt <jo...@gmail.com> wrote:
> > >
> > > I feel like 'major, minor, incremental' is sufficient for our purposes.
> > No?
> > >
> > >> On Thu, Nov 27, 2014 at 3:53 PM, Tony Kurc <tr...@gmail.com> wrote:
> > >>
> > >> I think the ? is "marketing"
> > >>
> > >>> On Thu, Nov 27, 2014 at 1:16 PM, Joe Witt <jo...@gmail.com>
> wrote:
> > >>>
> > >>> on the versioning scheme i should clarify that the
> > >>>
> > >>> x.y.z where X= ? , Y = Major, Z = Minor is based on what accumulo
> > appears
> > >>> to do. I am personally more familiar with
> > >>>
> > >>> x.y.z where X = Major, Y = Minor, Z = incremental
> > >>>
> > >>>> On Thu, Nov 27, 2014 at 10:05 AM, Joe Witt <jo...@gmail.com>
> > wrote:
> > >>>>
> > >>>> Folks,
> > >>>>
> > >>>> Would like to establish and follow very early on the bylaws under
> > which
> > >>> we
> > >>>> will operate. Projects such as Accumulo, CloudStack, Pig, and Kafka
> > >> have
> > >>>> very similar bylaws with minor differences:
> > >>>>
> > >>>> [References]
> > >>>> https://accumulo.apache.org/bylaws.html
> > >>>> http://hadoop.apache.org/bylaws.html
> > >>>> https://cwiki.apache.org/confluence/display/KAFKA/Bylaws
> > >>>> http://cloudstack.apache.org/bylaws.html
> > >>>> http://pig.apache.org/bylaws.html
> > >>>>
> > >>>> [My opinion]
> > >>>> I think we should adopt Accumulo's bylaws almost directly. What I
> > >> would
> > >>>> suggest we remove is the custom to have committers invited to the
> > >> PMC. I
> > >>>> think the staged progression to the PMC is important.
> > >>>>
> > >>>> Recommend we also do the same for a release guide. Again Accumulo
> > >> offers
> > >>>> a very good example:
> > >>>>
> > >>>> https://accumulo.apache.org/governance/releasing.html
> > >>>>
> > >>>>
> > >>>> And finally we should clearly define a few terms:
> > >>>>
> > >>>> API:
> > >>>>
> > >>>> We should clearly call out what is the public API and the internal
> > API.
> > >>>> Changes to the public API are very sensitive in nature as they can
> > >>> disturb
> > >>>> the user base. Changes to the private/internal API however are
> > >> important
> > >>>> to allow internal implementation to evolve.
> > >>>>
> > >>>> Versioning Scheme:
> > >>>>
> > >>>> x.y.z Where X = Massive? Y = Major Z = Minor
> > >>>>
> > >>>> Look forward to any thoughts. None of this needs to be solidified
> at
> > >>> this
> > >>>> very early stage for our project. But it is important to establish
> > >>>> something as a basis of further discussion and iteration.
> > >>>>
> > >>>> Happy Thanksgiving.
> > >>>>
> > >>>> Joe
> > >>>>
> > >>>
> > >>
> >
>
Re: Establish [draft] project bylaws, release guide
Posted by Joe Witt <jo...@gmail.com>.
I propose the following rather typical/conventional version scheme for our
artifacts:
[Major].[Minor].[Incremental]
Definitions:
'Major' releases are reserved for changes that alter the API in
non-backward compatible ways or changes in function of the application or
components which could break existing configured data flows.
'Minor' releases are reserved for the addition of significant new features
or backward compatible changes of the API.
'Incremental' releases are reserved for bug fixes, documentation changes,
the inclusion of features or enhancements to existing features which are
deemed routine.
Commentary:
These definitions are imprecise (significant/routine) but perhaps
sufficient at this early stage. We must also be clear about what we mean
by API. We should as mentioned previously clearly articulate that which
the public API and which we will defend aggressively on behalf of the users
versus the 'private API' which we should be free to adjust internally as
needed. We also have to consider that our API is more than the
traditionally considered 'code API' and also includes the web-based
interface to command and control the application. Developers building
extensions should feel confident that their developed capabilities will
work forever within a given major release.
Thanks
Joe
On Thu, Nov 27, 2014 at 8:25 PM, Mark Payne <ma...@hotmail.com> wrote:
> I like the major, minor, incremental terminology. But I think we need to
> provide clear guidance on what qualifies as major and minor. I think this
> is much more important than the terminology.
>
> Sent from my iPhone
>
> > On Nov 27, 2014, at 8:21 PM, Joe Witt <jo...@gmail.com> wrote:
> >
> > I feel like 'major, minor, incremental' is sufficient for our purposes.
> No?
> >
> >> On Thu, Nov 27, 2014 at 3:53 PM, Tony Kurc <tr...@gmail.com> wrote:
> >>
> >> I think the ? is "marketing"
> >>
> >>> On Thu, Nov 27, 2014 at 1:16 PM, Joe Witt <jo...@gmail.com> wrote:
> >>>
> >>> on the versioning scheme i should clarify that the
> >>>
> >>> x.y.z where X= ? , Y = Major, Z = Minor is based on what accumulo
> appears
> >>> to do. I am personally more familiar with
> >>>
> >>> x.y.z where X = Major, Y = Minor, Z = incremental
> >>>
> >>>> On Thu, Nov 27, 2014 at 10:05 AM, Joe Witt <jo...@gmail.com>
> wrote:
> >>>>
> >>>> Folks,
> >>>>
> >>>> Would like to establish and follow very early on the bylaws under
> which
> >>> we
> >>>> will operate. Projects such as Accumulo, CloudStack, Pig, and Kafka
> >> have
> >>>> very similar bylaws with minor differences:
> >>>>
> >>>> [References]
> >>>> https://accumulo.apache.org/bylaws.html
> >>>> http://hadoop.apache.org/bylaws.html
> >>>> https://cwiki.apache.org/confluence/display/KAFKA/Bylaws
> >>>> http://cloudstack.apache.org/bylaws.html
> >>>> http://pig.apache.org/bylaws.html
> >>>>
> >>>> [My opinion]
> >>>> I think we should adopt Accumulo's bylaws almost directly. What I
> >> would
> >>>> suggest we remove is the custom to have committers invited to the
> >> PMC. I
> >>>> think the staged progression to the PMC is important.
> >>>>
> >>>> Recommend we also do the same for a release guide. Again Accumulo
> >> offers
> >>>> a very good example:
> >>>>
> >>>> https://accumulo.apache.org/governance/releasing.html
> >>>>
> >>>>
> >>>> And finally we should clearly define a few terms:
> >>>>
> >>>> API:
> >>>>
> >>>> We should clearly call out what is the public API and the internal
> API.
> >>>> Changes to the public API are very sensitive in nature as they can
> >>> disturb
> >>>> the user base. Changes to the private/internal API however are
> >> important
> >>>> to allow internal implementation to evolve.
> >>>>
> >>>> Versioning Scheme:
> >>>>
> >>>> x.y.z Where X = Massive? Y = Major Z = Minor
> >>>>
> >>>> Look forward to any thoughts. None of this needs to be solidified at
> >>> this
> >>>> very early stage for our project. But it is important to establish
> >>>> something as a basis of further discussion and iteration.
> >>>>
> >>>> Happy Thanksgiving.
> >>>>
> >>>> Joe
> >>>>
> >>>
> >>
>
Re: Establish [draft] project bylaws, release guide
Posted by Mark Payne <ma...@hotmail.com>.
I like the major, minor, incremental terminology. But I think we need to provide clear guidance on what qualifies as major and minor. I think this is much more important than the terminology.
Sent from my iPhone
> On Nov 27, 2014, at 8:21 PM, Joe Witt <jo...@gmail.com> wrote:
>
> I feel like 'major, minor, incremental' is sufficient for our purposes. No?
>
>> On Thu, Nov 27, 2014 at 3:53 PM, Tony Kurc <tr...@gmail.com> wrote:
>>
>> I think the ? is "marketing"
>>
>>> On Thu, Nov 27, 2014 at 1:16 PM, Joe Witt <jo...@gmail.com> wrote:
>>>
>>> on the versioning scheme i should clarify that the
>>>
>>> x.y.z where X= ? , Y = Major, Z = Minor is based on what accumulo appears
>>> to do. I am personally more familiar with
>>>
>>> x.y.z where X = Major, Y = Minor, Z = incremental
>>>
>>>> On Thu, Nov 27, 2014 at 10:05 AM, Joe Witt <jo...@gmail.com> wrote:
>>>>
>>>> Folks,
>>>>
>>>> Would like to establish and follow very early on the bylaws under which
>>> we
>>>> will operate. Projects such as Accumulo, CloudStack, Pig, and Kafka
>> have
>>>> very similar bylaws with minor differences:
>>>>
>>>> [References]
>>>> https://accumulo.apache.org/bylaws.html
>>>> http://hadoop.apache.org/bylaws.html
>>>> https://cwiki.apache.org/confluence/display/KAFKA/Bylaws
>>>> http://cloudstack.apache.org/bylaws.html
>>>> http://pig.apache.org/bylaws.html
>>>>
>>>> [My opinion]
>>>> I think we should adopt Accumulo's bylaws almost directly. What I
>> would
>>>> suggest we remove is the custom to have committers invited to the
>> PMC. I
>>>> think the staged progression to the PMC is important.
>>>>
>>>> Recommend we also do the same for a release guide. Again Accumulo
>> offers
>>>> a very good example:
>>>>
>>>> https://accumulo.apache.org/governance/releasing.html
>>>>
>>>>
>>>> And finally we should clearly define a few terms:
>>>>
>>>> API:
>>>>
>>>> We should clearly call out what is the public API and the internal API.
>>>> Changes to the public API are very sensitive in nature as they can
>>> disturb
>>>> the user base. Changes to the private/internal API however are
>> important
>>>> to allow internal implementation to evolve.
>>>>
>>>> Versioning Scheme:
>>>>
>>>> x.y.z Where X = Massive? Y = Major Z = Minor
>>>>
>>>> Look forward to any thoughts. None of this needs to be solidified at
>>> this
>>>> very early stage for our project. But it is important to establish
>>>> something as a basis of further discussion and iteration.
>>>>
>>>> Happy Thanksgiving.
>>>>
>>>> Joe
>>>>
>>>
>>
Re: Establish [draft] project bylaws, release guide
Posted by Joe Witt <jo...@gmail.com>.
I feel like 'major, minor, incremental' is sufficient for our purposes. No?
On Thu, Nov 27, 2014 at 3:53 PM, Tony Kurc <tr...@gmail.com> wrote:
> I think the ? is "marketing"
>
> On Thu, Nov 27, 2014 at 1:16 PM, Joe Witt <jo...@gmail.com> wrote:
>
> > on the versioning scheme i should clarify that the
> >
> > x.y.z where X= ? , Y = Major, Z = Minor is based on what accumulo appears
> > to do. I am personally more familiar with
> >
> > x.y.z where X = Major, Y = Minor, Z = incremental
> >
> > On Thu, Nov 27, 2014 at 10:05 AM, Joe Witt <jo...@gmail.com> wrote:
> >
> > > Folks,
> > >
> > > Would like to establish and follow very early on the bylaws under which
> > we
> > > will operate. Projects such as Accumulo, CloudStack, Pig, and Kafka
> have
> > > very similar bylaws with minor differences:
> > >
> > > [References]
> > > https://accumulo.apache.org/bylaws.html
> > > http://hadoop.apache.org/bylaws.html
> > > https://cwiki.apache.org/confluence/display/KAFKA/Bylaws
> > > http://cloudstack.apache.org/bylaws.html
> > > http://pig.apache.org/bylaws.html
> > >
> > > [My opinion]
> > > I think we should adopt Accumulo's bylaws almost directly. What I
> would
> > > suggest we remove is the custom to have committers invited to the
> PMC. I
> > > think the staged progression to the PMC is important.
> > >
> > > Recommend we also do the same for a release guide. Again Accumulo
> offers
> > > a very good example:
> > >
> > > https://accumulo.apache.org/governance/releasing.html
> > >
> > >
> > > And finally we should clearly define a few terms:
> > >
> > > API:
> > >
> > > We should clearly call out what is the public API and the internal API.
> > > Changes to the public API are very sensitive in nature as they can
> > disturb
> > > the user base. Changes to the private/internal API however are
> important
> > > to allow internal implementation to evolve.
> > >
> > > Versioning Scheme:
> > >
> > > x.y.z Where X = Massive? Y = Major Z = Minor
> > >
> > > Look forward to any thoughts. None of this needs to be solidified at
> > this
> > > very early stage for our project. But it is important to establish
> > > something as a basis of further discussion and iteration.
> > >
> > > Happy Thanksgiving.
> > >
> > > Joe
> > >
> >
>
Re: Establish [draft] project bylaws, release guide
Posted by Tony Kurc <tr...@gmail.com>.
I think the ? is "marketing"
On Thu, Nov 27, 2014 at 1:16 PM, Joe Witt <jo...@gmail.com> wrote:
> on the versioning scheme i should clarify that the
>
> x.y.z where X= ? , Y = Major, Z = Minor is based on what accumulo appears
> to do. I am personally more familiar with
>
> x.y.z where X = Major, Y = Minor, Z = incremental
>
> On Thu, Nov 27, 2014 at 10:05 AM, Joe Witt <jo...@gmail.com> wrote:
>
> > Folks,
> >
> > Would like to establish and follow very early on the bylaws under which
> we
> > will operate. Projects such as Accumulo, CloudStack, Pig, and Kafka have
> > very similar bylaws with minor differences:
> >
> > [References]
> > https://accumulo.apache.org/bylaws.html
> > http://hadoop.apache.org/bylaws.html
> > https://cwiki.apache.org/confluence/display/KAFKA/Bylaws
> > http://cloudstack.apache.org/bylaws.html
> > http://pig.apache.org/bylaws.html
> >
> > [My opinion]
> > I think we should adopt Accumulo's bylaws almost directly. What I would
> > suggest we remove is the custom to have committers invited to the PMC. I
> > think the staged progression to the PMC is important.
> >
> > Recommend we also do the same for a release guide. Again Accumulo offers
> > a very good example:
> >
> > https://accumulo.apache.org/governance/releasing.html
> >
> >
> > And finally we should clearly define a few terms:
> >
> > API:
> >
> > We should clearly call out what is the public API and the internal API.
> > Changes to the public API are very sensitive in nature as they can
> disturb
> > the user base. Changes to the private/internal API however are important
> > to allow internal implementation to evolve.
> >
> > Versioning Scheme:
> >
> > x.y.z Where X = Massive? Y = Major Z = Minor
> >
> > Look forward to any thoughts. None of this needs to be solidified at
> this
> > very early stage for our project. But it is important to establish
> > something as a basis of further discussion and iteration.
> >
> > Happy Thanksgiving.
> >
> > Joe
> >
>
Re: Establish [draft] project bylaws, release guide
Posted by Joe Witt <jo...@gmail.com>.
on the versioning scheme i should clarify that the
x.y.z where X= ? , Y = Major, Z = Minor is based on what accumulo appears
to do. I am personally more familiar with
x.y.z where X = Major, Y = Minor, Z = incremental
On Thu, Nov 27, 2014 at 10:05 AM, Joe Witt <jo...@gmail.com> wrote:
> Folks,
>
> Would like to establish and follow very early on the bylaws under which we
> will operate. Projects such as Accumulo, CloudStack, Pig, and Kafka have
> very similar bylaws with minor differences:
>
> [References]
> https://accumulo.apache.org/bylaws.html
> http://hadoop.apache.org/bylaws.html
> https://cwiki.apache.org/confluence/display/KAFKA/Bylaws
> http://cloudstack.apache.org/bylaws.html
> http://pig.apache.org/bylaws.html
>
> [My opinion]
> I think we should adopt Accumulo's bylaws almost directly. What I would
> suggest we remove is the custom to have committers invited to the PMC. I
> think the staged progression to the PMC is important.
>
> Recommend we also do the same for a release guide. Again Accumulo offers
> a very good example:
>
> https://accumulo.apache.org/governance/releasing.html
>
>
> And finally we should clearly define a few terms:
>
> API:
>
> We should clearly call out what is the public API and the internal API.
> Changes to the public API are very sensitive in nature as they can disturb
> the user base. Changes to the private/internal API however are important
> to allow internal implementation to evolve.
>
> Versioning Scheme:
>
> x.y.z Where X = Massive? Y = Major Z = Minor
>
> Look forward to any thoughts. None of this needs to be solidified at this
> very early stage for our project. But it is important to establish
> something as a basis of further discussion and iteration.
>
> Happy Thanksgiving.
>
> Joe
>
Re: Establish [draft] project bylaws, release guide
Posted by Joe Witt <jo...@gmail.com>.
Andrew, Arvind, Sergio,
Thank you for the feedback. As you point out we'll just clarify guidelines
if and as needed. Less is certainly more.
Thanks
Joe
On Sun, Nov 30, 2014 at 3:55 PM, Andrew Purtell <ap...@apache.org> wrote:
> Some projects have succeeded for many years without even holding a vote,
> discussions that establish consensus have been sufficient. Other projects,
> with divided PMCs split among competing commercial concens, have spent a
> lot of time refining project-specific criteria. What you need will depend
> on the community the podling develops. I also recommend starting with the
> Foundation bylaws and then reflect after producing the first couple
> releases on what is working, what isn't, and what might help.
>
>
> On Sunday, November 30, 2014, Arvind Prabhakar <ar...@streamsets.com>
> wrote:
>
> > From my experience:
> >
> > Bylaws is something you have to formally define on TLP graduation,
> > > therefore you still have room to discuss such aspect.
> >
> >
> > This is not a necessity. Only if the PMC feels that it could help
> reducing
> > contentions etc, then it makes sense. There are projects that operate
> with
> > no formal bylaws other than what is considered an accepted practice.
> >
> > My suggestion on this topic is that - it is better to observe how the
> > community grows and let that shape up the bylaws if needed. Setting up
> > bylaws this early may bring in discipline but could have other costs.
> >
> > Regards,
> > Arvind
> >
> >
> > On Sat, Nov 29, 2014 at 12:56 AM, Sergio Fernández <wikier@apache.org
> > <javascript:;>>
> > wrote:
> >
> > > Hi Joe,
> > >
> > > On 29/11/14 03:03, Joe Witt wrote:
> > >
> > >> If the general feel is that bylaws particularly of the basic form
> > >> referenced previously are unnecessary at this early stage then we'll
> > just
> > >> table it. Still would like to document our intended 'voting table'.
> > >>
> > >
> > > Bylaws is something you have to formally define on TLP graduation,
> > > therefore you still have room to discuss such aspect.
> > >
> > > My personal recommendation is to stay for now with the Foundation
> bylaws,
> > > and just if you miss something during the incubation (AFAIK 80% of the
> > TLP
> > > project do not need it) then, just then, go ahead to defined
> specialized
> > > ones for NiFi.
> > >
> > > Cheers,
> > >
> > >
> > > --
> > > Sergio Fernández
> > > Partner Technology Manager
> > > Redlink GmbH
> > > m: +43 660 2747 925
> > > e: sergio.fernandez@redlink.co <javascript:;>
> > > w: http://redlink.co
> > >
> >
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
Re: Establish [draft] project bylaws, release guide
Posted by Andrew Purtell <ap...@apache.org>.
Some projects have succeeded for many years without even holding a vote,
discussions that establish consensus have been sufficient. Other projects,
with divided PMCs split among competing commercial concens, have spent a
lot of time refining project-specific criteria. What you need will depend
on the community the podling develops. I also recommend starting with the
Foundation bylaws and then reflect after producing the first couple
releases on what is working, what isn't, and what might help.
On Sunday, November 30, 2014, Arvind Prabhakar <ar...@streamsets.com>
wrote:
> From my experience:
>
> Bylaws is something you have to formally define on TLP graduation,
> > therefore you still have room to discuss such aspect.
>
>
> This is not a necessity. Only if the PMC feels that it could help reducing
> contentions etc, then it makes sense. There are projects that operate with
> no formal bylaws other than what is considered an accepted practice.
>
> My suggestion on this topic is that - it is better to observe how the
> community grows and let that shape up the bylaws if needed. Setting up
> bylaws this early may bring in discipline but could have other costs.
>
> Regards,
> Arvind
>
>
> On Sat, Nov 29, 2014 at 12:56 AM, Sergio Fernández <wikier@apache.org
> <javascript:;>>
> wrote:
>
> > Hi Joe,
> >
> > On 29/11/14 03:03, Joe Witt wrote:
> >
> >> If the general feel is that bylaws particularly of the basic form
> >> referenced previously are unnecessary at this early stage then we'll
> just
> >> table it. Still would like to document our intended 'voting table'.
> >>
> >
> > Bylaws is something you have to formally define on TLP graduation,
> > therefore you still have room to discuss such aspect.
> >
> > My personal recommendation is to stay for now with the Foundation bylaws,
> > and just if you miss something during the incubation (AFAIK 80% of the
> TLP
> > project do not need it) then, just then, go ahead to defined specialized
> > ones for NiFi.
> >
> > Cheers,
> >
> >
> > --
> > Sergio Fernández
> > Partner Technology Manager
> > Redlink GmbH
> > m: +43 660 2747 925
> > e: sergio.fernandez@redlink.co <javascript:;>
> > w: http://redlink.co
> >
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Establish [draft] project bylaws, release guide
Posted by Arvind Prabhakar <ar...@streamsets.com>.
>From my experience:
Bylaws is something you have to formally define on TLP graduation,
> therefore you still have room to discuss such aspect.
This is not a necessity. Only if the PMC feels that it could help reducing
contentions etc, then it makes sense. There are projects that operate with
no formal bylaws other than what is considered an accepted practice.
My suggestion on this topic is that - it is better to observe how the
community grows and let that shape up the bylaws if needed. Setting up
bylaws this early may bring in discipline but could have other costs.
Regards,
Arvind
On Sat, Nov 29, 2014 at 12:56 AM, Sergio Fernández <wi...@apache.org>
wrote:
> Hi Joe,
>
> On 29/11/14 03:03, Joe Witt wrote:
>
>> If the general feel is that bylaws particularly of the basic form
>> referenced previously are unnecessary at this early stage then we'll just
>> table it. Still would like to document our intended 'voting table'.
>>
>
> Bylaws is something you have to formally define on TLP graduation,
> therefore you still have room to discuss such aspect.
>
> My personal recommendation is to stay for now with the Foundation bylaws,
> and just if you miss something during the incubation (AFAIK 80% of the TLP
> project do not need it) then, just then, go ahead to defined specialized
> ones for NiFi.
>
> Cheers,
>
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 660 2747 925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co
>
Re: Establish [draft] project bylaws, release guide
Posted by Sergio Fernández <wi...@apache.org>.
Hi Joe,
On 29/11/14 03:03, Joe Witt wrote:
> If the general feel is that bylaws particularly of the basic form
> referenced previously are unnecessary at this early stage then we'll just
> table it. Still would like to document our intended 'voting table'.
Bylaws is something you have to formally define on TLP graduation,
therefore you still have room to discuss such aspect.
My personal recommendation is to stay for now with the Foundation
bylaws, and just if you miss something during the incubation (AFAIK 80%
of the TLP project do not need it) then, just then, go ahead to defined
specialized ones for NiFi.
Cheers,
--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 660 2747 925
e: sergio.fernandez@redlink.co
w: http://redlink.co
Re: Establish [draft] project bylaws, release guide
Posted by Joe Witt <jo...@gmail.com>.
Sergio
"Do you really need project specific bylaws?"
I was thinking it was the norm for podlings to establish this. But after
looking further I see the presence of them being very hit or miss among
projects. What I do like about the idea is that it just helps establish
some structure around the nature of the project structure and in particular
documenting the voting cycle and default orientation for many cases (lazy
consensus, etc..). What really got me started on that track was noticing a
relatively contentious (albeit professional in nature) exchange on another
project recently. They were resorting to quoting their bylaws in settling
a dispute. Obviously great care should be taken to avoid even needing them
but ...
If the general feel is that bylaws particularly of the basic form
referenced previously are unnecessary at this early stage then we'll just
table it. Still would like to document our intended 'voting table'.
Thanks
Joe
On Fri, Nov 28, 2014 at 3:59 AM, Sergio Fernández <wi...@apache.org> wrote:
> Do you really need project specific bylaws?
> You can always establish pursuant to bylaws of the Foundation.
>
>
> On 27/11/14 16:05, Joe Witt wrote:
>
>> Folks,
>>
>> Would like to establish and follow very early on the bylaws under which we
>> will operate. Projects such as Accumulo, CloudStack, Pig, and Kafka have
>> very similar bylaws with minor differences:
>>
>> [References]
>> https://accumulo.apache.org/bylaws.html
>> http://hadoop.apache.org/bylaws.html
>> https://cwiki.apache.org/confluence/display/KAFKA/Bylaws
>> http://cloudstack.apache.org/bylaws.html
>> http://pig.apache.org/bylaws.html
>>
>> [My opinion]
>> I think we should adopt Accumulo's bylaws almost directly. What I would
>> suggest we remove is the custom to have committers invited to the PMC. I
>> think the staged progression to the PMC is important.
>>
>> Recommend we also do the same for a release guide. Again Accumulo offers
>> a
>> very good example:
>>
>> https://accumulo.apache.org/governance/releasing.html
>>
>>
>> And finally we should clearly define a few terms:
>>
>> API:
>>
>> We should clearly call out what is the public API and the internal API.
>> Changes to the public API are very sensitive in nature as they can disturb
>> the user base. Changes to the private/internal API however are important
>> to allow internal implementation to evolve.
>>
>> Versioning Scheme:
>>
>> x.y.z Where X = Massive? Y = Major Z = Minor
>>
>> Look forward to any thoughts. None of this needs to be solidified at this
>> very early stage for our project. But it is important to establish
>> something as a basis of further discussion and iteration.
>>
>> Happy Thanksgiving.
>>
>> Joe
>>
>>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 660 2747 925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co
>
Re: Establish [draft] project bylaws, release guide
Posted by Sergio Fernández <wi...@apache.org>.
Do you really need project specific bylaws?
You can always establish pursuant to bylaws of the Foundation.
On 27/11/14 16:05, Joe Witt wrote:
> Folks,
>
> Would like to establish and follow very early on the bylaws under which we
> will operate. Projects such as Accumulo, CloudStack, Pig, and Kafka have
> very similar bylaws with minor differences:
>
> [References]
> https://accumulo.apache.org/bylaws.html
> http://hadoop.apache.org/bylaws.html
> https://cwiki.apache.org/confluence/display/KAFKA/Bylaws
> http://cloudstack.apache.org/bylaws.html
> http://pig.apache.org/bylaws.html
>
> [My opinion]
> I think we should adopt Accumulo's bylaws almost directly. What I would
> suggest we remove is the custom to have committers invited to the PMC. I
> think the staged progression to the PMC is important.
>
> Recommend we also do the same for a release guide. Again Accumulo offers a
> very good example:
>
> https://accumulo.apache.org/governance/releasing.html
>
>
> And finally we should clearly define a few terms:
>
> API:
>
> We should clearly call out what is the public API and the internal API.
> Changes to the public API are very sensitive in nature as they can disturb
> the user base. Changes to the private/internal API however are important
> to allow internal implementation to evolve.
>
> Versioning Scheme:
>
> x.y.z Where X = Massive? Y = Major Z = Minor
>
> Look forward to any thoughts. None of this needs to be solidified at this
> very early stage for our project. But it is important to establish
> something as a basis of further discussion and iteration.
>
> Happy Thanksgiving.
>
> Joe
>
--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 660 2747 925
e: sergio.fernandez@redlink.co
w: http://redlink.co