Re: Why separate Streams-Master and Streams-Project ?

2016-12-27 Thread Matt Franklin 
I see.  It has been a while since I have looked at master.  Generally,
master is just used for cross-project settings like developer info, etc.
We could move versions down into the parent pom of the main repo and then
just have examples reference the parent.  That way versions are controlled
at the streams repository level, master is only updated with developers,
and examples gets the version changes from the main repo.



On Tue, Dec 27, 2016 at 6:27 PM Suneel Marthi  wrote:

> Flink announced 1.1.4 release this weekend
>
> slf4j is out with 1.7.22
>
> and other dep jars that might change ...
>
> On the other Apache projects I am on I see some of the jars being updated
> with each release, so its expected that the master changes frequently.
>
> On Tue, Dec 27, 2016 at 5:54 PM, Matt Franklin 
> wrote:
>
> > On Thu, Dec 15, 2016 at 4:27 PM Steve Blackmon 
> wrote:
> >
> > > This could be a breaking change to dependent projects.
> > >
> > > For example, if your internal streams repo's parent pom is
> streams-master
> > > and streams-master suddenly disappears in the latest release, that’s
> > going
> > > to take some refactoring to fix.
> > >
> > > Additionally, there’s significant impact to poms, to documentation, to
> > > Jenkins, to the project website build and deployment process.
> > >
> > > For these reason I think it should not be rushed into a maintenance
> > > release.
> > >
> >
> > I am still curious why the master file is changing so often...
> >
> >
> > >
> > > Steve
> > >
> > > On November 26, 2016 at 1:22:23 PM, Suneel Marthi (
> > suneel.mar...@gmail.com
> > > )
> > > wrote:
> > >
> > > Do we wanna target this for 0.4.1 or 0.5 release ?
> > >
> > > On Sat, Nov 26, 2016 at 10:00 AM, sblackmon 
> > wrote:
> > >
> > > > Agreed - reopened STREAMS-255.
> > > > On November 25, 2016 at 2:00:51 PM, Suneel Marthi (
> smar...@apache.org)
> > > > wrote:
> > > >
> > > > Seems like we have consensus in merging streams-master and
> > > streams-project.
> > > > If correct, let's target this for 0.5 release.
> > > >
> > > > On Mon, Nov 14, 2016 at 8:21 AM, Ate Douma  wrote:
> > > >
> > > > > On 2016-11-14 12:22, Suneel Marthi wrote:
> > > > >
> > > > >> On Mon, Nov 14, 2016 at 11:27 AM, sblackmon  >
> > > > wrote:
> > > > >>
> > > > >>
> > > > >>> On November 11, 2016 at 5:17:11 PM, Matt Franklin (
> > > > >>> m.ben.frank...@gmail.com(mailto:m.ben.frank...@gmail.com))
> wrote:
> > > > >>>
> > > > >>> On Thu, Nov 10, 2016 at 6:12 PM Suneel Marthi wrote:
> > > > 
> > > >  Why do we have 3 separate projects - Streams-master,
> > Streams-project
> > > > >
> > > >  and
> > > > >>>
> > > >  streams-examples?
> > > > >
> > > > >
> > > >  The split between streams-master and streams-project has been
> > there
> > > > >>> since
> > > > >>> the project started, I think a legacy of how Rave was organized.
> > The
> > > > >>> feedback related to naming (that ‘master’ is confusing given the
> > > source
> > > > >>> code is in git) makes sense to me.
> > > > >>>
> > > > 
> > > > 
> > > > > While it may make sense to keep streams-examples separate from
> > the
> > > > >
> > > >  others,
> > > > >>>
> > > >  what's the reasoning behind keeping separate streams-master and
> > > > > streams-project ?
> > > > >
> > > > >
> > > >  Keeping the master pom separate from the rest of the project is
> > > fairly
> > > >  common within Apache. It allows things that don't change often
> to
> > be
> > > >  centralized, such as developer info, etc. I am +1 for keeping it
> > on
> > > a
> > > >  separate release cycle and +0 for integrating it back into the
> > main
> > > > code
> > > >  repo.
> > > > 
> > > >  I’m -1 to separate release cycles - In reality we’re making a
> > change
> > > > to
> > > > >>> the POM and/or the website, currently organized under
> > streams-master,
> > > > >>> every
> > > > >>> release cycle, and it would be confusing for developers if the
> > > versions
> > > > >>> became disconnected.
> > > > >>>
> > > > >>>
> > > > >> I am -1 too for separate release cycles. I can see streams-master
> > > being
> > > > >> modified/updated on a regular basis, given that most other
> > dependency
> > > > >> projects like Spark, Flink etc are on a 2 month minor release
> cycle
> > > and
> > > > a
> > > > >> 4
> > > > >> month major release cycle (on an average).
> > > > >>
> > > > >
> > > > > Maybe the real problem is that streams-master is modified/updated
> on
> > a
> > > > > regular
> > > > > basis.
> > > > >
> > > > > The original idea was to (only) separate out and centralize the
> > general
> > > > > things
> > > > > (like issueManagement, licensing, supported java version,
> > > developerInfo,
> > > > > common/generic plugin configurations, etc.) which should not need
> to
> > be
> > > > > modified
>

Re: Why separate Streams-Master and Streams-Project ?

2016-12-27 Thread Suneel Marthi 
Flink announced 1.1.4 release this weekend

slf4j is out with 1.7.22

and other dep jars that might change ...

On the other Apache projects I am on I see some of the jars being updated
with each release, so its expected that the master changes frequently.

On Tue, Dec 27, 2016 at 5:54 PM, Matt Franklin 
wrote:

> On Thu, Dec 15, 2016 at 4:27 PM Steve Blackmon  wrote:
>
> > This could be a breaking change to dependent projects.
> >
> > For example, if your internal streams repo's parent pom is streams-master
> > and streams-master suddenly disappears in the latest release, that’s
> going
> > to take some refactoring to fix.
> >
> > Additionally, there’s significant impact to poms, to documentation, to
> > Jenkins, to the project website build and deployment process.
> >
> > For these reason I think it should not be rushed into a maintenance
> > release.
> >
>
> I am still curious why the master file is changing so often...
>
>
> >
> > Steve
> >
> > On November 26, 2016 at 1:22:23 PM, Suneel Marthi (
> suneel.mar...@gmail.com
> > )
> > wrote:
> >
> > Do we wanna target this for 0.4.1 or 0.5 release ?
> >
> > On Sat, Nov 26, 2016 at 10:00 AM, sblackmon 
> wrote:
> >
> > > Agreed - reopened STREAMS-255.
> > > On November 25, 2016 at 2:00:51 PM, Suneel Marthi (smar...@apache.org)
> > > wrote:
> > >
> > > Seems like we have consensus in merging streams-master and
> > streams-project.
> > > If correct, let's target this for 0.5 release.
> > >
> > > On Mon, Nov 14, 2016 at 8:21 AM, Ate Douma  wrote:
> > >
> > > > On 2016-11-14 12:22, Suneel Marthi wrote:
> > > >
> > > >> On Mon, Nov 14, 2016 at 11:27 AM, sblackmon 
> > > wrote:
> > > >>
> > > >>
> > > >>> On November 11, 2016 at 5:17:11 PM, Matt Franklin (
> > > >>> m.ben.frank...@gmail.com(mailto:m.ben.frank...@gmail.com)) wrote:
> > > >>>
> > > >>> On Thu, Nov 10, 2016 at 6:12 PM Suneel Marthi wrote:
> > > 
> > >  Why do we have 3 separate projects - Streams-master,
> Streams-project
> > > >
> > >  and
> > > >>>
> > >  streams-examples?
> > > >
> > > >
> > >  The split between streams-master and streams-project has been
> there
> > > >>> since
> > > >>> the project started, I think a legacy of how Rave was organized.
> The
> > > >>> feedback related to naming (that ‘master’ is confusing given the
> > source
> > > >>> code is in git) makes sense to me.
> > > >>>
> > > 
> > > 
> > > > While it may make sense to keep streams-examples separate from
> the
> > > >
> > >  others,
> > > >>>
> > >  what's the reasoning behind keeping separate streams-master and
> > > > streams-project ?
> > > >
> > > >
> > >  Keeping the master pom separate from the rest of the project is
> > fairly
> > >  common within Apache. It allows things that don't change often to
> be
> > >  centralized, such as developer info, etc. I am +1 for keeping it
> on
> > a
> > >  separate release cycle and +0 for integrating it back into the
> main
> > > code
> > >  repo.
> > > 
> > >  I’m -1 to separate release cycles - In reality we’re making a
> change
> > > to
> > > >>> the POM and/or the website, currently organized under
> streams-master,
> > > >>> every
> > > >>> release cycle, and it would be confusing for developers if the
> > versions
> > > >>> became disconnected.
> > > >>>
> > > >>>
> > > >> I am -1 too for separate release cycles. I can see streams-master
> > being
> > > >> modified/updated on a regular basis, given that most other
> dependency
> > > >> projects like Spark, Flink etc are on a 2 month minor release cycle
> > and
> > > a
> > > >> 4
> > > >> month major release cycle (on an average).
> > > >>
> > > >
> > > > Maybe the real problem is that streams-master is modified/updated on
> a
> > > > regular
> > > > basis.
> > > >
> > > > The original idea was to (only) separate out and centralize the
> general
> > > > things
> > > > (like issueManagement, licensing, supported java version,
> > developerInfo,
> > > > common/generic plugin configurations, etc.) which should not need to
> be
> > > > modified
> > > > on a regular basis. And thus also shouldn't need to be released
> often.
> > > >
> > > > However the master pom now indeed also defines practically all
> > > > dependencies,
> > > > which IMO should not (need to) be defined there.
> > > >
> > > > I've no real problem (+/-0) moving streams-master into
> streams-project,
> > > > however
> > > > that will then require streams-examples to directly depend on
> > > > streams-project,
> > > > while currently it also uses streams-master as parent.
> > > >
> > > > From a (better) separation of concern I still think using a separate
> > > > streams-master (which by all means can be renamed like to
> > streams-parent)
> > > > would
> > > > be better, certainly to allow and support better modularity and
> > > > independent release cycles of

Re: Why separate Streams-Master and Streams-Project ?

2016-12-27 Thread Matt Franklin 
On Thu, Dec 15, 2016 at 4:27 PM Steve Blackmon  wrote:

> This could be a breaking change to dependent projects.
>
> For example, if your internal streams repo's parent pom is streams-master
> and streams-master suddenly disappears in the latest release, that’s going
> to take some refactoring to fix.
>
> Additionally, there’s significant impact to poms, to documentation, to
> Jenkins, to the project website build and deployment process.
>
> For these reason I think it should not be rushed into a maintenance
> release.
>

I am still curious why the master file is changing so often...


>
> Steve
>
> On November 26, 2016 at 1:22:23 PM, Suneel Marthi (suneel.mar...@gmail.com
> )
> wrote:
>
> Do we wanna target this for 0.4.1 or 0.5 release ?
>
> On Sat, Nov 26, 2016 at 10:00 AM, sblackmon  wrote:
>
> > Agreed - reopened STREAMS-255.
> > On November 25, 2016 at 2:00:51 PM, Suneel Marthi (smar...@apache.org)
> > wrote:
> >
> > Seems like we have consensus in merging streams-master and
> streams-project.
> > If correct, let's target this for 0.5 release.
> >
> > On Mon, Nov 14, 2016 at 8:21 AM, Ate Douma  wrote:
> >
> > > On 2016-11-14 12:22, Suneel Marthi wrote:
> > >
> > >> On Mon, Nov 14, 2016 at 11:27 AM, sblackmon 
> > wrote:
> > >>
> > >>
> > >>> On November 11, 2016 at 5:17:11 PM, Matt Franklin (
> > >>> m.ben.frank...@gmail.com(mailto:m.ben.frank...@gmail.com)) wrote:
> > >>>
> > >>> On Thu, Nov 10, 2016 at 6:12 PM Suneel Marthi wrote:
> > 
> >  Why do we have 3 separate projects - Streams-master, Streams-project
> > >
> >  and
> > >>>
> >  streams-examples?
> > >
> > >
> >  The split between streams-master and streams-project has been there
> > >>> since
> > >>> the project started, I think a legacy of how Rave was organized. The
> > >>> feedback related to naming (that ‘master’ is confusing given the
> source
> > >>> code is in git) makes sense to me.
> > >>>
> > 
> > 
> > > While it may make sense to keep streams-examples separate from the
> > >
> >  others,
> > >>>
> >  what's the reasoning behind keeping separate streams-master and
> > > streams-project ?
> > >
> > >
> >  Keeping the master pom separate from the rest of the project is
> fairly
> >  common within Apache. It allows things that don't change often to be
> >  centralized, such as developer info, etc. I am +1 for keeping it on
> a
> >  separate release cycle and +0 for integrating it back into the main
> > code
> >  repo.
> > 
> >  I’m -1 to separate release cycles - In reality we’re making a change
> > to
> > >>> the POM and/or the website, currently organized under streams-master,
> > >>> every
> > >>> release cycle, and it would be confusing for developers if the
> versions
> > >>> became disconnected.
> > >>>
> > >>>
> > >> I am -1 too for separate release cycles. I can see streams-master
> being
> > >> modified/updated on a regular basis, given that most other dependency
> > >> projects like Spark, Flink etc are on a 2 month minor release cycle
> and
> > a
> > >> 4
> > >> month major release cycle (on an average).
> > >>
> > >
> > > Maybe the real problem is that streams-master is modified/updated on a
> > > regular
> > > basis.
> > >
> > > The original idea was to (only) separate out and centralize the general
> > > things
> > > (like issueManagement, licensing, supported java version,
> developerInfo,
> > > common/generic plugin configurations, etc.) which should not need to be
> > > modified
> > > on a regular basis. And thus also shouldn't need to be released often.
> > >
> > > However the master pom now indeed also defines practically all
> > > dependencies,
> > > which IMO should not (need to) be defined there.
> > >
> > > I've no real problem (+/-0) moving streams-master into streams-project,
> > > however
> > > that will then require streams-examples to directly depend on
> > > streams-project,
> > > while currently it also uses streams-master as parent.
> > >
> > > From a (better) separation of concern I still think using a separate
> > > streams-master (which by all means can be renamed like to
> streams-parent)
> > > would
> > > be better, certainly to allow and support better modularity and
> > > independent release cycles of subsets of streams in the future.
> > > In the current state however there isn't much need for this, yet, and
> > > separating
> > > it up again when needed in the future won't be a big deal either.
> > >
> > > So therefore +0 if others think this is useful to do now.
> > >
> > > Ate
> > >
> > >
> > >
> > >> In light of the above argument, I think it makes sense to merge
> > >> streams-master and streams-project.
> > >>
> > >>
> > >>
> > >>> I’m +1 to merging streams-master into streams-project - I can’t think
> > of
> > >>> any reasons that wouldn’t work, it would simplify build, tests, CI,
> > >>> releases, and