Re: [VOTE] Update dev guidelines with format for sharing architecture source files and rendered images
That works too On Fri, Apr 26, 2019, 12:20 PM Otto Fowler wrote: > When I say module, I mean at the root of any module, so each module could > have it’s own diagrams. > And the project root wold have diagrams for the ‘overall' > > > On April 26, 2019 at 13:44:30, Michael Miklavcic ( > michael.miklav...@gmail.com) wrote: > > The convention that seems to have been followed thus far has been to plop > the images in the root of the module they're relevant to. Maybe relocating > them to a central place would make it easier. The site-book image link > rewriting might be simpler then as well. The only downside to this approach > would be that the artifacts are split from their respective modules, but I > honestly don't see that as a problem. > > On Fri, Apr 26, 2019, 11:40 AM Otto Fowler > wrote: > > > On April 26, 2019 at 13:19:05, Michael Miklavcic ( > > michael.miklav...@gmail.com) wrote: > > > > @otto when I get your responses to my Q's inline below I can post another > > revision. > > > > On Thu, Apr 25, 2019 at 11:52 AM Otto Fowler > > wrote: > > > > > - We need to specify the format I think, and then say that draw io is > the > > > tool for the format and not just specify the tool. > > > > > > > Format for the source files, rendered files, or both? I believe their > > source file format is a proprietary XML format. For rendered images, I > > don't have a strong opinion and am happy to leave that up to the > > implementer. If we want to be more opinionated, i.e. specify png, svg, > > jpeg, etc. I could probably be persuaded. For the source file comment, > > maybe it would help if I did the full write-up for 3.1 wrt instructions > for > > how to produce the diagrams and source files from draw.io. > > > > > > I think what you say would be ok then, if draw io only has one source > > format. > > > > I don’t care about the image format either, I’m surprised nobody has a > > strong opinion about it. > > > > Do we want a standard place to put the diagrams? > > > > module/ > > - diagrams/ > > - foo.xml > > - foo.png > > - pr1234.xml > > - pr1234.jpeg > > - METRON-13244.xml > > - METRON-13244.png > > - EnrichementArchitecture.xml > > - EnrichementArchitecture.png > > > > > > > > > > > > > > > - Existing diagrams, in order to be modified, will have to be converted > > to > > > this format, there should be jiras for that > > > > > > Makes sense - I think I'll create those Jiras in lockstep with this > vote > > getting approval > > > > > > > 2.1 "New features and significant bug fixes should be documented in the > > > JIRA. Appropriate architecture diagrams should be created in > > > https://www.draw.io/ and committed “ > > > "New features and significant bug fixes should be documented in the > JIRA. > > > Appropriate architecture diagrams should be created in > > > https://www.draw.io/ and > > > committed. Diagrams may be requested of PR submitters during review > > either > > > as documentation or as an aid to the reviewer “ > > > > > > We could/should/can use the diagrams as > > > > > > - documentation > > > - simple aids for understanding PRs and communication ( Nick and I used > > > them for such yesterday to great effect to make sure we were on the > same > > > page ). > > > > > > I’m not sure we don’t want to have that blurb in there > > > > > > I'm happy to add this as well, +1 to that. > > > > > > > > > > On April 25, 2019 at 12:57:47, Michael Miklavcic ( > > > michael.miklav...@gmail.com) wrote: > > > > > > I'd like to propose a vote to change our dev guidelines which will > > clarify > > > the tooling we use to produce diagrams and share the source files for > > those > > > diagrams. The original discuss thread is noted at the end of this > email. > > I > > > propose the dev guidelines > > > > > > https://cwiki.apache.org/confluence/display/METRON/Development+Guidelines > > > and > > > PR checklist > > > > > > > > > > > > https://github.com/apache/metron/blob/master/.github/PULL_REQUEST_TEMPLATE.md#for-documentation-related-changes > > > be > > > changed in the following ways: > > > > > > 1. We specify that draw.io is the free tool of choice for sharing > > > diagrams in Metron and that the source files will be maintained/shared > in > > > source control. > > > 2. Under "1.1 Contributing A Code Change" > > > 1. Change "New features and significant bug fixes should be > > > documented in the JIRA and appropriate architecture diagrams should be > > > attached. Major features may require a vote." to "New features and > > > significant bug fixes should be documented in the JIRA. Appropriate > > > architecture diagrams should be created in https://www.draw.io/ > > > and committed > > > to source control with their XML source files and final rendered image. > > > Major features may require a vote." > > > 3. Under "2.4 Documentation" > > > 1. Add a new section with instructions entitled "Creating and Modifying > > > Diagrams". This section would provide basic instructions for > downloading > > > source files
Re: [VOTE] Update dev guidelines with format for sharing architecture source files and rendered images
When I say module, I mean at the root of any module, so each module could have it’s own diagrams. And the project root wold have diagrams for the ‘overall' On April 26, 2019 at 13:44:30, Michael Miklavcic ( michael.miklav...@gmail.com) wrote: The convention that seems to have been followed thus far has been to plop the images in the root of the module they're relevant to. Maybe relocating them to a central place would make it easier. The site-book image link rewriting might be simpler then as well. The only downside to this approach would be that the artifacts are split from their respective modules, but I honestly don't see that as a problem. On Fri, Apr 26, 2019, 11:40 AM Otto Fowler wrote: > On April 26, 2019 at 13:19:05, Michael Miklavcic ( > michael.miklav...@gmail.com) wrote: > > @otto when I get your responses to my Q's inline below I can post another > revision. > > On Thu, Apr 25, 2019 at 11:52 AM Otto Fowler > wrote: > > > - We need to specify the format I think, and then say that draw io is the > > tool for the format and not just specify the tool. > > > > Format for the source files, rendered files, or both? I believe their > source file format is a proprietary XML format. For rendered images, I > don't have a strong opinion and am happy to leave that up to the > implementer. If we want to be more opinionated, i.e. specify png, svg, > jpeg, etc. I could probably be persuaded. For the source file comment, > maybe it would help if I did the full write-up for 3.1 wrt instructions for > how to produce the diagrams and source files from draw.io. > > > I think what you say would be ok then, if draw io only has one source > format. > > I don’t care about the image format either, I’m surprised nobody has a > strong opinion about it. > > Do we want a standard place to put the diagrams? > > module/ > - diagrams/ > - foo.xml > - foo.png > - pr1234.xml > - pr1234.jpeg > - METRON-13244.xml > - METRON-13244.png > - EnrichementArchitecture.xml > - EnrichementArchitecture.png > > > > > > > > - Existing diagrams, in order to be modified, will have to be converted > to > > this format, there should be jiras for that > > > > Makes sense - I think I'll create those Jiras in lockstep with this vote > getting approval > > > > 2.1 "New features and significant bug fixes should be documented in the > > JIRA. Appropriate architecture diagrams should be created in > > https://www.draw.io/ and committed “ > > "New features and significant bug fixes should be documented in the JIRA. > > Appropriate architecture diagrams should be created in > > https://www.draw.io/ and > > committed. Diagrams may be requested of PR submitters during review > either > > as documentation or as an aid to the reviewer “ > > > > We could/should/can use the diagrams as > > > > - documentation > > - simple aids for understanding PRs and communication ( Nick and I used > > them for such yesterday to great effect to make sure we were on the same > > page ). > > > > I’m not sure we don’t want to have that blurb in there > > > > I'm happy to add this as well, +1 to that. > > > > > > On April 25, 2019 at 12:57:47, Michael Miklavcic ( > > michael.miklav...@gmail.com) wrote: > > > > I'd like to propose a vote to change our dev guidelines which will > clarify > > the tooling we use to produce diagrams and share the source files for > those > > diagrams. The original discuss thread is noted at the end of this email. > I > > propose the dev guidelines > > > https://cwiki.apache.org/confluence/display/METRON/Development+Guidelines > > and > > PR checklist > > > > > > https://github.com/apache/metron/blob/master/.github/PULL_REQUEST_TEMPLATE.md#for-documentation-related-changes > > be > > changed in the following ways: > > > > 1. We specify that draw.io is the free tool of choice for sharing > > diagrams in Metron and that the source files will be maintained/shared in > > source control. > > 2. Under "1.1 Contributing A Code Change" > > 1. Change "New features and significant bug fixes should be > > documented in the JIRA and appropriate architecture diagrams should be > > attached. Major features may require a vote." to "New features and > > significant bug fixes should be documented in the JIRA. Appropriate > > architecture diagrams should be created in https://www.draw.io/ > > and committed > > to source control with their XML source files and final rendered image. > > Major features may require a vote." > > 3. Under "2.4 Documentation" > > 1. Add a new section with instructions entitled "Creating and Modifying > > Diagrams". This section would provide basic instructions for downloading > > source files from draw.io. > > 4. Add a new checkbox item under PR checklist heading "For documentation > > related changes" with the following text > > 1. Have you ensured that any documentation diagrams have been > > updated, along with their source files, using draw.io? See > > > https://cwiki.apache.org/confluence/display/METRON/Development+Guidelines > >
Re: [VOTE] Update dev guidelines with format for sharing architecture source files and rendered images
The convention that seems to have been followed thus far has been to plop the images in the root of the module they're relevant to. Maybe relocating them to a central place would make it easier. The site-book image link rewriting might be simpler then as well. The only downside to this approach would be that the artifacts are split from their respective modules, but I honestly don't see that as a problem. On Fri, Apr 26, 2019, 11:40 AM Otto Fowler wrote: > On April 26, 2019 at 13:19:05, Michael Miklavcic ( > michael.miklav...@gmail.com) wrote: > > @otto when I get your responses to my Q's inline below I can post another > revision. > > On Thu, Apr 25, 2019 at 11:52 AM Otto Fowler > wrote: > > > - We need to specify the format I think, and then say that draw io is the > > tool for the format and not just specify the tool. > > > > Format for the source files, rendered files, or both? I believe their > source file format is a proprietary XML format. For rendered images, I > don't have a strong opinion and am happy to leave that up to the > implementer. If we want to be more opinionated, i.e. specify png, svg, > jpeg, etc. I could probably be persuaded. For the source file comment, > maybe it would help if I did the full write-up for 3.1 wrt instructions for > how to produce the diagrams and source files from draw.io. > > > I think what you say would be ok then, if draw io only has one source > format. > > I don’t care about the image format either, I’m surprised nobody has a > strong opinion about it. > > Do we want a standard place to put the diagrams? > > module/ > - diagrams/ > - foo.xml > - foo.png > - pr1234.xml > - pr1234.jpeg > - METRON-13244.xml > - METRON-13244.png > - EnrichementArchitecture.xml > - EnrichementArchitecture.png > > > > > > > > - Existing diagrams, in order to be modified, will have to be converted > to > > this format, there should be jiras for that > > > > Makes sense - I think I'll create those Jiras in lockstep with this vote > getting approval > > > > 2.1 "New features and significant bug fixes should be documented in the > > JIRA. Appropriate architecture diagrams should be created in > > https://www.draw.io/ and committed “ > > "New features and significant bug fixes should be documented in the JIRA. > > Appropriate architecture diagrams should be created in > > https://www.draw.io/ and > > committed. Diagrams may be requested of PR submitters during review > either > > as documentation or as an aid to the reviewer “ > > > > We could/should/can use the diagrams as > > > > - documentation > > - simple aids for understanding PRs and communication ( Nick and I used > > them for such yesterday to great effect to make sure we were on the same > > page ). > > > > I’m not sure we don’t want to have that blurb in there > > > > I'm happy to add this as well, +1 to that. > > > > > > On April 25, 2019 at 12:57:47, Michael Miklavcic ( > > michael.miklav...@gmail.com) wrote: > > > > I'd like to propose a vote to change our dev guidelines which will > clarify > > the tooling we use to produce diagrams and share the source files for > those > > diagrams. The original discuss thread is noted at the end of this email. > I > > propose the dev guidelines > > > https://cwiki.apache.org/confluence/display/METRON/Development+Guidelines > > and > > PR checklist > > > > > > https://github.com/apache/metron/blob/master/.github/PULL_REQUEST_TEMPLATE.md#for-documentation-related-changes > > be > > changed in the following ways: > > > > 1. We specify that draw.io is the free tool of choice for sharing > > diagrams in Metron and that the source files will be maintained/shared in > > source control. > > 2. Under "1.1 Contributing A Code Change" > > 1. Change "New features and significant bug fixes should be > > documented in the JIRA and appropriate architecture diagrams should be > > attached. Major features may require a vote." to "New features and > > significant bug fixes should be documented in the JIRA. Appropriate > > architecture diagrams should be created in https://www.draw.io/ > > and committed > > to source control with their XML source files and final rendered image. > > Major features may require a vote." > > 3. Under "2.4 Documentation" > > 1. Add a new section with instructions entitled "Creating and Modifying > > Diagrams". This section would provide basic instructions for downloading > > source files from draw.io. > > 4. Add a new checkbox item under PR checklist heading "For documentation > > related changes" with the following text > > 1. Have you ensured that any documentation diagrams have been > > updated, along with their source files, using draw.io? See > > > https://cwiki.apache.org/confluence/display/METRON/Development+Guidelines > > for > > instructions. > > > > We require a minimum of 72 hours for a vote, not typically including > > weekend days. I'd like to leave this vote open until Tuesday, 12PM > > EDT. Please vote +1, -1, or 0 to abstain, and also indicate if your vote
Re: [VOTE] Metron Release Candidate 0.7.1-RC1
Curious Anand, are your steps for bringing up an open stack cluster something we could script like the AWS stuff? On April 26, 2019 at 09:35:29, Anand Subramanian ( asubraman...@hortonworks.com) wrote: +1 (non-binding) * Built RPMs and mpacks. * Brought up Metron stack on 12-node CentOS 7 openstack cluster. * Ran sensor-stubs and validated events in the Alerts UI for the default sensors. * Management UI, Alerts UI and Swagger UI sanity check Regards, Anand On 4/26/19, 5:18 AM, "Nick Allen" wrote: +1 Verified release with all documented steps and ran up Full Dev. On Thu, Apr 25, 2019 at 6:10 PM Michael Miklavcic < michael.miklav...@gmail.com> wrote: > Ok cool, just finished the validation and updated the steps in the doc to > reflect the current code base. > > On Thu, Apr 25, 2019 at 3:45 PM Nick Allen wrote: > > > No voting required. Those are just docs. Whoever is willing to correct > > and has access, should be able to. Good catch. > > > > On Thu, Apr 25, 2019 at 4:32 PM Michael Miklavcic < > > michael.miklav...@gmail.com> wrote: > > > > > We're also not "incubator-metron" any longer. Do we require any kind of > > > voting or +1 on that verification page to make corrections to it? > > > > > > On Thu, Apr 25, 2019 at 2:29 PM Michael Miklavcic < > > > michael.miklav...@gmail.com> wrote: > > > > > > > fyi, the steps in this doc have changed slightly per this naming > > > > convention change as well - > > > > https://cwiki.apache.org/confluence/display/METRON/Verifying+Builds. > > > > > > > > > > > > > > > > On Thu, Apr 25, 2019 at 1:25 PM Justin Leet > > > wrote: > > > > > > > >> For everyone taking the time to validate and vote on the RC, there > is > > a > > > >> caveat. The naming conventions for the two repos are now aligned > > > >> (_, instead of being '-' in the main repo and > '_' > > in > > > >> the plugin repo) along with the location of the KEYS file, I have a > PR > > > out > > > >> to update the metron-rc-check script ( > > > >> https://github.com/apache/metron/pull/1394). > > > >> > > > >> This accounts for both of these changes, and should allow the script > > to > > > be > > > >> run normally. > > > >> > > > >> On Thu, Apr 25, 2019 at 3:22 PM Justin Leet > > > >> wrote: > > > >> > > > >> > This is a call to vote on releasing Apache Metron 0.7.1 > > > >> > > > > >> > Full list of changes in this release: > > > >> > https://dist.apache.org/repos/dist/dev/metron/0.7.1-RC1/CHANGES > > > >> > The tag to be voted upon is: > > > >> > apache-metron_0.7.1-rc1 > > > >> > > > > >> > The source archives being voted upon can be found here: > > > >> > > > > >> > > > > >> > > > > > > https://dist.apache.org/repos/dist/dev/metron/0.7.1-RC1/apache-metron_0.7.1-rc1.tar.gz > > > >> > > > > >> > Other release files, signatures and digests can be found here: > > > >> > https://dist.apache.org/repos/dist/dev/metron/0.7.1-RC1/ > > > >> > > > > >> > The release artifacts are signed with the following key: > > > >> > https://dist.apache.org/repos/dist/release/metron/KEYS > > > >> > Please vote on releasing this package as Apache Metron 0.7.1-RC1 > > > >> > > > > >> > When voting, please list the actions taken to verify the release. > > > >> > > > > >> > Recommended build validation and verification instructions are > > posted > > > >> > here: > > > >> > > https://cwiki.apache.org/confluence/display/METRON/Verifying+Builds > > > >> > > > > >> > This vote will be open for until 4pm EDT on Tuesday April 30 2019, > > to > > > >> > account for the weekend.. > > > >> > > > > >> > [ ] +1 Release this package as Apache Metron 0.7.1-RC1 > > > >> > > > > >> > [ ] 0 No opinion > > > >> > > > > >> > [ ] -1 Do not release this package because... > > > >> > > > > >> > > > > > > > > > >
