Good catch.  I'm not sure what the right approach is there, I wonder what
other projects do for the same situation

Jon

On Mon, Oct 8, 2018 at 3:24 PM Justin Leet <justinjl...@gmail.com> wrote:

> https://github.com/apache/metron/pull/1188 scripts the creation of RC's.
> It does this split, and allows for independent releases. The main catch is
> a slight hangup with the KEYS file.
>
> The metron-bro-kafka-plugin repo doesn't contain a KEYS file, it currently
> has just been aligned with the main repo's KEYS file.The KEYS file doesn't
> need to live in each submodule's directory, just in the main folder (
> https://dist.apache.org/repos/dist/release/metron/).  This means it's not
> a
> problem for the plugin repo to be missing it.
>
> The main catch is that right now, we only publish the KEYS file when we
> release the main repo. In the (admittedly rare) situation where we have a
> new release manager who has to update the KEYS file, we'd currently need to
> do a metron release before we could do a plugin release.
>
> Should we split out and document a KEYS update from the main repo?
> Essentially, just run through the normal PR process and then have a post
> merge step of kicking up the updated KEYS file.  Then Release Process
> <https://cwiki.apache.org/confluence/display/METRON/Release+Process> would
> just get updated to reflect this process.
>
>
> On Fri, Sep 7, 2018 at 3:15 PM Casey Stella <ceste...@gmail.com> wrote:
>
> > +1 to defer for this release and complete separation.  Good fences make
> > good submodules. ;)
> >
> > On Fri, Sep 7, 2018 at 2:33 PM zeo...@gmail.com <zeo...@gmail.com>
> wrote:
> >
> > > +1 to defer for this release and +1 to Justin's suggested release/dist
> > > directory breakout and complete separation.
> > >
> > > Jon
> > >
> > > On Fri, Sep 7, 2018 at 1:43 PM Michael Miklavcic <
> > > michael.miklav...@gmail.com> wrote:
> > >
> > > > +1 to deferring for this release and having the separation like NiFi.
> > > Since
> > > > we're bootstrapping from their process, what are they doing? I would
> > > assume
> > > > we'd want some sort of vote for the plugin version change as well.
> > > >
> > > > On Fri, Sep 7, 2018 at 10:15 AM Nick Allen <n...@nickallen.org>
> wrote:
> > > >
> > > > > +1 for complete separation as you've described.
> > > > >
> > > > > On Fri, Sep 7, 2018 at 11:31 AM Justin Leet <justinjl...@gmail.com
> >
> > > > wrote:
> > > > >
> > > > > > I would like this to be a complete separation.  Complete with
> > > separate
> > > > > RCs,
> > > > > > separate call to vote, etc. There's a bit more overhead, but
> plugin
> > > > > > releases should be rarer and as the release infra gets improved
> and
> > > > > > scripted out more, I don't think it'll end up being much more
> than
> > > > > bundling
> > > > > > it together.
> > > > > >
> > > > > > On Fri, Sep 7, 2018 at 11:27 AM Nick Allen <n...@nickallen.org>
> > > wrote:
> > > > > >
> > > > > > > > Other projects, e.g. NiFi <http://apache.org/dist/nifi/>,
> > split
> > > > > apart
> > > > > > > these releases within their dist directories.
> > > > > > >
> > > > > > > I prefer the way Nifi organizes it.  Definitely seems more
> > > logically
> > > > > > > organized.
> > > > > > >
> > > > > > >
> > > > > > > > If we split them apart, we can make the releases
> independently.
> > > > This
> > > > > > > fixes the problem of aligning the versions (simply release the
> > > plugin
> > > > > > > first, update full-dev, release core Metron).
> > > > > > >
> > > > > > > Does this entail a complete separation; including a separate
> > > > > > call-to-vote?
> > > > > > > One vote for core Metron and a separate vote for plugin?
> > > > > > >
> > > > > > >
> > > > > > > > Do we want try to get this separation done after the current
> > > > release
> > > > > > > cycle is over?
> > > > > > >
> > > > > > > +1 Let's wait for the next release to hash this out.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Sep 7, 2018 at 10:27 AM Justin Leet <
> > justinjl...@gmail.com
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > Right now, we tie together our main release and the Bro
> plugin,
> > > as
> > > > > seen
> > > > > > > in
> > > > > > > > our 0.4.2 release
> > > > > > > > https://archive.apache.org/dist/metron/0.4.2/ and the
> current
> > > RC.
> > > > > > > >
> > > > > > > > Other projects, e.g. NiFi <http://apache.org/dist/nifi/>,
> > split
> > > > > apart
> > > > > > > > these
> > > > > > > > releases within their dist directories.
> > > > > > > >
> > > > > > > > In our case this might look something like
> > > > > > > > 0.5.0/
> > > > > > > > metron-bro-plugin-kafka
> > > > > > > >     - 0.2.0/
> > > > > > > >
> > > > > > > > Right now, with the releases tied together, we aren't
> upgrading
> > > > > > full-dev
> > > > > > > > with the version of the plugin (because we're releasing
> > > > > simultaneously
> > > > > > > and
> > > > > > > > can't update the version number).
> > > > > > > >
> > > > > > > > If we split them apart, we can make the releases
> independently.
> > > > This
> > > > > > > fixes
> > > > > > > > the problem of aligning the versions (simply release the
> plugin
> > > > > first,
> > > > > > > > update full-dev, release core Metron).  The plugin also
> updates
> > > > > > > > substantially less often and we can just do those releases
> at a
> > > > > cadence
> > > > > > > we
> > > > > > > > choose.
> > > > > > > >
> > > > > > > > Any thoughts on doing this?
> > > > > > > > Do we want try to get this separation done after the current
> > > > release
> > > > > > > cycle
> > > > > > > > is over?
> > > > > > > > If we do, do we have a preferred layout? I didn't see
> anything
> > > > Apache
> > > > > > > > preferred in a quick search, but I definitely could have
> missed
> > > > > > something
> > > > > > > > (and https://checker.apache.org/projs/nifi.html looks clean
> > for
> > > > > NiFi,
> > > > > > > so I
> > > > > > > > assume it's fine.)
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > --
> > >
> > > Jon
> > >
> >
>
-- 

Jon

Reply via email to