Re: [VOTE] Release Apache Flagon UserALEjs 2.4.0

[Austin Bennett]

+1 ... LGTM.

@j...@apache.org  good catches.

@ALL -- Which of the release steps do we think could be more automated and
less manual?  Yes, we still will have manual steps, but it might be worth
investing in some repeatable scripts.  For those that have done
more thorough releases and/or validation, have you thought about what is
missing?  What could make your life easier?  If yes, let's at least writeup
some tickets for future work.


nit: i'd like to see which RC we are voting on in the subject line.

On Sat, Mar 30, 2024 at 2:29 PM Joshua Poore  wrote:

> BUMP
>
> Hi All,
>
> Don’t forget to VOTE for this release!
>
> > On Mar 25, 2024, at 10:17 PM, Joshua Poore  wrote:
> >
> > +1 from me
> >
> > Great work everyone! Acceptable release.
> >
> > we only need 1 more binding VOTE for a release!
> >
> >
> > [Y] Build and Unit Tests Pass
> > [Y] Integration Tests Pass
> > [Y] Signatures and Hashes Match Keys
> > [Y] LICENSE, and NOTICE Files in Source and Binary Release Packages
> > [Y] LICENSE, and NOTICE are consistent with ASF and Incubator Policy
> > [Y] CHANGELOG included with release distribution
> > [Y] All Source Files Have Correct ASF Headers
> > [Y] No Binary Files in Source Release Packages
> >
> >> On Mar 24, 2024, at 9:47 PM, Amir Ghaemi  wrote:
> >>
> >> Thank you both!
> >>
> >> +1 from me!
> >>
> >> [✓] Build and Unit Tests Pass
> >> [ ] Integration Tests Pass
> >> [ ] Signatures and Hashes Match Keys
> >> [✓] DISCLAIMER, LICENSE, and NOTICE Files in Source and Binary Release
> >> Packages
> >> [✓] DISCLAIMER, LICENSE, and NOTICE are consistent with ASF and
> Incubator
> >> Policy
> >> [✓] CHANGELOG included with release distribution
> >> [✓] All Source Files Have Correct ASF Headers
> >> [ ] No Binary Files in Source Release Packages
> >>
> >>
> >> Best,
> >> *Amir M. Ghaemi*
> >>
> >>
> >> On Sun, Mar 24, 2024 at 1:14 PM Jason Young  wrote:
> >>
> >>> +1 from me now, and thanks for updating the release script.
> >>>
>  [Y] Build and Unit Tests Pass
>  [Y] Integration Tests Pass
>  [Y] Signatures and Hashes Match Keys
>  [Y] LICENSE, and NOTICE Files in Source and Binary Release Packages
>  [Y] LICENSE, and NOTICE are consistent with ASF and Incubator Policy
>  [Y] CHANGELOG included with release distribution
>  [Y] All Source Files Have Correct ASF Headers
>  [Y] No Binary Files in Source Release Packages
> >>>
> >>> -Jason
> >>>
> >>> On 2024/03/23 19:30:10 Evan Jones wrote:
>  All,
> 
>  I've fixed up the release candidate. Given the commit head and source
> >>> code
>  haven't changed, I've decided to update the RC in place on the apache
>  dist/dev repo and will keep the voting open on this thread to avoid
>  spamming your inboxes.
> 
>  Fixes:
>  1. The release script in the flagon repo claimed to run git clean
> -dxf,
> >>> but
>  this was actually commented out. I've fixed this in the script.
>  2. I indeed was signing with a different default key. This has been
> >>> fixed.
>  However, please note, your verification call was incorrect. You must
> do a
>  one-one mapping between the signatures and their constituent files.
> For
>  unix systems, the one-liner below does this:
>  for a in *.tar.gz *.zip; do gpg2 --verify ${a}.asc ${a}; done
>  3. I updated the script to use sha512sum. This should ameliorate your
>  issues, Jason.
> 
>  Please re-assess the candidate and get your votes in. We'll extend
> voting
>  by another 72 hours.
> 
>  Best
> 
>  Evan Jones
>  Website: www.ea-jones.com
> 
> 
>  On Sat, Mar 23, 2024 at 10:08 AM Evan Jones 
> >>> wrote:
> 
> > Thanks, Jason.
> >
> > 1. This is odd. I used the script. And explicitly recall it asking
> >>> about
> > git clean.
> >
> > 2. I was worried about this. I have multiple keys.
> >
> > 3. I'll update the script to use sha512sum.
> >
> > Will re-roll later.
> >
> > Best
> >
> > Evan Jones
> > Website: www.ea-jones.com
> >
> >
> > On Sat, Mar 23, 2024 at 9:55 AM Jason Young  wrote:
> >
> >> -1 from me
> >>
> >> 1. (blocking) Source artifacts should contain only files tracked by
> >>> git
> >> but there are build files, log files, and .vscode. The
> >> make-release-artifacts.sh script should do this, so maybe this is an
> >>> issue
> >> with the script. Otherwise you can remove these files with `git
> clean
> >>> -dxf`
> >>
> >> 2. (blocking)  I cannot verify the signatures, I am running:
> >> gpg --import KEYS
> >> gpg --verify *.asc
> >>
> >> gpg is using RSA key 1750ADB4640DCF780D97CE2FDC659A327EC07063 to
> >>> verify,
> >> which I'm guessing is a different GPG key on your machine
> >>
> >> 3. (non-blocking) When I check the hashes with shasum it throws "no
> >> properly formatted SHA checksum lines found". I recalculated and
> >>> compared
> 

Re: [RFC] Consolidation of Apache Flagon Projects into a Monorepo Structure

[Austin Bennett]

On: ASF Admin's don't understand project health due to repo structure --
i disagree with the idea that itshould at all inform/dictate how work gets
structured and completed by the Flagon project.

I am not sure I understand how documentation improves by having a
monorepo.  I guess if pitched about a single README section.  Open Source
projects commonly have docs that get autogenerated and published to a
webpage, and can be done so from a number of disparate repos to a single
location.

Off handed, it seems just as straightforward to invest in the ability to "treat
a number of highly inter-related projects as" coupled, than to refactor
repos and invest in alternative testing infra. Either way, the problem
outlined appears actually to surface the urgency for increasingly robust
CI?

The rest is docs and education, which can be handled in a number of ways.

I don't buy the necessity of a monorepo, but *I accept the preferences of
those that will choose to do the work*. Wondering: has anyone done the
equivalent planning work to actually surface a pros/cons; ex: what would
the tooling need to look like to address the problems and maintain the
current repo structure?

On Tue, Jan 30, 2024 at 2:18 PM Joshua Poore  wrote:

> The idea is growing on me—I’m pretty sure we can generate Pypi and NPM
> releases from the same repo, different folders.
>
> Agree that now is the time to do it before user base on Distill grows.
>
> I do think we should run a consensus/community VOTE on this. Let me
> refresh myself on which ruleset we should use for this. It’s a big change,
> so may need to fall under the same guidelines as RELEASE.
>
> Josh
>
> > On Jan 30, 2024, at 4:05 PM, Evan Jones  wrote:
> >
> > *When should this process begin? *In terms of where UserALE and currently
> > are.**
> > I want to get all *non-breaking* PRs merged into UserALE/test and
> > Distill/main and then do a new release of each of them, assuming there
> are
> > changes to release. UserALE has been queued up for a 2.4.0 for quite some
> > time. I don't think we have anything new for Distill. That way the
> monorepo
> > consolidation would happen on top of clean releases.
> >
> > I want to start the monorepo migration ASAP which means getting these
> > releases in progress ASAP.
> >
> > *The scope and sequence of the changes? Roadmap for the migration?*
> > If by scope you mean what aspects of the code base does this touch and
> > who's impacted, then the answer to the former is all aspects -- albeit
> > purely in a structural way -- and the answer to the latter is
> > contributors/devs only. Nothing about our individual projects will change
> > to start except they'll all be moved into the Flagon repo as
> > sub-directories. Within those directories, everything will be identical
> to
> > how they are currently. The only real repo that will see changes is the
> > Flagon repo.
> >
> > Because of this consolidation, the way developers contribute to the
> > projects will change. People will fork the Flagon Suite repo and merge
> back
> > into it regardless of the flagon product (distill, userale) they're
> > contributing to. Each project will still be released the same way.
> >
> > On the ASF side, we would have a single release process for the entire
> > Flagon project, rather than different releases for different
> sub-projects.
> > My hope is this vastly lowers overhead.
> >
> > The steps proposed above are the roadmap, more or less. As far as
> timeline
> > goes, I think the biggest bottleneck will be getting the current releases
> > out. I believe I can do the consolidation into a single repo in one
> weekend.
> >
> > *For documentation, do we intend to use ReadTheDocs and Sphinx? Any
> others
> > that you might know of?*
> >
> > All documentation and website files would be stored in a single directory
> > in the repo. It sits alongside userale, distill, etc. The API
> documentation
> > for each project should leverage automated doc generators:
> >
> >   - Distill = Sphinx + PyDoc --> ReadTheDocs
> >   - UserALE = Sphinx + JsDoc --> ReadTheDocs
> >
> > The main flagon website should be the primary source of documentation for
> > things like tutorials, getting started, concept definitions, etc. It can
> > then point to the ReadTheDocs pages for each of packages' API documents.
> >
> > The overhauling of the documentation is not really couple to the monorepo
> > migration, though. The monorepo migration merely lowers to burden of the
> > workflow I describe above by centralizing everything.
> >
> > *I think we should set up a robust CI/CD pipeline to handle the monorepo
> to
> > ensure that all projects are integrated seamlessly and that automated
> tests
> > are in place for the monorepo.*
> >
> > Yes.
> >
> > Best
> >
> > Evan Jones
> > Website: www.ea-jones.com
> >
> >
> > On Tue, Jan 30, 2024 at 2:21 PM Amir Ghaemi  wrote:
> >
> >> Hi Evan,
> >>
> >> I support this monorepo structure - as you stated, there are
> >> several benefits of 

Re: Service account

[Austin Bennett]

This would be worth asking ASF Infra.  I would hope that's something that
could be largely automated, though - if memory serves - we need a human to
choose to perform [ ex: trigger ]  the release.

That also invites how authentication is happening -- definitely I prefer
short-lived credentials, but unclear whether ASF has some sort of OIDC
provider [ ex:
https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect
]

On Mon, Oct 30, 2023 at 11:19 AM proton_mail_bridge
 wrote:

> I’m working on automating some tasks for the release process. Does anybody
> know if we can get an apache service account such that a GitHub action can
> post builds to https://dist.apache.org/, or is that something that only a
> human can do? And if so, could such a service account be used for dev/,
> release/, and test/?
>
> - Jason

Re: [VOTE] Release Apache Flagon Distill 0.1.0

[Austin Bennett]

Missed who was PMC/not [ thanks for counting @
jason_...@protonmail.com.invalid  If others not able, I should be able to
find a little time to dig in later this week; roll-call also made it sound
like there were a few others active, so must imagine we can get the
requisite VOTEs.



On Fri, Oct 20, 2023 at 7:49 AM proton_mail_bridge
 wrote:

> Let me add my +1. And while we have 4 yes votes, only  2 are binding. So
> one additional PMC yes vote is still required.
>
> Apache Phone Book <https://people.apache.org/phonebook.html?pmc=flagon>
> people.apache.org <https://people.apache.org/phonebook.html?pmc=flagon>
> [image: favicon.ico] <https://people.apache.org/phonebook.html?pmc=flagon>
> <https://people.apache.org/phonebook.html?pmc=flagon>
>
>
> - Jason
>
> On Oct 18, 2023, at 2:55 PM, Austin Bennett  wrote:
>
> Great, thanks, congratulations -- I haven't dug in, yet, but sufficient
> votes are in!  Naturally, gotta wait the 72 hours, but seems the release
> likely to go out!
>
> On Wed, Oct 18, 2023 at 11:42 AM Amir Ghaemi  wrote:
>
> Hi all,
>
> +1
> Great work!
>
> [✓] Build and Unit Tests Pass (On Windows - Python 3.10)
> [✓] DISCLAIMER, LICENSE, and NOTICE Files in Source and Binary Release
> Packages
> [✓] DISCLAIMER, LICENSE, and NOTICE are consistent with ASF and Incubator
> Policy
> [✓] All Source Files Have Correct ASF Headers
> [ ] No Binary Files in Source Release Packages
> [ ] Signatures and Hashes Match Keys
> [ ] CHANGELOG included with release distribution
>
> Best,
> *Amir M. Ghaemi*
>
>
>

Re: Roll-Call for Apache Flagon

[Austin Bennett]

What's the plan?

On Sat, Oct 21, 2023, 10:39 AM lewis john mcgibbney 
wrote:

> I’m here.
> lewismc
>
> On Sat, Oct 21, 2023 at 08:28 Christofer Dutz 
> wrote:
>
>> Hi all,
>>
>>
>>
>> I was tasked at the last board report to pursue a roll call for Apache
>> Flagon after we saw that a VOTE thread has currently been open for over 2
>> weeks with only one vote (which was “-0”).
>>
>> Also seeing that only 2 people have done any commits in the last few
>> months feels rather strange for a project that has been a TLP for only 7
>> months now.
>>
>>
>>
>>
>> Please reply to this thread if you’re still willing and able to
>> contribute to this project.
>>
>>
>>
>> Thanks,
>>
>>  Chris
>>
>

Re: [VOTE] Release Apache Flagon Distill 0.1.0

[Austin Bennett]

Great, thanks, congratulations -- I haven't dug in, yet, but sufficient
votes are in!  Naturally, gotta wait the 72 hours, but seems the release
likely to go out!

On Wed, Oct 18, 2023 at 11:42 AM Amir Ghaemi  wrote:

> Hi all,
>
> +1
> Great work!
>
> [✓] Build and Unit Tests Pass (On Windows - Python 3.10)
> [✓] DISCLAIMER, LICENSE, and NOTICE Files in Source and Binary Release
> Packages
> [✓] DISCLAIMER, LICENSE, and NOTICE are consistent with ASF and Incubator
> Policy
> [✓] All Source Files Have Correct ASF Headers
> [ ] No Binary Files in Source Release Packages
> [ ] Signatures and Hashes Match Keys
> [ ] CHANGELOG included with release distribution
>
> Best,
> *Amir M. Ghaemi*
>

Re: [DISCUSS] Flagon UserALE.js Release

[Austin Bennett]

Generally, I'd imagine minor releases.  Unless breaking changes.  So,
sounds like this suffices.

Time to dig into our release process and testing.  Specifically, wondering
what all additionally will people potentially do manually - since would
want to work towards systematizing and automating.

On Wed, Jul 19, 2023 at 10:00 AM Joshua Poore  wrote:

> Hi All,
>
> It’s high-time we do a UserALE.js release. We’ve had some great community
> contributions and we should update packages through Apache and NPM distro
> for security reasons.
>
> Given some of the adds to UserALE.js since last release. Given we have
> substantive new features, but those features don’t include “breaking
> changes”, I recommend that we do a MINOR release. This would advance
> UserALE.js versioning from 2.3.0 —>  2.4.0.
>
> Before moving on this plan, I’d like to give the community 72 hours to
> discuss. In the interim, I’ll begin working on an “RC” branch.
>
> -J

Re: Notifications@ ?

[Austin Bennett]

Awesome, thanks Josh!

On Fri, Jun 16, 2023, 2:18 AM Joshua Poore  wrote:

> OK! Did it!
>
> This works now. See schema here:
> https://github.com/apache/flagon-useralejs/blob/master/.asf.yaml
>
> I haven’t tested PRs, or dependabots, however, issue updates are now going
> to notificati...@flagon.apache.org <mailto:notificati...@flagon.apache.org>
> and NOT to dev
>
> I’ve implemented the schema @ master for both apache/flagon and
> apache/flagon-useralejs (i’ll get it into distill at a later date)
>
> New lists are active (of course):
>
> p...@flagon.apache.org <mailto:p...@flagon.apache.org>
> notificati...@flagon.apache.org <mailto:p...@flagon.apache.org>
> maintena...@flagon.apache.org <mailto:p...@flagon.apache.org>
>
> to subscribe:
>
> Send email to [list]-subscr...@flagon.apache.org  subscr...@flagon.apache.org> (ex: pr-subscr...@flagon.apache.org  pr-subscr...@flagon.apache.org>)
>
> or
>
> If you are a committer, use your LDAP to use the subscription management
> tool on Whimsey:
>
>
> https://whimsy.apache.org/committers/subscribe
>
> PS I also implemented GitHub wikis via asf.yaml just for fun. Was thinking
> about putting in release procs. there at minimum.
>
> We saved dev!
>
> -J
>
> > On Jun 15, 2023, at 9:56 PM, Austin Bennett  wrote:
> >
> > Sounds great - thanks for digging into getting this cleaned up!
> >
> > On Wed, Jun 14, 2023 at 9:06 PM Joshua Poore  wrote:
> >
> >> from:
> >>
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA=git+-+.asf.yaml+features
> >>
> >> The hierarchy for determining the email target for an action is:
> >> If a specific status or comment target is specified, use that
> >> otherwise, if a global issue/pull request target exists, use that
> >> otherwise, fall back to the targets that were configured when the
> >> repository was set up
> >> finally, fall back to dev@project for issues/PRs and commits@ for
> commits
> >>
> >> feeling optimistic this works when new lists are up and running.
> >>
> >>
> >>> On Jun 14, 2023, at 11:58 PM, Joshua Poore  wrote:
> >>>
> >>> Well,
> >>>
> >>> Requested 3 new lists:
> >>>
> >>> 1. PR
> >>> 2. Maintenance
> >>> 3. Notifications
> >>>
> >>> These are now in process.
> >>>
> >>> Pushed new asf.yaml to Apache/Flagon repo:
> >> https://github.com/apache/flagon/blob/master/.asf.yaml
> >>>
> >>> Commits are going to where they should (commits). However, new issues,
> >> issue updates are still going to dev@ (I am seeing mods to the titles
> >> consistent with asf.yaml). I’ll run another test when the new lists are
> >> active. It could require some more experimentation.
> >>>
> >>> Bear with us @dev… We’ll get it.
> >>>
> >>>> On Jun 14, 2023, at 11:16 PM, Joshua Poore 
> wrote:
> >>>>
> >>>> OK, I have requested the Notifications list. I’ll push subscribe
> >> details out when it’s available (approx 24hrs).
> >>>>
> >>>> Going to experiment with asf.yaml mods on apache/flagon repo next.
> >>>>
> >>>>> On Jun 14, 2023, at 12:03 AM, Austin Bennett 
> >> wrote:
> >>>>>
> >>>>> +1
> >>>>>
> >>>>> The reply-to functionality works out the box via GH notification
> >> emails to individual accounts.  I like the thought of adding that as
> ASF,
> >> but need to explore whether worth the hassle of piping through ASF Infra
> >> [and the associated downsides that were raised like messy messages from
> >> things like email signatures in replies].
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Jun 13, 2023, 9:12 PM Joshua Poore  >> <mailto:poor...@apache.org>> wrote:
> >>>>>> Hey Austin,
> >>>>>>
> >>>>>> This is looking an awful like the other thread on dev:
> >> https://lists.apache.org/thread/5374nqhndp46fmv0hzdjp9b6s6v833bj
> >>>>>>
> >>>>>> This all involves add additional email lists and then pipeline
> >> Github/Gitbox notifications through to different lists.
> >>>>>>
> >>>>>> My original proposal:
> >>>>>>
> >>>>>>

Re: Notifications@ ?

[Austin Bennett]

Sounds great - thanks for digging into getting this cleaned up!

On Wed, Jun 14, 2023 at 9:06 PM Joshua Poore  wrote:

> from:
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA=git+-+.asf.yaml+features
>
> The hierarchy for determining the email target for an action is:
> If a specific status or comment target is specified, use that
> otherwise, if a global issue/pull request target exists, use that
> otherwise, fall back to the targets that were configured when the
> repository was set up
> finally, fall back to dev@project for issues/PRs and commits@ for commits
>
> feeling optimistic this works when new lists are up and running.
>
>
> > On Jun 14, 2023, at 11:58 PM, Joshua Poore  wrote:
> >
> > Well,
> >
> > Requested 3 new lists:
> >
> > 1. PR
> > 2. Maintenance
> > 3. Notifications
> >
> > These are now in process.
> >
> > Pushed new asf.yaml to Apache/Flagon repo:
> https://github.com/apache/flagon/blob/master/.asf.yaml
> >
> > Commits are going to where they should (commits). However, new issues,
> issue updates are still going to dev@ (I am seeing mods to the titles
> consistent with asf.yaml). I’ll run another test when the new lists are
> active. It could require some more experimentation.
> >
> > Bear with us @dev… We’ll get it.
> >
> >> On Jun 14, 2023, at 11:16 PM, Joshua Poore  wrote:
> >>
> >> OK, I have requested the Notifications list. I’ll push subscribe
> details out when it’s available (approx 24hrs).
> >>
> >> Going to experiment with asf.yaml mods on apache/flagon repo next.
> >>
> >>> On Jun 14, 2023, at 12:03 AM, Austin Bennett 
> wrote:
> >>>
> >>> +1
> >>>
> >>> The reply-to functionality works out the box via GH notification
> emails to individual accounts.  I like the thought of adding that as ASF,
> but need to explore whether worth the hassle of piping through ASF Infra
> [and the associated downsides that were raised like messy messages from
> things like email signatures in replies].
> >>>
> >>>
> >>>
> >>>
> >>> On Tue, Jun 13, 2023, 9:12 PM Joshua Poore  <mailto:poor...@apache.org>> wrote:
> >>>> Hey Austin,
> >>>>
> >>>> This is looking an awful like the other thread on dev:
> https://lists.apache.org/thread/5374nqhndp46fmv0hzdjp9b6s6v833bj
> >>>>
> >>>> This all involves add additional email lists and then pipeline
> Github/Gitbox notifications through to different lists.
> >>>>
> >>>> My original proposal:
> >>>>
> >>>> 1)  to open a ‘maintenance’ list for flagon and pipe dependabot
> alerts there suppress from dev
> >>>> 2)  to open a ‘PR’ list for flagon and pipe PR notifications through
> there.
> >>>> 3) commits will stay on the ‘commits’ thread.
> >>>> 4) pipe GitHub discussions and Issue mods through to ‘dev’
> >>>>
> >>>> How about we push GitHub Discussions and Issues through a
> “Notifications” list (would be good to keep that to human traffic and not
> dependably traffic), as you propose in lieu of [4] above. I love your idea
> for a “reply to” functionality.
> >>>>
> >>>> If that works for you, I’ll request the additional threads and we can
> start experimenting with modifying our .asf.yaml files given the example
> below:
> >>>>
> >>>>
> >>>> plc4x/.asf.yaml at e14a3d7dc8bae8ead824f019d5e87767c4460adc ·
> apache/plc4x
> >>>> github.com
> >>>> <
> https://github.com/apache/plc4x/blob/e14a3d7dc8bae8ead824f019d5e87767c4460adc/.asf.yaml#L61>plc4x/.asf.yaml
> at e14a3d7dc8bae8ead824f019d5e87767c4460adc · apache/plc4x <
> https://github.com/apache/plc4x/blob/e14a3d7dc8bae8ead824f019d5e87767c4460adc/.asf.yaml#L61
> >
> >>>> github.com <
> https://github.com/apache/plc4x/blob/e14a3d7dc8bae8ead824f019d5e87767c4460adc/.asf.yaml#L61
> >
> >>>>
> >>>> Did I miss anything?
> >>>>
> >>>> Josh
> >>>>
> >>>>> On Jun 11, 2023, at 9:54 PM, Austin Bennett  <mailto:aus...@apache.org>> wrote:
> >>>>>
> >>>>> Hi Flagon Dev,
> >>>>>
> >>>>> How do we feel about using a notifications@ list, so that not
> everything is
> >>>>> piped to dev@?  That is one option mentioned from @
> ctubb...@apache.org <mailto:ctubb

Re: Nix ?

[Austin Bennett]

I'll focus on some lessons learned getting this into some other open source
projects, and can then use that to inform onboarding here [ if interested
].  Should anyone be interested do feel free to reachout to collab, and/or
comment on https://github.com/apache/flagon/issues/34

On Tue, Jun 13, 2023, 9:00 PM Joshua Poore  wrote:

> Regretfully, I’m not. wish I could be more helpful.
>
> > On Jun 11, 2023, at 6:33 PM, Austin Bennett  wrote:
> >
> > Hi Flagon Devs,
> >
> > Is anyone else familiar with Nix?   ( if we had shell configs, would
> those
> > be used/enjoyed by anyone else? )
> >
> > If not at all of interest to anyone else, that makes it less interesting
> to
> > create - the benefit I get from those is via collab.
> >
> > Curious your thoughts,
> > Thanks,
> > Austin
> >
> >
> > Ex:
> > * https://nix.dev/
>
>

Re: Notifications@ ?

[Austin Bennett]

+1

The reply-to functionality works out the box via GH notification emails to
individual accounts.  I like the thought of adding that as ASF, but need to
explore whether worth the hassle of piping through ASF Infra [and the
associated downsides that were raised like messy messages from things like
email signatures in replies].




On Tue, Jun 13, 2023, 9:12 PM Joshua Poore  wrote:

> Hey Austin,
>
> This is looking an awful like the other thread on dev:
> https://lists.apache.org/thread/5374nqhndp46fmv0hzdjp9b6s6v833bj
>
> This all involves add additional email lists and then pipeline
> Github/Gitbox notifications through to different lists.
>
> My original proposal:
>
> 1)  to open a ‘maintenance’ list for flagon and pipe dependabot alerts
> there suppress from dev
> 2)  to open a ‘PR’ list for flagon and pipe PR notifications through
> there.
> 3) commits will stay on the ‘commits’ thread.
> 4) pipe GitHub discussions and Issue mods through to ‘dev’
>
> How about we push GitHub Discussions and Issues through a “Notifications”
> list (would be good to keep that to human traffic and not dependably
> traffic), as you propose in lieu of [4] above. I love your idea for a
> “reply to” functionality.
>
> If that works for you, I’ll request the additional threads and we can
> start experimenting with modifying our .asf.yaml files given the example
> below:
>
> [image: plc4x.png]
>
> plc4x/.asf.yaml at e14a3d7dc8bae8ead824f019d5e87767c4460adc · apache/plc4x
> <https://github.com/apache/plc4x/blob/e14a3d7dc8bae8ead824f019d5e87767c4460adc/.asf.yaml#L61>
> github.com
> <https://github.com/apache/plc4x/blob/e14a3d7dc8bae8ead824f019d5e87767c4460adc/.asf.yaml#L61>
>
> <https://github.com/apache/plc4x/blob/e14a3d7dc8bae8ead824f019d5e87767c4460adc/.asf.yaml#L61>
>
>
> Did I miss anything?
>
> Josh
>
> On Jun 11, 2023, at 9:54 PM, Austin Bennett  wrote:
>
> Hi Flagon Dev,
>
> How do we feel about using a notifications@ list, so that not everything
> is
> piped to dev@?  That is one option mentioned from @ctubb...@apache.org
>  ( below ).
>
> That seems vastly preferable for people involved in issue/PR discussions to
> not receive duplicate messages.
>
> Related: if Infra is amenable, I am also willing to explore extending the
> functionality to be able to reply from email [ sent to list ] to get it
> back to GH, that's a very nice feature of the messages coming from GH.
>
> Interested to hear your thoughts.  If there is
> consensus/sufficient-support, I'll be happy to update .asf.yaml, and deal
> with creating that list [ I'm not sure whether I can move forward via lazy
> consensus if not hearing from people ].
>
> Thanks,
> Austin
>
>
> -- Forwarded message -
> From: Christopher 
> Date: Sun, Jun 11, 2023 at 6:11 PM
> Subject: Re: How to NOT receive GH traffic on devlist, for things my GH
> user is apart of?
> To: Austin Bennett 
> Cc: , 
>
>
> You'd really have to try to convince your project to configure their
> .asf.yaml file to send their GH notifications to a secondary list
> (like notifications@) which you can simply unsubscribe from, so you
> don't get duplicates from both GH and via the mailing list. That way
> users can choose to opt-in to the notifications@ list in addition to
> the dev@ list, at their choice. Some projects do this, while others
> are much more resistant to the idea, and would prefer you just
> configure your mail client to filter things out manually.
>
> On Sun, Jun 11, 2023 at 6:40 PM Austin Bennett  wrote:
>
>
> Hi Infra Users,
>
> The Flagon project currently receives GH notifications to the dev list.
>
> I'd prefer to not receive emails for Issues/Comments I am already
> participating in [ as it otherwise feels like spam ], is there a way to
> customize this so it does not get sent to me?  I write here since in the
> bottom of email to flagon's dev list as forwarded from GH it suggested to
> contact us...@infra.apache.org
>
>
> A related feature request [ maybe better for a different email?]:
> * When GH sends me notifications directly, I can reply to the issue/PR.
>
> This does not work when the traffic goes through the dev list [ if I reply
> to the message to dev list, the response goes to dev list, not to GH ].  Is
> that additional customization that we already have?  If not, is that
> something worth looking to build/support?
>
>
> Including dev@flagon for visibility, so devs can also potentially
>
> opt-into what gets determined.
>
>
> Thanks,
> Austin
>
>
>

Notifications@ ?

[Austin Bennett]

Hi Flagon Dev,

How do we feel about using a notifications@ list, so that not everything is
piped to dev@?  That is one option mentioned from @ctubb...@apache.org
 ( below ).

That seems vastly preferable for people involved in issue/PR discussions to
not receive duplicate messages.

Related: if Infra is amenable, I am also willing to explore extending the
functionality to be able to reply from email [ sent to list ] to get it
back to GH, that's a very nice feature of the messages coming from GH.

Interested to hear your thoughts.  If there is
consensus/sufficient-support, I'll be happy to update .asf.yaml, and deal
with creating that list [ I'm not sure whether I can move forward via lazy
consensus if not hearing from people ].

Thanks,
Austin


-- Forwarded message -
From: Christopher 
Date: Sun, Jun 11, 2023 at 6:11 PM
Subject: Re: How to NOT receive GH traffic on devlist, for things my GH
user is apart of?
To: Austin Bennett 
Cc: , 


You'd really have to try to convince your project to configure their
.asf.yaml file to send their GH notifications to a secondary list
(like notifications@) which you can simply unsubscribe from, so you
don't get duplicates from both GH and via the mailing list. That way
users can choose to opt-in to the notifications@ list in addition to
the dev@ list, at their choice. Some projects do this, while others
are much more resistant to the idea, and would prefer you just
configure your mail client to filter things out manually.

On Sun, Jun 11, 2023 at 6:40 PM Austin Bennett  wrote:
>
> Hi Infra Users,
>
> The Flagon project currently receives GH notifications to the dev list.
I'd prefer to not receive emails for Issues/Comments I am already
participating in [ as it otherwise feels like spam ], is there a way to
customize this so it does not get sent to me?  I write here since in the
bottom of email to flagon's dev list as forwarded from GH it suggested to
contact us...@infra.apache.org
>
> A related feature request [ maybe better for a different email?]:
> * When GH sends me notifications directly, I can reply to the issue/PR.
This does not work when the traffic goes through the dev list [ if I reply
to the message to dev list, the response goes to dev list, not to GH ].  Is
that additional customization that we already have?  If not, is that
something worth looking to build/support?
>
> Including dev@flagon for visibility, so devs can also potentially
opt-into what gets determined.
>
> Thanks,
> Austin

Re: How to NOT receive GH traffic on devlist, for things my GH user is apart of?

[Austin Bennett]

Thanks, @ctubbsii !

Interesting.  I can imagine how to extend functionality to get this sorted
out via whatever parses the `.asf.yaml` -- but I could dig into that in
more detail.  *If you have a link handy, do share*.  Otherwise, I can
search around.

 This leads me to wonder whether I can mimic the functionality that I get
from subscribing to things via GH, and turn off notifications via GH and
rely on what is piped through the list settings configured in `.asf.yaml`.
For that to work, I would seek additional functionality described in the
following.

Desired functionality:  If I respond to the email it does not appear that
those responses go back to GH and only are sent to the list.  `Is that
something we can imagine supporting in the future, or was it ruled out as
part of the design?  Would that just be a matter of someone contributing
the code to do the thing, or since it involves infra needing to feel
comfortable running/supporting would be a much more involved process [ I'm
not sure how infra works, but I suspect somewhat difference in governance
].




On Sun, Jun 11, 2023 at 6:11 PM Christopher  wrote:

> You'd really have to try to convince your project to configure their
> .asf.yaml file to send their GH notifications to a secondary list
> (like notifications@) which you can simply unsubscribe from, so you
> don't get duplicates from both GH and via the mailing list. That way
> users can choose to opt-in to the notifications@ list in addition to
> the dev@ list, at their choice. Some projects do this, while others
> are much more resistant to the idea, and would prefer you just
> configure your mail client to filter things out manually.
>
> On Sun, Jun 11, 2023 at 6:40 PM Austin Bennett  wrote:
> >
> > Hi Infra Users,
> >
> > The Flagon project currently receives GH notifications to the dev list.
> I'd prefer to not receive emails for Issues/Comments I am already
> participating in [ as it otherwise feels like spam ], is there a way to
> customize this so it does not get sent to me?  I write here since in the
> bottom of email to flagon's dev list as forwarded from GH it suggested to
> contact us...@infra.apache.org
> >
> > A related feature request [ maybe better for a different email?]:
> > * When GH sends me notifications directly, I can reply to the issue/PR.
> This does not work when the traffic goes through the dev list [ if I reply
> to the message to dev list, the response goes to dev list, not to GH ].  Is
> that additional customization that we already have?  If not, is that
> something worth looking to build/support?
> >
> > Including dev@flagon for visibility, so devs can also potentially
> opt-into what gets determined.
> >
> > Thanks,
> > Austin
>

#NewComers/#Easy issues?

[Austin Bennett]

Hi Flagon Devs,

I'd like to surface issues with tags to make it clear what components might
be easier to address, and/or where newcomer help would be especially
welcome.  This is in service towards getting practices/thoughts on list :-)

Some projects have issues tied to each individual component/repo, and
others use a GH Issue list for ALL project related issues.

I wonder whether we believe there are sufficient benefits for having a
single repo [ probably https://github.com/apache/flagon ] so we can use
some tags to have issues that might be especially 'easy' or 'for newbies'.
If we want to maintain multiple lists, per repo that invites some questions:

* Anyone have a good way to be able to provide a single view of #easy
issues for people to contribute to the project?

* In the event of using issues in each GH repo:  if new components might
involve the potential creation of a new repos -- where would an issue get
filed about those new features/components [ since it might not be tied to
an existing repo ]?

Happy to hear your thoughts,
Thanks,
Austin

How to NOT receive GH traffic on devlist, for things my GH user is apart of?

[Austin Bennett]

Hi Infra Users,

The Flagon project currently receives GH notifications to the dev list.
I'd prefer to not receive emails for Issues/Comments I am
already participating in [ as it otherwise feels like spam ], is there a
way to customize this so it does not get sent to me?  I write here since in
the bottom of email to flagon's dev list as forwarded from GH it suggested
to contact us...@infra.apache.org

A related feature request [ maybe better for a different email?]:
* When GH sends me notifications directly, I can reply to the issue/PR.
This does not work when the traffic goes through the dev list [ if I reply
to the message to dev list, the response goes to dev list, not to GH ].  Is
that additional customization that we already have?  If not, is that
something worth looking to build/support?

Including dev@flagon for visibility, so devs can also potentially opt-into
what gets determined.

Thanks,
Austin

Nix ?

[Austin Bennett]

Hi Flagon Devs,

Is anyone else familiar with Nix?   ( if we had shell configs, would those
be used/enjoyed by anyone else? )

If not at all of interest to anyone else, that makes it less interesting to
create - the benefit I get from those is via collab.

Curious your thoughts,
Thanks,
Austin


Ex:
* https://nix.dev/

Re: [GitHub] [flagon] brucearctor opened a new issue, #34: Add Nix [ shell ] config for developing in this repo

[Austin Bennett]

Do we have the ability to customize these messages?  Ex:  I would prefer
not to see issues I'm filing.  Can this be handled serverside?

On Sun, Jun 11, 2023 at 3:29 PM brucearctor (via GitHub) 
wrote:

>
> brucearctor opened a new issue, #34:
> URL: https://github.com/apache/flagon/issues/34
>
>See https://nix.dev/
>
>etc
>
>
> --
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> To unsubscribe, e-mail: dev-unsubscr...@flagon.apache.org.apache.org
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>

gRPC / Protobuf?

[Austin Bennett]

Hi Flagon Devs,

Does anyone else have experience with protobuf/gRPC.  Support is increasing
for web, so it will eventually make sense to use.  Is it too early now?
Does this concern people to also support?  Concretely, I tend to rip
JSON/REST out of most code I touch, for the performance benefits.  I don't
see JSON going away in this project, but do see benefits to at least
support an alternative.

Since this would be a significant effort, it probably warrants a design doc
and ensuring there is some form of consensus/support for the idea.

Any thoughts?  Concerns?  Opposition?

Thanks,
Austin


Ex:  see
* https://github.com/grpc/grpc-web
* https://protobuf.dev/
* https://grpc.io/docs/platforms/web/basics/
* https://github.com/bufbuild/protobuf-es
* etc

Re: managing GitHub messages on threads

[Austin Bennett]

On Fri, Jun 9, 2023 at 6:27 PM Joshua Poore  wrote:

> > Dependabot opens PRs, why treat that differently than other PRs?  So,
> I'm at least a +1 on both 1 and 2 [ but suggest they be the same list? ].
>
> My perspective is that alerts from human contributors are things we really
> need an alert to… dependably alerts are basically noise, but remind us to
> look at dependencies… That was my thinking
>

Makes enough sense to differentiate -- my thinking is that [ in a future
state with with automated testing ] alerts should be mindless and able to
easily merge [ and we'd want to merge dependabot immidiately ].  Esp. in
that scenario, the sooner they merged the better to minimize conflicts with
the yet-to-be-committed code ( or to allow a surface of a bug report
earlier ).  So, that's also fine.  Easier to combine things than separate.
So, I can support that. +1



>
> > For 4 --> Any reason people can't just subscribe themselves to
> notifications [ via 'watch' ]?
> https://docs.github.com/en/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications
> ...  why opt all subscribers of dev list to get that traffic, when there is
> another way to get that info for anyone that wants?
>
> They could… however, there is a concerted drive to keep the Apache threads
> relevant. For real, I’ve had students who have asked me, “what’s a
> listserv”? I think it’s presently natural to keep communities close to the
> source code, which keeps them on platforms like GitHub. However, lists are
> important to Apache for a few reasons: 1) they are an auditable record of
> the community and its decisions; 2) lists foster discussion about community
> over code. So, IMHO I think we should work to bridge discussions on GItHub
> with dev
>

Personally, currently dev@ goes to my inbox, which would likely change the
busier this list gets especially issue/PR traffic [ which I'd prefer to
address 'in bulk' ], but this community certainly is not about me, *so
should do what helps grow the community. *

I am also not sure I understand the connections between students knowing
what a listserv and whether or not PR/Issues should be on-dev-list [ since
we still permit people to comment on issues/PRs/etc on GH or wherever they
want ]?  If anything, that comment sounds like then the move would be
then to pipe PRs/etc to Slack <https://github.com/integrations/slack>,
Discord, etc if students not doing much with email lists.  I would imagine
increasing noise [ any comment on any issue/PR would only discourage people
to read, but ...? ].



>
> -J
>
> > On Jun 6, 2023, at 1:34 AM, Austin Bennett  wrote:
> >
> > Dependabot opens PRs, why treat that differently than other PRs?  So,
> I'm at least a +1 on both 1 and 2 [ but suggest they be the same list? ].
> >
> > For 4 --> Any reason people can't just subscribe themselves to
> notifications [ via 'watch' ]?
> https://docs.github.com/en/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications
> ...  why opt all subscribers of dev list to get that traffic, when there is
> another way to get that info for anyone that wants?
> >
> >
> >
> > On Mon, Jun 5, 2023 at 9:18 PM Joshua Poore  poor...@apache.org>> wrote:
> >> Hi Folks,
> >>
> >> I wanted to raise that we’ve been (slowly) looking to address a
> sensible way to manage the “rage” that GitHub adds to our lists. We don’t
> want an inundation of GitHub comms on the lists to dissuade usage of the
> lists.
> >>
> >> Here’s my proposal:
> >>
> >> 1)  to open a ‘maintenance’ list for flagon and pipe dependabot alerts
> there suppress from dev
> >> 2)  to open a ‘PR’ list for flagon and pipe PR notifications through
> there.
> >> 3) commits will stay on the ‘commits’ thread.
> >> 4) pipe GitHub discussions and Issue mods through to ‘dev’
> >>
> >> Frees up dev for actual discussion and helps better integrate our dev
> list with GitHub, where most of our comms about dev actually end up…
> >>
> >> Big thanks to Chris Dutz @ Apache who informed us of some cool stuff
> they’re doing with lists and Steampipes. Great example here:
> >>
> >>
> >> plc4x/.asf.yaml at e14a3d7dc8bae8ead824f019d5e87767c4460adc ·
> apache/plc4x
> >> github.com
> >>  <
> https://github.com/apache/plc4x/blob/e14a3d7dc8bae8ead824f019d5e87767c4460adc/.asf.yaml#L61>plc4x/.asf.yaml
> at e14a3d7dc8bae8ead824f019d5e87767c4460adc · apache/plc4x <
> https://github.com/apache/plc4x/blob/e14a3d7dc8bae8ead824f019d5e87767c4460adc/.asf.yaml#L61
> >
> >> github.com <
> https://github.com/apache/plc4x/blob/e14a3d7dc8bae8ead824f019d5e87767c4460adc/.asf.yaml#L61
> >
> >>
> >>
> >> Thoughts? Commends?
>
>

Re: [DISCUSS] Changes to Apache Flagon Repo

[Austin Bennett]

Yes.  Also, do we want ALL issues for all repos in one place?  Or issues
for each repo with the repo?  The usual pro/cons.  I suggest for ease of
finding/usability of newcomers ALL issues in same place, but anything fine
for me

On Fri, Jun 9, 2023, 11:16 PM Joshua Poore  wrote:

> I’m in the repo right now, I can write up some issues, but we have to go
> to infra to set up a new repo—essentially, we’ll clone the current
> Apache/Flagon and Apache/Flagon-Website, then remove all the integrations
> stuff. Then we can set up GitHub actions for automation way easier managing
> merges between master and asf-site.
>
> > On Jun 9, 2023, at 10:13 PM, Austin Bennett  wrote:
> >
> > sounds great ...  Do you think we need to writeup issues, and see if
> > concrete/bite-size enough to get any committers or
> > contributors/future-committers to help address?
> >
> > Anyone have an interest and bandwidth to address?
> >
> > On Fri, Jun 9, 2023 at 6:56 PM Joshua Poore  wrote:
> >
> >> Recent PR from Austin raised an excellent point about the current
> >> structure of our Apache/Flagon repo.
> >>
> >> Presently, this repo contains:
> >>
> >> 1. Website assets
> >> 2. Integration examples (e.g., ELK)
> >>
> >> Keeping this repo together as a jumble of top level “utilities” does
> >> prevent us from improving automation in builds and tests for our
> website,
> >> in particular.
> >>
> >> Proposal: Let’s split this repo into two. Establish an
> >> Apache/Flagon-Website repo, and maintain automated builds and tests for
> our
> >> website.
> >>
> >> Thoughts?
>
>

Re: [GitHub] [flagon-useralejs] poorejc commented on pull request #358: Updated examples to use addCallbacks

[Austin Bennett]

TEST:

Does this comment go to GH as well?  Otherwise, I think there is a
usability problem with piping issue/pr comments to a list, and then the
reply doesn't work to send back there.  Let's see.

Also, agreed, thanks, @Jyyjy !



On Fri, Jun 9, 2023 at 6:40 PM poorejc (via GitHub)  wrote:

>
> poorejc commented on PR #358:
> URL:
> https://github.com/apache/flagon-useralejs/pull/358#issuecomment-1585415303
>
>Thanks @Jyyjy these are great adds to docs. Thanks again. Really
> excited about the callback work you did. Solved a thorny issue in userale!
>
>
> --
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> To unsubscribe, e-mail: dev-unsubscr...@flagon.apache.org
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>

Re: [DISCUSS] Changes to Apache Flagon Repo

[Austin Bennett]

sounds great ...  Do you think we need to writeup issues, and see if
concrete/bite-size enough to get any committers or
contributors/future-committers to help address?

Anyone have an interest and bandwidth to address?

On Fri, Jun 9, 2023 at 6:56 PM Joshua Poore  wrote:

> Recent PR from Austin raised an excellent point about the current
> structure of our Apache/Flagon repo.
>
> Presently, this repo contains:
>
> 1. Website assets
> 2. Integration examples (e.g., ELK)
>
> Keeping this repo together as a jumble of top level “utilities” does
> prevent us from improving automation in builds and tests for our website,
> in particular.
>
> Proposal: Let’s split this repo into two. Establish an
> Apache/Flagon-Website repo, and maintain automated builds and tests for our
> website.
>
> Thoughts?

Re: [GitHub] [flagon] brucearctor commented on pull request #29: Update Gemfile

[Austin Bennett]

Since was discussed on another the other thread -- I find this noise by
being on dev list.

On Mon, Jun 5, 2023 at 10:37 PM brucearctor (via GitHub) 
wrote:

>
> brucearctor commented on PR #29:
> URL: https://github.com/apache/flagon/pull/29#issuecomment-1577940757
>
>@poorejc -- what's our 'testing the build' process look like?  Seems
> something more ideal to be automated?
>
>
> --
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> To unsubscribe, e-mail: dev-unsubscr...@flagon.apache.org
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>

Re: managing GitHub messages on threads

[Austin Bennett]

Dependabot opens PRs, why treat that differently than other PRs?  So, I'm
at least a +1 on both 1 and 2 [ but suggest they be the same list? ].

For 4 --> Any reason people can't just subscribe themselves to
notifications [ via 'watch' ]?
https://docs.github.com/en/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications
...  why opt all subscribers of dev list to get that traffic, when there is
another way to get that info for anyone that wants?



On Mon, Jun 5, 2023 at 9:18 PM Joshua Poore  wrote:

> Hi Folks,
>
> I wanted to raise that we’ve been (slowly) looking to address a sensible
> way to manage the “rage” that GitHub adds to our lists. We don’t want an
> inundation of GitHub comms on the lists to dissuade usage of the lists.
>
> Here’s my proposal:
>
> 1)  to open a ‘maintenance’ list for flagon and pipe dependabot alerts
> there suppress from dev
> 2)  to open a ‘PR’ list for flagon and pipe PR notifications through
> there.
> 3) commits will stay on the ‘commits’ thread.
> 4) pipe GitHub discussions and Issue mods through to ‘dev’
>
> Frees up dev for actual discussion and helps better integrate our dev list
> with GitHub, where most of our comms about dev actually end up…
>
> Big thanks to Chris Dutz @ Apache who informed us of some cool stuff
> they’re doing with lists and Steampipes. Great example here:
>
> [image: plc4x.png]
>
> plc4x/.asf.yaml at e14a3d7dc8bae8ead824f019d5e87767c4460adc · apache/plc4x
> 
> github.com
> 
>
> 
>
>
> Thoughts? Commends?
>

2023 Summer of Code

[Austin Bennett]

https://summerofcode.withgoogle.com/

There are possibilities to take on students via GSOC under the ASF
umbrella.  I have mentored for GSOC in the past.  Putting on Flagon's
radar, in case interested in mentoring some students into Open Source.

Re: [DISCUSS] Flagon CI

[Austin Bennett]

Supportive of that.

Would encourage us to also communicate more general guidance on what the
community intends to support [ or can expect ].  An example --> "We support
3 versions of Node, at least 2 of which are LTS".  Or something similar.
Good for website, README, etc...

Also, very strongly suggest that we consider stopping support of versions
once versions are EOL, given potential related security concerns.
Concretely thinking ahead, node16 is EOL 11 Nov 2023 [ 1 ].  After that
point ( once EOL ) software is increasingly dangerous to continue to use,
not to mention harder to support.


[1] https://nodejs.org/en/blog/announcements/nodejs16-eol/

On Mon, Jan 30, 2023 at 8:42 PM Joshua Poore  wrote:

> Silly me—I forgot to couch this in the context of UserALE.js! For the
> avoidance of doubt...
>
> > On Jan 30, 2023, at 11:37 PM, Joshua Poore  wrote:
> >
> > All,
> >
> > I’ve been doing some simple dependency management—mostly for security,
> and to stay on top of modernization.
> >
> > We’re about at that time when some of the versions of Node.js that we
> test against are nearing (or past) the end of life [1].
> >
> > Consistent with [1], I think we should be testing and supporting Node
> vs. 16.x, 18.x, 19.x. Currently we are (CI) testing against 12.x, 14.x,
> 16.x.
> >
> > Before, we commit to any specific versions—I just wanted to pulse the
> community to see if anyone strongly opposes the proposal above, given the
> Node versions they are using.
> >
> > Let’s discuss for 72 hours. I’ll continue maintenance in the interim.
> >
> > Josh
> >
> > [1] https://endoflife.date/nodejs
>
>

Re: Web Extension updates

[Austin Bennett]

Looks like Chrome might be slightly more generous on the deprecation
timeline:  https://developer.chrome.com/docs/extensions/mv3/mv2-sunset/
But, that needn't change the steps proposed here.

>From a user/use-case perspective, would it be better to think about what
browser is supported from master?  Rather than feature?  We are confident
that are always supporting X Browser, which can be better publicized, and
made clear [ ex: it seems feasible if maintaining different
implementations, whatever is not on master might fall behind ].

Also, IIRC, ASF releases are about the artifact being
produced/tested/released.  Is the plan to release versions from the
proposed multiple supported branches?  Or only release the chrome version
from master?



On Sun, Nov 6, 2022 at 2:26 PM Joshua Poore  wrote:

> Hi All—
>
> Update:
>
> My team here at UMD has been working on the plugin a bit.
>
> Completely agree with @Rob Foley.
>
> Issues are as follows:
>
> 1. Chrome is deprecating MV2 in Jan. We have a nice MV3 version of the
> Chrome plugin that builds off the example I committed some time ago.
>
> 2. FF is following suite with Chrome, but not likely on the same timeline.
> Notably, they claim that they *will* support background service workers,
> but not yet. Currently, their MV3 build utilizes “background scripts”.
> While we do have a working MV3 build for FF, it is not compatible with
> Chrome, and won’t be until they roll out support for background service
> workers.
>
> 3. We’ve not yet tested on Edge.
>
> I think the near term decision is really which browser build we want to
> keep on Master. At this point, I see it as a forced choice between Chrome
> and FF. Certainly we can keep an otherwise level branch that supports the
> other.
>
> Given that FF eventually will move to Background scripts, I propose:
>
> 1. Add support for MV3 for Chrome on Master
> 2. Keep a branch that supports MV2 (for near term FF support—they are
> keeping support for MV2 for the near term)
> 3. Add support for MV3 for FF (and Edge) when FF adds support for
> Background Service Workers.
>
> Thoughts?
>
> J
>
> > On Sep 2, 2022, at 1:38 PM, Rob Foley  wrote:
> >
> > I don't recall enough about our initial browser compatibility list, but,
> if we haven't yet already deprecated IE support, this will do it. For the
> sake of correctness, |fetch| isn't a protocol, it is just a browser API.
> Both the |fetch| and |XMLHttpRequest| APIs will make essentially the same
> |POST| requests.
> >
> > Here is the browser compatibility list for |fetch|, the picture for the
> |Service Workers| is similar:
> > https://caniuse.com/fetch
> >
> > On the subject of compatibility, keep in mind that the switch to
> Manifest V3 will also mean immediate loss of compatibility with the earlier
> versions of Chrome/Firefox/Edge, since the change isn't backwards
> compatible. With that in mind, it may be wise for us to
> temporarily/permanently keep an older Manifest V2 version published.
> >
> > Regards,
> > Rob
> >
> > On 8/29/2022 9:49 PM, Austin Bennett wrote:
> >> Great to be updating to keep compatibility.  A web-based tool without
> >> chrome and Firefox compatibility seems ... not desirable.
> >>
> >> I haven't used that part of the tooling.  Naturally, if you think
> valuable,
> >> then it seems worth the effort.  Not into the specifics enough to have a
> >> worthwhile opinion on implementation.
> >>
> >> Since this is designed to continue functionality, i would expecr changes
> >> needed to support to be not especially contentious even if involved
> >> significant modification.
> >>
> >> It sounds like this can be done without breaking things for our users,
> if
> >> that's the case then not concerned about version numbering.
> >>
> >>
> >>
> >> On Mon, Aug 29, 2022, 6:28 PM Joshua Poore  wrote:
> >>
> >>> All,
> >>>
> >>> Looking for comments on this:
> >>>
> >>> I think there are only few end users that actually use our Web
> Extension,
> >>> however, it’s a pretty valuable tool in user testing uninstrumented
> >>> applications.
> >>>
> >>> Presently, our WebExtension (on Master) is Manifest v2. However, as you
> >>> may be aware Chrome is moving to Manifest v3 (MV3). MV2 will be
> unsupported
> >>> by chrome following Dec 2022.
> >>>
> >>> https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/
> < https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/&

Re: [ VOTE ] Graduation of Flagon Project

[Austin Bennett]

Result Vote found:
https://lists.apache.org/thread/vcpqfsvx17zzmd5ztklgz63tc0wcpdno

Do advise if anything should be changed.

On Sat, Nov 5, 2022 at 6:28 PM lewis john mcgibbney 
wrote:

> Excellent, please close the thread off with a RESULT title and then tally
> the VOTE’s and who VOTE’d.
> Thanks
>
> On Sat, Nov 5, 2022 at 15:37 Austin Bennett 
> wrote:
>
> > On this thread, we have 6 +1s [ also another on the incubator thread ]
> and
> > no 0, or -1 votes, so* the VOTE passes*, and we can confidently say the
> > community is in favor of Graduation.
> >
> >
> > On Thu, Nov 3, 2022 at 8:00 AM Evan Jones 
> wrote:
> >
> >> + 1
> >>
> >> Best
> >>
> >> Evan Jones
> >> Website: www.ea-jones.com
> >>
> >>
> >> On Thu, Nov 3, 2022 at 4:44 AM Furkan KAMACI 
> >> wrote:
> >>
> >> > Definitely +1!
> >> >
> >> > On Tue, Nov 1, 2022 at 7:58 PM Amir Ghaemi  wrote:
> >> >
> >> >> +1
> >> >>
> >> >> Best Regards,
> >> >> *Amir M. Ghaemi*
> >> >>
> >> >>
> >> >> On Tue, Nov 1, 2022 at 7:06 AM Gedd Johnson 
> >> wrote:
> >> >>
> >> >> > +1
> >> >> >
> >> >> > Best,
> >> >> > Gedd Johnson
> >> >> >
> >> >> > On Mon, Oct 31, 2022 at 23:22 Joshua Poore 
> >> wrote:
> >> >> >
> >> >> > > Emphatic +1 for me.
> >> >> > >
> >> >> > > Sincerely,
> >> >> > >
> >> >> > > Josh
> >> >> > >
> >> >> > >
> >> >> > > On Oct 31, 2022, at 5:13 PM, lewis john mcgibbney <
> >> lewi...@apache.org
> >> >> >
> >> >> > > wrote:
> >> >> > >
> >> >> > > +1
> >> >> > >
> >> >> > > On Mon, Oct 31, 2022 at 09:31 Austin Bennett 
> >> >> wrote:
> >> >> > >
> >> >> > >> Hi Flagon Community,
> >> >> > >> +1
> >> >> > >> Given recent discussions around the graduation status of the
> >> >> project, it
> >> >> > >> is time to work through the process.  We have had a recent
> >> discussion
> >> >> > >> on-list, and consensus seems to be in favor of graduation.  The
> >> next
> >> >> > step
> >> >> > >> seems to be a recommendation that we make an official VOTE, per:
> >> >> > >> https://incubator.apache.org/guides/graduation
> >> >> > >> .html#community_graduation_vote
> >> >> > >>
> >> >> > >> *Please VOTE* for the actual record.  I will also let the
> >> Incubator
> >> >> know
> >> >> > >> the vote is occurring [ per the link above ], and imagine that I
> >> will
> >> >> > tally
> >> >> > >> the votes later on Friday the 4th to allow for >= 72 hours;
> we'll
> >> see
> >> >> > how
> >> >> > >> this thread goes.
> >> >> > >>
> >> >> > >> Per https://www.apache.org/foundation/voting.html* ideally
> votes
> >> >> will
> >> >> > >> be +1, 0, or -1* And, as I understand it, only IPMC votes are
> >> >> binding,
> >> >> > >> as found in
> >> https://incubator.apache.org/guides/participation.html.
> >> >> > >>
> >> >> > >>
> >> >> > >> Please consider this my +1.
> >> >> > >>
> >> >> > >> The existing community has demonstrated addressing the
> >> requirements
> >> >> as
> >> >> > >> found in the incubator guidelines for graduation.  Graduation is
> >> an
> >> >> > >> important milestone signaling project maturity, and a great step
> >> >> towards
> >> >> > >> ongoing growth and evolution.
> >> >> > >>
> >> >> > >> Cheers -
> >> >> > >> Austin
> >> >> > >>
> >> >> > >> --
> >> >> > > http://home.apache.org/~lewismc/
> >> >> > > http://people.apache.org/keys/committer/lewismc
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> >
> >> >>
> >> >
> >>
> > --
> http://home.apache.org/~lewismc/
> http://people.apache.org/keys/committer/lewismc
>

[RESULT][VOTE] Graduation of Flagon Project

[Austin Bennett]

Hi Flagon Community,

The votes have been tallied, and the result is in favor of the graduation
of the Flagon project [1].  Per the Graduation Guidelines this is meant to
show the community's support, which was unanimous with 6 votes on the
message thread [ and 1 additional from @lewi...@apache.org
 found in two alternate locations [2][3] - so that is
noteworthy, but I mention supplementarily rather than part of the official
on-list Vote ], and no votes against.

Votes in Favor [ beyond those by of Lewis John McGibbney ] were cast by:

Joshua Poore
Gedd Johnson
Amir Ghaemi
Furkan KAMACI
Evan Jones
Austin Bennett


There were no votes against.

Best,
Austin


[1] https://lists.apache.org/thread/vlhrb87f6s4wmckkwrh2v3toj06zhhbp
[2] https://lists.apache.org/thread/po7g4b51mp6nb2khvkpxd8r0gv4qsh34
[3] https://lists.apache.org/thread/xbkg9mcwx23c1235013ownyxss31rkpc

Re: [ VOTE ] Graduation of Flagon Project

[Austin Bennett]

On this thread, we have 6 +1s [ also another on the incubator thread ] and
no 0, or -1 votes, so* the VOTE passes*, and we can confidently say the
community is in favor of Graduation.


On Thu, Nov 3, 2022 at 8:00 AM Evan Jones  wrote:

> + 1
>
> Best
>
> Evan Jones
> Website: www.ea-jones.com
>
>
> On Thu, Nov 3, 2022 at 4:44 AM Furkan KAMACI 
> wrote:
>
> > Definitely +1!
> >
> > On Tue, Nov 1, 2022 at 7:58 PM Amir Ghaemi  wrote:
> >
> >> +1
> >>
> >> Best Regards,
> >> *Amir M. Ghaemi*
> >>
> >>
> >> On Tue, Nov 1, 2022 at 7:06 AM Gedd Johnson 
> wrote:
> >>
> >> > +1
> >> >
> >> > Best,
> >> > Gedd Johnson
> >> >
> >> > On Mon, Oct 31, 2022 at 23:22 Joshua Poore 
> wrote:
> >> >
> >> > > Emphatic +1 for me.
> >> > >
> >> > > Sincerely,
> >> > >
> >> > > Josh
> >> > >
> >> > >
> >> > > On Oct 31, 2022, at 5:13 PM, lewis john mcgibbney <
> lewi...@apache.org
> >> >
> >> > > wrote:
> >> > >
> >> > > +1
> >> > >
> >> > > On Mon, Oct 31, 2022 at 09:31 Austin Bennett 
> >> wrote:
> >> > >
> >> > >> Hi Flagon Community,
> >> > >> +1
> >> > >> Given recent discussions around the graduation status of the
> >> project, it
> >> > >> is time to work through the process.  We have had a recent
> discussion
> >> > >> on-list, and consensus seems to be in favor of graduation.  The
> next
> >> > step
> >> > >> seems to be a recommendation that we make an official VOTE, per:
> >> > >> https://incubator.apache.org/guides/graduation
> >> > >> .html#community_graduation_vote
> >> > >>
> >> > >> *Please VOTE* for the actual record.  I will also let the Incubator
> >> know
> >> > >> the vote is occurring [ per the link above ], and imagine that I
> will
> >> > tally
> >> > >> the votes later on Friday the 4th to allow for >= 72 hours; we'll
> see
> >> > how
> >> > >> this thread goes.
> >> > >>
> >> > >> Per https://www.apache.org/foundation/voting.html* ideally votes
> >> will
> >> > >> be +1, 0, or -1* And, as I understand it, only IPMC votes are
> >> binding,
> >> > >> as found in https://incubator.apache.org/guides/participation.html
> .
> >> > >>
> >> > >>
> >> > >> Please consider this my +1.
> >> > >>
> >> > >> The existing community has demonstrated addressing the requirements
> >> as
> >> > >> found in the incubator guidelines for graduation.  Graduation is an
> >> > >> important milestone signaling project maturity, and a great step
> >> towards
> >> > >> ongoing growth and evolution.
> >> > >>
> >> > >> Cheers -
> >> > >> Austin
> >> > >>
> >> > >> --
> >> > > http://home.apache.org/~lewismc/
> >> > > http://people.apache.org/keys/committer/lewismc
> >> > >
> >> > >
> >> > >
> >> >
> >>
> >
>

[ VOTE ] Graduation of Flagon Project

[Austin Bennett]

Hi Flagon Community,

Given recent discussions around the graduation status of the project, it is
time to work through the process.  We have had a recent discussion on-list,
and consensus seems to be in favor of graduation.  The next step seems to
be a recommendation that we make an official VOTE, per:
https://incubator.apache.org/guides/graduation
.html#community_graduation_vote

*Please VOTE* for the actual record.  I will also let the Incubator know
the vote is occurring [ per the link above ], and imagine that I will tally
the votes later on Friday the 4th to allow for >= 72 hours; we'll see how
this thread goes.

Per https://www.apache.org/foundation/voting.html* ideally votes will
be +1, 0, or -1* And, as I understand it, only IPMC votes are binding, as
found in https://incubator.apache.org/guides/participation.html.


Please consider this my +1.

The existing community has demonstrated addressing the requirements as
found in the incubator guidelines for graduation.  Graduation is an
important milestone signaling project maturity, and a great step towards
ongoing growth and evolution.

Cheers -
Austin

Re: [DISCUSS] Graduate Apache Flagon

[Austin Bennett]

Looks like community consensus is for graduation.

Is next step a formal vote?  Or, something else?

I am happy to check with incubator, etc on working through steps, in the
event nobody else wants to drive this.


On Mon, Oct 24, 2022, 10:35 AM Rob Foley  wrote:

> I'm also in favor of graduation.
>
> Rob
>
> On 10/22/2022 1:44 PM, Austin Bennett wrote:
> > +1
> >
> > Graduation a great step, I am in favor.
> >
> > I would like to see a bigger community [ of public users, and
> contributors
> > ], and those from different organizations.  But, graduation may help
> that -
> > as being graduated is a strong signaling mechanism.
> >
> >
> >
> >
> > On Sat, Oct 22, 2022 at 9:52 AM Gedd Johnson 
> wrote:
> >
> >> This is great to hear! Strongly in favor.
> >> - Gedd
> >>
> >> On Fri, Oct 21, 2022 at 22:42 Joshua Poore  wrote:
> >>
> >>> Hi All,
> >>>
> >>> I’m initiating this DISCUSS thread to talk through the communities
> >>> perspective (at this point in time) on Graduation as a Top Level
> project.
> >>>
> >>> Flagon has tried to Graduate twice before first in 2018, and then in
> >> 2020.
> >>> Each time, we didn’t get any strong blockers, but some tickets that we
> >>> worked to burn down. Ultimately, though the graduation VOTE on
> >>> general@incubator just lost steam. Here is the last thread:
> >>>
> >>> https://lists.apache.org/thread/svf7ckpohmt4s9cflf35m12n3w0sz46z <
> >>> https://lists.apache.org/thread/svf7ckpohmt4s9cflf35m12n3w0sz46z>
> >>>
> >>> Now, the Incubator is highly motivated to push projects that have been
> in
> >>> Incubation status longer than two years to move toward graduation.
> Flagon
> >>> is CERTAINLY on that list, and the remark is that we should have
> >> graduated.
> >>> At this point, there are certainly ways that our project and community
> >> can
> >>> improve. However, the following is true:
> >>>
> >>> 1. The community has consistently VOTED in favor Graduation
> >>> 2. Mentors have consistently been in favor of Graduation
> >>> 3. The project has demonstrated stability and continued growth over the
> >>> years
> >>> 4. The project meets the maturity model of the incubator:
> >>>
> >>
> https://community.apache.org/apache-way/apache-project-maturity-model.html
> >>> <
> >>>
> >>
> https://community.apache.org/apache-way/apache-project-maturity-model.html
> >>> 5. The Incubator is now very engaged in graduating (I suspect VOTEs on
> >>> INCUBATOR won’t fizzle out)
> >>>
> >>> The project and the community, like software, are never done. So the
> >>> question to DISCUSS is whether the community agrees that we’re ready to
> >>> self-govern and continue development outside the Incubator.
> >>>
> >>> Let’s discuss over the next week, and move to a VOTE on the week of the
> >> 31
> >>> OCT 2022.
> >>>
> >>> Best,
> >>>
> >>> Josh
>

Re: [DISCUSS] Graduate Apache Flagon

[Austin Bennett]

+1

Graduation a great step, I am in favor.

I would like to see a bigger community [ of public users, and contributors
], and those from different organizations.  But, graduation may help that -
as being graduated is a strong signaling mechanism.




On Sat, Oct 22, 2022 at 9:52 AM Gedd Johnson  wrote:

> This is great to hear! Strongly in favor.
> - Gedd
>
> On Fri, Oct 21, 2022 at 22:42 Joshua Poore  wrote:
>
> > Hi All,
> >
> > I’m initiating this DISCUSS thread to talk through the communities
> > perspective (at this point in time) on Graduation as a Top Level project.
> >
> > Flagon has tried to Graduate twice before first in 2018, and then in
> 2020.
> > Each time, we didn’t get any strong blockers, but some tickets that we
> > worked to burn down. Ultimately, though the graduation VOTE on
> > general@incubator just lost steam. Here is the last thread:
> >
> > https://lists.apache.org/thread/svf7ckpohmt4s9cflf35m12n3w0sz46z <
> > https://lists.apache.org/thread/svf7ckpohmt4s9cflf35m12n3w0sz46z>
> >
> > Now, the Incubator is highly motivated to push projects that have been in
> > Incubation status longer than two years to move toward graduation. Flagon
> > is CERTAINLY on that list, and the remark is that we should have
> graduated.
> >
> > At this point, there are certainly ways that our project and community
> can
> > improve. However, the following is true:
> >
> > 1. The community has consistently VOTED in favor Graduation
> > 2. Mentors have consistently been in favor of Graduation
> > 3. The project has demonstrated stability and continued growth over the
> > years
> > 4. The project meets the maturity model of the incubator:
> >
> https://community.apache.org/apache-way/apache-project-maturity-model.html
> > <
> >
> https://community.apache.org/apache-way/apache-project-maturity-model.html
> > >
> > 5. The Incubator is now very engaged in graduating (I suspect VOTEs on
> > INCUBATOR won’t fizzle out)
> >
> > The project and the community, like software, are never done. So the
> > question to DISCUSS is whether the community agrees that we’re ready to
> > self-govern and continue development outside the Incubator.
> >
> > Let’s discuss over the next week, and move to a VOTE on the week of the
> 31
> > OCT 2022.
> >
> > Best,
> >
> > Josh
>

Re: [RESULT] Accept ICLA and Software Grant from UMD Into the Apache Flagon Podling

[Austin Bennett]

Great, thanks josh!

On Mon, Sep 26, 2022, 7:23 PM Joshua Poore  wrote:

> Good news!
>
> I think we’re clear on all our actions following the CCLA and SW Grant.
>
> I’ve pushed the SW grant to the Apache Flagon Distill repo (
> https://github.com/apache/incubator-flagon-distill <
> https://github.com/apache/incubator-flagon-distill>).
>
> I’ve also started on some of our overhead actions (updating copyright,
> headers, etc.) on a dev branch:
> https://github.com/apache/incubator-flagon-distill/tree/license_headers <
> https://github.com/apache/incubator-flagon-distill/tree/license_headers>
>
> I’ve preserved our legacy code on another branch:
> https://github.com/apache/incubator-flagon-distill/tree/distill_server_legacy
> <
> https://github.com/apache/incubator-flagon-distill/tree/distill_server_legacy
> >
>
> best,
>
> Josh
>
> > Begin forwarded message:
> >
> > From: Joshua Poore 
> > Subject: [RESULT] Accept ICLA and Software Grant from UMD Into the
> Apache Flagon Podling
> > Date: September 26, 2022 at 10:18:23 PM EDT
> > To: gene...@incubator.apache.org
> > Reply-To: gene...@incubator.apache.org
> >
> > The VOTE is closed. Thanks to all those who VOTE’d!
> >
> > The RESULTS are as follows:
> >
> > [4] +1 (3 IPMC Binding)
> > [0] 0
> > [0] -1
> >
> > The consensus VOTE to accept the SW Grant from UMD for the Distill
> refactor has passed.
> >
> > Some additional clarification following from John’s comments:
> >
> > 1. UMD has granted the copyright to ASF (this is explicitly stated in
> our IP disclosure case through UMD Ventures)--those of us that can commit
> on behalf of UMD are changing the copyright statement to appropriately
> reflect ASF.
> > 2. This is a substantial SW gift, but there remains much overhead before
> an official ASF release—including ensuring appropriate headers are on every
> source file.
> > 3. .ipynb are json, however, it’s easy enough to include an ASF header
> in a cell at the top of notebook. Notwithstanding, we’ll ask around and see
> if there is a (better) best practice.
> >
> > Thanks!
> >
> > Josh (on behalf of Flagon PPMC)
> >
> >> On Sep 17, 2022, at 10:11 AM, John D. Ament 
> wrote:
> >>
> >> Here's my +1 on the code
> >>
> >> There's a few notes:
> >> - I would recommend the podling add some kind of reference to this
> clause
> >> in their NOTICE file: Copyright 2022 The Applied Research Laboratory for
> >> Intelligence and Security (ARLIS) (see [1])
> >> - There's many files missing any headers.  I think it's safe to assume
> they
> >> follow the same license since there is a LICENSE file at the root.  I
> >> couldn't find any evidence that the files missing headers were
> copy/pasted
> >> from other repositories.
> >> - For files like the .ipynb files, I don't think there's a way to
> >> explicitly add a license header (since they're JSON files).  You may
> want
> >> to consult with legal on how to add license file references for them.
> >>
> >>
> >> [1]:
> >>
> https://github.com/UMD-ARLIS/incubator-flagon-distill/blob/distill_toolkit_refactor/NOTICE
> >>
> >>
> >> On Fri, Sep 16, 2022 at 11:12 AM John D. Ament 
> >> wrote:
> >>
> >>> Hey Josh,
> >>>
> >>> Thanks for the clarification, I found the thread from Craig.  For
> future
> >>> reference, you shouldn't be voting on accepting a CCLA and/or SGA.
> >>> Procedure wise, this doesn't make sense.  You're voting on accepting a
> code
> >>> donation, and it's just that code donations from the foundation's
> >>> standpoint require a SGA.  The vote to accept the donation happens on
> the
> >>> podling's private list.  I think we're in alignment up to that point
> (other
> >>> than the fact that the vote on the private list looks a bit off).
> >>>
> >>> To be 100% clear on the scope, you're looking for a third vote to view
> the
> >>> repo at [1] and confirm whether or not the content within is compliant
> to
> >>> be imported into a repository hosted by the ASF? Where I'm concerned
> with
> >>> the original vote, you're including in scope adding 5 new committers
> (which
> >>> aren't named in the vote thread) to the project.  It's not apparent
> that
> >>> both are in scope, the vote to add committers should be separate from
> the
> >>> vote to add code to the repository (usually you would import the code
> >>> first, then vote to add the committers to the project).  Do keep in
> mind
> >>> since these are your coworkers you're not building a diverse community
> of
> >>> committers.
> >>>
> >>> I'm including a few links to show a bit better how TLPs have handled
> this
> >>> before to give a little better picture.  I'll take a deeper look in the
> >>> repo I linked in a bit, but I'm not seeing any major issues with the
> code.
> >>>
> >>> - John
> >>>
> >>> [1]:
> >>>
> https://github.com/UMD-ARLIS/incubator-flagon-distill/tree/distill_toolkit_refactor
> >>> TLPs: https://lists.apache.org/thread/r7jx0d2fy37kwj792n0qf5rcttyqzmzp
> ,
> >>> https://lists.apache.org/thread/b2gmkbp879m72gdyztl674tqhtpdl7zn
> >>>
> >>> 

Re: [ DISCUSS ] Dependabot PRs?

[Austin Bennett]

Personally would err towards more frequent rather than less frequent.
Isn't that the intent behind CI/CD ... "continuous" rather than batch.

Esp. dependency bumps can coincide with security vulnerability fixes?
Wouldn't we want those incorporated ASAP?

We would even need to check.  I *think* there might be something where we
can't allow bots to auto-merge code?  But would need to check ASF policy.

Human in the loop for a final merge not particularly contentious.  But,
ideally we continue to find ways to get computers to do the verification [
ex: integration, and even functional tests ] as part of the
build/test/deployment pipelines.

Also: We are talking about code in Git, which is reversible.  Much
different and potentially lower stakes than other autonomous systems [ ex:
weapons ].




On Mon, Aug 29, 2022, 7:07 PM Joshua Poore  wrote:

> I’m a nervous nelly about updating the entire built pipeline without human
> in the loop eyes on integration tests. That’s the thing about the
> UserALE.js repo—it’s not just about source and build artifacts. The build
> artifacts export well out of the box, but the entire repo itself is a build
> pipeline that supports local customization. The build procs and
> dependencies are important to curate… my 02c.
>
> We could also pull back dependabot to check on a monthly basis, not
> weekly. That will reduce clutter in committer inboxes.
>
> So, that’s a monthly review and manual merge with Master. How’s that?
>
> > On Aug 29, 2022, at 9:24 PM, Austin Bennett 
> wrote:
> >
> > That is certainly a way to do it that seems better than the current
> > approach?  Hoping to get as automated as feasible.
> >
> > Is there a reason you'd want package.json updates to be done manually?
> > That seems something a GH Action could do [ after tests pass ] -- without
> > having spent about any time with this thought, it looks like it could
> parse
> > updated package-lock to get versions and then replace/update those
> versions
> > in package.json, and run tests accordingly.
> >
> >
> >
> > On Mon, Aug 29, 2022 at 6:15 PM Joshua Poore  wrote:
> >
> >> Dependabot updates package-file not package.json. When I clear these
> >> updates, i like to update package.json and test for collisions. I agree
> >> dependabot is just alerting us to updates.
> >>
> >> Proposal: why don’t we have dependabot merge changes into the test
> branch.
> >> then we can update package.json in merges from test to master.
> >>
> >> How’s that?
> >>
> >>> On Aug 26, 2022, at 11:42 AM, Austin Bennett <
> >> whatwouldausti...@gmail.com> wrote:
> >>>
> >>> Hi Devs,
> >>>
> >>> We have Dependabot in the repository which is suggesting maintenance
> PRs
> >> to
> >>> bump versions -->
> >>>
> >>
> https://github.com/apache/incubator-flagon-useralejs/pulls/app%2Fdependabot
> >>>
> >>> What are your thoughts around how to treat those PRs?
> >>>
> >>> * Turn off?
> >>> * Just [manually] merge?  We do have some tests, and if bumping
> versions
> >>> causes more problems that just points to needing to roll-back and/or
> add
> >>> new tests?
> >>> * Configure dependabot to auto-merge if tests pass?
> >>> * other?
> >>>
> >>> Cheers,
> >>> Austin
> >>
> >>
>

Re: [ DISCUSS ] Dependabot PRs?

[Austin Bennett]

That is certainly a way to do it that seems better than the current
approach?  Hoping to get as automated as feasible.

Is there a reason you'd want package.json updates to be done manually?
That seems something a GH Action could do [ after tests pass ] -- without
having spent about any time with this thought, it looks like it could parse
updated package-lock to get versions and then replace/update those versions
in package.json, and run tests accordingly.



On Mon, Aug 29, 2022 at 6:15 PM Joshua Poore  wrote:

> Dependabot updates package-file not package.json. When I clear these
> updates, i like to update package.json and test for collisions. I agree
> dependabot is just alerting us to updates.
>
> Proposal: why don’t we have dependabot merge changes into the test branch.
> then we can update package.json in merges from test to master.
>
> How’s that?
>
> > On Aug 26, 2022, at 11:42 AM, Austin Bennett <
> whatwouldausti...@gmail.com> wrote:
> >
> > Hi Devs,
> >
> > We have Dependabot in the repository which is suggesting maintenance PRs
> to
> > bump versions -->
> >
> https://github.com/apache/incubator-flagon-useralejs/pulls/app%2Fdependabot
> >
> > What are your thoughts around how to treat those PRs?
> >
> > * Turn off?
> > * Just [manually] merge?  We do have some tests, and if bumping versions
> > causes more problems that just points to needing to roll-back and/or add
> > new tests?
> > * Configure dependabot to auto-merge if tests pass?
> > * other?
> >
> > Cheers,
> > Austin
>
>

[ DISCUSS ] Dependabot PRs?

[Austin Bennett]

Hi Devs,

We have Dependabot in the repository which is suggesting maintenance PRs to
bump versions -->
https://github.com/apache/incubator-flagon-useralejs/pulls/app%2Fdependabot

What are your thoughts around how to treat those PRs?

* Turn off?
* Just [manually] merge?  We do have some tests, and if bumping versions
causes more problems that just points to needing to roll-back and/or add
new tests?
* Configure dependabot to auto-merge if tests pass?
* other?

Cheers,
Austin

[DISCUSS] What Reviews Required-or-Needed / When OK to merge?

[Austin Bennett]

Hi Flagon-Dev,

Do we have a Flagon community standard for when OK to merge a PR?

Inviting us to have a discussion, and to get consensus around community
standards for reviewing PRs/when-OK-to-Merge.  Apologies if I missed a
prior discussion/doc on this topic.

I assume we ultimately need a committer to review the work of a
non-committer ahead of merge ( since someone with permissions eventually
has to actually accept/merge/commit the code ).  In general, is one
reviewer/committer sufficient?

How does this change if the author of the PR is an existing committer?  I
have seen some communities require a committee to review things ( no matter
the status of the author), and others require anyone else -- so that's more
of a community determination.  For example, could also be a judgement call
as to whether to tag in the expertise of someone having great depth on a
specific component, or just some eyeballs for sanity check.

Hoping we can try to be *somewhat* specific [ where possible ] about the
sort of expected requirements, and our standards.  A result of the
discussion likely will be things that can be summarized and used for
updating http://flagon.incubator.apache.org/docs/contributing/

And, naturally there are exceptions ( ex: very large commits, when
functionality significantly altered [ such a case could warrant a FIP /
Flagon-Improvement-Proposal ], etc ).  And, exception in the other
direction -- how sufficiently small to be OK merging without another
reviewer [ of any kind ]?

Thanks,
Austin

Re: [DISCUSS] Accept UMD Software Grant into Apache Flagon

[Austin Bennett]

The details shared in the email sound great.  Will follow up after reading
the links, in the event anything seems really concerning.


On Tue, May 31, 2022, 6:49 PM Joshua Poore  wrote:

> Hi All,
>
> I’m very excited to say that the University of Maryland has executed an
> CCLA with Software Grant for the Apache Flagon project!
>
> The Software Grant encompasses a refactor of the Apache Flagon Distill
> product, which has been deprecated for a few years now [1]
>
> This Grant includes ~150 new commits and thousands of new insertions (and
> a lot of deletions)
>
> At UMD my team and I re-thought Distill as a Python Package (for distro
> through PyPI) [2] that allows users to:
>
> - efficiently segment UserALE.js (or User Behavior Logs) data
> - curate segments
> - transform segments with logical operations (intersection, union, etc.)
> - filter log data extracted from segments
> - apply analytics (e.g., statistical, graphs) to data extracted from
> segments
> - support graph-based visualization (funnel, sankey)
>
> Additionally:
> - code is well documented [3]
> - excellent working examples [4]
>
> Distill also provides examples for dashboards to visualize segments using
> both Apache Superset and Plotly/Dash
>
> The original Distill product was tethered to a front-end (Tap), relied on
> rudimentary (and error-prone) processing of segments within the client.
> This made Distill difficult to maintain and required users to adopt tap,
> limiting their analytical use-cases with UserALE.js and Distill.
>
> Overall, I think that Distill provides a far more scaleable product to
> engage (and expand) our development community. I think this will add real
> value to Apache Flagon.
>
> Overhead/Actions prior to release:
>
> - Documentation builds will need be adjusted for a new repo/branch
> - Additional documentation for a few analytical functions (i.e.,
> click-rate)
> - Minor tweaks to simply code in a few functions (i.e., click-rate)
> - Some restructuring of Repo to consolidate and organize examples
> - a few additional README’s should be added (i.e., examples /dir)
>
> IP Clearance
>
> The Software Grant is signed by Felicia Metz, esq. who is an Associate
> Director at the University of Maryland’s, UMD Ventures office, which has
> authority to release UMD IP. That makes accepting this grant significantly
> easier from an IP Clearance perspective.
>
> New Committers
>
> The UMD executed CCLA includes 5 new committers and potentially new PPMC
> members.
>
> Prior to initiating a VOTE on private@ I wanted to give the community an
> opportunity to chime in and ask questions. The New Committers listed are
> already subscribed to the dev list.
>
> Let’s take 72 hours to DISCUSS prior to a VOTE.
>
> Best,
>
> Josh
>
>
> [1] https://github.com/apache/incubator-flagon-distill <
> https://github.com/apache/incubator-flagon-distill>
> [2]
> https://github.com/UMD-ARLIS/incubator-flagon-distill/tree/distill_toolkit_refactor
> <
> https://github.com/UMD-ARLIS/incubator-flagon-distill/tree/distill_toolkit_refactor>
>
> [3]
> https://incubator-flagon-distill.readthedocs.io/en/distill_toolkit_refactor/
> <
> https://incubator-flagon-distill.readthedocs.io/en/distill_toolkit_refactor/>
>
> [4]
> https://github.com/UMD-ARLIS/incubator-flagon-distill/blob/distill_toolkit_refactor/examples/Segments_Demo.ipynb
> <
> https://github.com/UMD-ARLIS/incubator-flagon-distill/blob/distill_toolkit_refactor/examples/Segments_Demo.ipynb>
>

Re: [ANNOUNCEMENT] Austin Bennett added as Apache Flagon Committer and PPMC

[Austin Bennett]

Thanks, all -- glad to be voted in to be even more a part of the community,
and looking forward to seeing the things we will develop!




On Thu, May 26, 2022 at 7:42 PM Joshua Poore  wrote:

> All--
>
> I am pleased to Announce that Austin Bennet has been added as a Committer
> and PPMC member following a passing VOTE at the PPMC level.
>
> Austin has participated in the Flagon community for a few years, and has
> been active in discussions, governance VOTEs, and Release VOTEs.
>
> Austin is already a committer with ASF within the Apache Beam community.
> He brings with him a rich set of ideas for our project and deep experience
> in FOSS development, the Apache Way. We welcome his help in development,
> steerage, and governance!
>
> PPMC is working with mentors to complete onboarding
>
> Welcome to full-tilt Flagon, Austin! And Thank You!
>
> Best,
>
> Josh (PPMC)
>
>
>

Re: Flagon Related Publication RE Distill and Analytics

[Austin Bennett]

great - thanks for sharing!

On Tue, May 24, 2022 at 7:12 AM Joshua Poore  wrote:

> Hi All,
>
> For your reading enjoyment:
>
> My team at University of Maryland presented a paper on our work on Distill
> to the 2022 AAAI Spring Symposium on AI Engineering. Our paper is now
> available as a proceedings here:
> http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=884337 <
> http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=884337>
>
> Enjoy!
>
> -Josh

Re: [VOTE] Release Apache Flagon (Incubating) UserALE.js 2.3.0

[Austin Bennett]

Exactly.  Not enough binding/qualified votes to approve the release.
Thanks for confirming!  And, getting the project [ well, those that read
the dev list ], on the same page.



On Tue, May 10, 2022 at 2:10 PM Joshua Poore  wrote:

> Austin,
>
> Because we’re still a podling, PPMC (Podling Project Management Committee)
> VOTEs don’t count toward releases RE Apache release guideline. Think of
> Podlings as smaller projects under the larger “Incubator” project. We need
> +3 IPMC (Incubator Podline Management Committee) VOTES to pass release
> VOTES (and more +1 and -1). That doesn’t mean that “community” VOTEs —
> PPMC, Committer, and anyone on Dev—don’t count for anything. Still
> appreciated at the IPMC level.
>
> As it stands we have +1 Binding VOTEs toward release and will need to
> rally at the IPMC level. Furkan and our mentors are all IPMC.
>
> Apologies for the delay in the release VOTE. I should have delegated
> earlier in light of havoc at home.
>
> > On May 7, 2022, at 10:11 PM, Austin Bennett 
> wrote:
> >
> > Furkan,
> >
> > Trying to understand the process, esp. understand PPMC, IPMC, and mentor
> > distinction.  I see you as a mentor [1], and look like for someone to be
> a
> > mentor, they must be  IPMC which you are [2] .
> >
> > These comments are to understand ASF Process, and to ensure there are
> docs
> > ( perhaps I'm failing to find, as I've only done a cursory search thus
> far
> > ).
> >
> > According to [3] "The only time when a PPMC member’s vote is binding is
> for
> > the addition of new PPMC members and committers. Release votes are only
> > binding for IPMC members." ... so that seems like for a release the only
> > binding vote cast has been @Furkam.  As I see it [2], Gedd Johnson and
> > Joshua Poore are committers ( not PMC ) of the incubator, so wouldn't
> cast
> > binding votes?
> >
> > Though, that also seems strange.  So, can you help me understand the
> > process?  As I am likely missing some docs/info somewhere?  Or, perhaps
> I'm
> > misunderstanding the acronyms.
> >
> > Thanks!
> > Austin
> >
> >
> >
> > [1]  https://incubator.apache.org/projects/flagon.html
> >
> > [2] http://home.apache.org/phonebook.html?pmc=incubator
> >
> > [3] https://incubator.apache.org/guides/ppmc.html#ppmc_and_binding_votes
> >
> >
> >
> > On Sat, May 7, 2022 at 5:26 PM Furkan KAMACI 
> wrote:
> >
> >> Hi,
> >>
> >> We have 3 binding votes (Joshua Poore, Gedd Johnson, Furkan KAMACI) and
> 1
> >> non-binding vote (Austin Bennett).
> >>
> >> So, the vote has passed in terms of the ASF rules.
> >>
> >> Kind Regards,
> >> Furkan KAMACI
> >>
> >> On Sun, May 8, 2022 at 3:21 AM Austin Bennett <
> whatwouldausti...@gmail.com
> >>>
> >> wrote:
> >>
> >>> At least 72 hours have passed :-)
> >>>
> >>> But ...  doesn't look like received 3 +1 votes from PPMC; was there
> >> enough
> >>> for this to pass?  I can look up but don't recall off head the
> incubating
> >>> project guidelines.
> >>>
> >>>
> >>>
> >>>
> >>> On Sat, May 7, 2022 at 3:52 PM Furkan KAMACI 
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> Is this voting closed or not?
> >>>>
> >>>> Kind Regards,
> >>>> Furkan KAMACI
> >>>>
> >>>> On Tue, May 3, 2022 at 10:04 PM Austin Bennett <
> >>>> whatwouldausti...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Based on what has been checked, it looks good to me, so +1 (
> >>> non-binding
> >>>>> ).
> >>>>>
> >>>>> A process questions to ensure things get covered, long term:
> >>>>>
> >>>>> * is there a concrete list for things actually desired to be checked
> >> as
> >>>>> part of release process ( I see some things, ex:
> >>>>> https://github.com/apache/incubator-flagon/tree/master/release and
> >>> some
> >>>>> info https://flagon.incubator.apache.org/releases/ and
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://cwiki.apache.org/confluence/display/FLAGON/UserALE.js+Release+Management+Procedure
> >>>>> but not an actual list of things we want to ensure are c

Re: [VOTE] Release Apache Flagon (Incubating) UserALE.js 2.3.0

[Austin Bennett]

Furkan,

Trying to understand the process, esp. understand PPMC, IPMC, and mentor
distinction.  I see you as a mentor [1], and look like for someone to be a
mentor, they must be  IPMC which you are [2] .

These comments are to understand ASF Process, and to ensure there are docs
( perhaps I'm failing to find, as I've only done a cursory search thus far
).

According to [3] "The only time when a PPMC member’s vote is binding is for
the addition of new PPMC members and committers. Release votes are only
binding for IPMC members." ... so that seems like for a release the only
binding vote cast has been @Furkam.  As I see it [2], Gedd Johnson and
Joshua Poore are committers ( not PMC ) of the incubator, so wouldn't cast
binding votes?

Though, that also seems strange.  So, can you help me understand the
process?  As I am likely missing some docs/info somewhere?  Or, perhaps I'm
misunderstanding the acronyms.

Thanks!
Austin



[1]  https://incubator.apache.org/projects/flagon.html

[2] http://home.apache.org/phonebook.html?pmc=incubator

[3] https://incubator.apache.org/guides/ppmc.html#ppmc_and_binding_votes



On Sat, May 7, 2022 at 5:26 PM Furkan KAMACI  wrote:

> Hi,
>
> We have 3 binding votes (Joshua Poore, Gedd Johnson, Furkan KAMACI) and 1
> non-binding vote (Austin Bennett).
>
> So, the vote has passed in terms of the ASF rules.
>
> Kind Regards,
> Furkan KAMACI
>
> On Sun, May 8, 2022 at 3:21 AM Austin Bennett  >
> wrote:
>
> > At least 72 hours have passed :-)
> >
> > But ...  doesn't look like received 3 +1 votes from PPMC; was there
> enough
> > for this to pass?  I can look up but don't recall off head the incubating
> > project guidelines.
> >
> >
> >
> >
> > On Sat, May 7, 2022 at 3:52 PM Furkan KAMACI 
> > wrote:
> >
> > > Hi,
> > >
> > > Is this voting closed or not?
> > >
> > > Kind Regards,
> > > Furkan KAMACI
> > >
> > > On Tue, May 3, 2022 at 10:04 PM Austin Bennett <
> > > whatwouldausti...@gmail.com>
> > > wrote:
> > >
> > > > Based on what has been checked, it looks good to me, so +1 (
> > non-binding
> > > > ).
> > > >
> > > > A process questions to ensure things get covered, long term:
> > > >
> > > > * is there a concrete list for things actually desired to be checked
> as
> > > > part of release process ( I see some things, ex:
> > > > https://github.com/apache/incubator-flagon/tree/master/release and
> > some
> > > > info https://flagon.incubator.apache.org/releases/ and
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/FLAGON/UserALE.js+Release+Management+Procedure
> > > > but not an actual list of things we want to ensure are covered by a
> > > machine
> > > > or human )?
> > > >
> > > > Also, I don't recall -- Does the project have a targeted release
> cycle
> > (
> > > > ex: every month, quarter, etc ), or just cutting releases as desired?
> > > That
> > > > might help inform what all checks are worth automating.
> > > >
> > > >
> > > > On Tue, May 3, 2022 at 11:43 AM Joshua Poore  >
> > > > wrote:
> > > >
> > > > > Bump!
> > > > >
> > > > > > On Apr 23, 2022, at 1:32 PM, Joshua Poore  >
> > > > > wrote:
> > > > > >
> > > > > > Reminder! Please VOTE for this release!!
> > > > > >
> > > > > > Joshua Poore
> > > > > >
> > > > > >
> > > > > >> On Apr 13, 2022, at 5:16 PM, Furkan KAMACI <
> > furkankam...@gmail.com>
> > > > > wrote:
> > > > > >>
> > > > > >> Hi,
> > > > > >>
> > > > > >> +1 from me.
> > > > > >>
> > > > > >> I checked:
> > > > > >>
> > > > > >> - Incubating in name
> > > > > >> - DISCLAIMER exists
> > > > > >> - LICENSE and NOTICE are fine
> > > > > >> - No unexpected binary files
> > > > > >> - Checked PGP signatures
> > > > > >> - Checked checksums
> > > > > >> - Code compiles and tests successfully run
> > > > > >>
> > > > > >> Kind Regards,
> > > > > >> Furkan KAMACI
> > > > > >>
> > > > 

Re: [VOTE] Release Apache Flagon (Incubating) UserALE.js 2.3.0

[Austin Bennett]

At least 72 hours have passed :-)

But ...  doesn't look like received 3 +1 votes from PPMC; was there enough
for this to pass?  I can look up but don't recall off head the incubating
project guidelines.




On Sat, May 7, 2022 at 3:52 PM Furkan KAMACI  wrote:

> Hi,
>
> Is this voting closed or not?
>
> Kind Regards,
> Furkan KAMACI
>
> On Tue, May 3, 2022 at 10:04 PM Austin Bennett <
> whatwouldausti...@gmail.com>
> wrote:
>
> > Based on what has been checked, it looks good to me, so +1 ( non-binding
> > ).
> >
> > A process questions to ensure things get covered, long term:
> >
> > * is there a concrete list for things actually desired to be checked as
> > part of release process ( I see some things, ex:
> > https://github.com/apache/incubator-flagon/tree/master/release and some
> > info https://flagon.incubator.apache.org/releases/ and
> >
> >
> https://cwiki.apache.org/confluence/display/FLAGON/UserALE.js+Release+Management+Procedure
> > but not an actual list of things we want to ensure are covered by a
> machine
> > or human )?
> >
> > Also, I don't recall -- Does the project have a targeted release cycle (
> > ex: every month, quarter, etc ), or just cutting releases as desired?
> That
> > might help inform what all checks are worth automating.
> >
> >
> > On Tue, May 3, 2022 at 11:43 AM Joshua Poore 
> > wrote:
> >
> > > Bump!
> > >
> > > > On Apr 23, 2022, at 1:32 PM, Joshua Poore 
> > > wrote:
> > > >
> > > > Reminder! Please VOTE for this release!!
> > > >
> > > > Joshua Poore
> > > >
> > > >
> > > >> On Apr 13, 2022, at 5:16 PM, Furkan KAMACI 
> > > wrote:
> > > >>
> > > >> Hi,
> > > >>
> > > >> +1 from me.
> > > >>
> > > >> I checked:
> > > >>
> > > >> - Incubating in name
> > > >> - DISCLAIMER exists
> > > >> - LICENSE and NOTICE are fine
> > > >> - No unexpected binary files
> > > >> - Checked PGP signatures
> > > >> - Checked checksums
> > > >> - Code compiles and tests successfully run
> > > >>
> > > >> Kind Regards,
> > > >> Furkan KAMACI
> > > >>
> > > >>> On Wed, Apr 13, 2022 at 11:54 PM Joshua Poore 
> > > wrote:
> > > >>>
> > > >>> REMINDER PPMC, Mentors—please don’t forget to VOTE for this
> release!!
> > > >>>
> > > >>> This release contains some great PR work from our community!!!
> > > >>>
> > > >>>>> On Apr 11, 2022, at 12:05 PM, Gedd Johnson  >
> > > wrote:
> > > >>>>
> > > >>>> [x] +1, let's get it released!!!
> > > >>>>
> > > >>>> [x ] Build and Unit Tests Pass
> > > >>>> [x ] Integration Tests Pass
> > > >>>> [x ] "Incubating" in References to Project and Distribution File
> > Names
> > > >>>> [x ] Signatures and Hashes Match Keys
> > > >>>> [x ] DISCLAIMER, LICENSE, and NOTICE Files in Source and Binary
> > > Release
> > > >>>> Packages
> > > >>>> [x ] DISCLAIMER, LICENSE, and NOTICE are consistent with ASF and
> > > >>> Incubator
> > > >>>> Policy
> > > >>>> [x ] CHANGELOG included with release distribution
> > > >>>> [x ] All Source Files Have Correct ASF Headers
> > > >>>> [x ] No Binary Files in Source Release Packages
> > > >>>>
> > > >>>> - Gedd Johnson
> > > >>>>
> > > >>>> On Sun, Apr 10, 2022 at 12:38 PM Joshua Poore  >
> > > >>> wrote:
> > > >>>>
> > > >>>>> +1 (PPMC)
> > > >>>>>
> > > >>>>> I checked:
> > > >>>>>
> > > >>>>> [ x ] Build and Unit Tests Pass
> > > >>>>> [ x ] Integration Tests Pass (Example Page, Webpack (NPM), React
> > > (NPM)
> > > >>>>> [ x ] "Incubating" in References to Project and Distribution File
> > > Names
> > > >>>>> [ x ] Signatures and Hashes Match Keys
> > > >>>>> [ x ] DISCLAIMER, LICENSE, and NOTICE Files in 

Re: [VOTE] Release Apache Flagon (Incubating) UserALE.js 2.3.0

[Austin Bennett]

Based on what has been checked, it looks good to me, so +1 ( non-binding
).

A process questions to ensure things get covered, long term:

* is there a concrete list for things actually desired to be checked as
part of release process ( I see some things, ex:
https://github.com/apache/incubator-flagon/tree/master/release and some
info https://flagon.incubator.apache.org/releases/ and
https://cwiki.apache.org/confluence/display/FLAGON/UserALE.js+Release+Management+Procedure
but not an actual list of things we want to ensure are covered by a machine
or human )?

Also, I don't recall -- Does the project have a targeted release cycle (
ex: every month, quarter, etc ), or just cutting releases as desired?  That
might help inform what all checks are worth automating.


On Tue, May 3, 2022 at 11:43 AM Joshua Poore  wrote:

> Bump!
>
> > On Apr 23, 2022, at 1:32 PM, Joshua Poore 
> wrote:
> >
> > Reminder! Please VOTE for this release!!
> >
> > Joshua Poore
> >
> >
> >> On Apr 13, 2022, at 5:16 PM, Furkan KAMACI 
> wrote:
> >>
> >> Hi,
> >>
> >> +1 from me.
> >>
> >> I checked:
> >>
> >> - Incubating in name
> >> - DISCLAIMER exists
> >> - LICENSE and NOTICE are fine
> >> - No unexpected binary files
> >> - Checked PGP signatures
> >> - Checked checksums
> >> - Code compiles and tests successfully run
> >>
> >> Kind Regards,
> >> Furkan KAMACI
> >>
> >>> On Wed, Apr 13, 2022 at 11:54 PM Joshua Poore 
> wrote:
> >>>
> >>> REMINDER PPMC, Mentors—please don’t forget to VOTE for this release!!
> >>>
> >>> This release contains some great PR work from our community!!!
> >>>
> > On Apr 11, 2022, at 12:05 PM, Gedd Johnson 
> wrote:
> 
>  [x] +1, let's get it released!!!
> 
>  [x ] Build and Unit Tests Pass
>  [x ] Integration Tests Pass
>  [x ] "Incubating" in References to Project and Distribution File Names
>  [x ] Signatures and Hashes Match Keys
>  [x ] DISCLAIMER, LICENSE, and NOTICE Files in Source and Binary
> Release
>  Packages
>  [x ] DISCLAIMER, LICENSE, and NOTICE are consistent with ASF and
> >>> Incubator
>  Policy
>  [x ] CHANGELOG included with release distribution
>  [x ] All Source Files Have Correct ASF Headers
>  [x ] No Binary Files in Source Release Packages
> 
>  - Gedd Johnson
> 
>  On Sun, Apr 10, 2022 at 12:38 PM Joshua Poore 
> >>> wrote:
> 
> > +1 (PPMC)
> >
> > I checked:
> >
> > [ x ] Build and Unit Tests Pass
> > [ x ] Integration Tests Pass (Example Page, Webpack (NPM), React
> (NPM)
> > [ x ] "Incubating" in References to Project and Distribution File
> Names
> > [ x ] Signatures and Hashes Match Keys
> > [ x ] DISCLAIMER, LICENSE, and NOTICE Files in Source and Binary
> Release
> > Packages
> > [ x ] DISCLAIMER, LICENSE, and NOTICE are consistent with ASF and
> > Incubator Policy
> > [ x ] CHANGELOG included with release distribution
> > [ x ] New source code (React app, OpenTelemetry Ex) has compatible
> > licenses (ALv2, MIT)
> > [ x ] All Source Files Have Correct ASF Headers (ran RAT tool: only
> > .gitignore and .babelrc (json) exclude headers)
> > [ x ] No Binary Files in Source Release Packages (except for
> supporting
> > .png files)
> >
> >> On Apr 10, 2022, at 1:36 PM, Joshua Poore 
> wrote:
> >>
> >> Please VOTE on the Apache Flagon (Incubating) UserALE.js 2.3.0
> Release
> > Candidate # 01.
> >>
> >> About Flagon: http://flagon.incubator.apache.org/
> >>
> >> This Minor release includes:
> >>
> >> Fixes issue in autostart configurations and start(), stop() export
> >>> usage
> >> Adds additional unit tests for autostart configurations
> >> Adds React App.js example/test utility
> >> Adds additional examples (non-user log examples)
> >> Minor updates to update deprecated downstream dev dependencies
> >> Minor changes to documentation, updated examples
> >>
> >> Resolved issues:
> > https://github.com/apache/incubator-flagon-useralejs/projects/9
> >>
> >> Git source tag (566b279;
> >
> >>>
> https://github.com/apache/incubator-flagon-useralejs/releases/tag/2.3.0-RC-01
> > )
> >>
> >> Staging repo:
> https://dist.apache.org/repos/dist/dev/incubator/flagon/
> >>
> >> Source Release Artifacts:
> >
> >>>
> https://dist.apache.org/repos/dist/dev/incubator/flagon/apache-flagon-useralejs-incubating-2.3.0-RC-01/
> >>
> >> PGP release keys (signed using F9374FAE3FCADF6E):
> > https://dist.apache.org/repos/dist/release/incubator/flagon/KEYS
> >>
> >> Link to Successful CI Build:
> > https://github.com/apache/incubator-flagon-useralejs/runs/5958813955
> >>
> >> Reference to the UserALE.js testing framework to assist in your unit
> >>> and
> > integration tests:
> >
> >>>
> https://cwiki.apache.org/confluence/display/FLAGON/UserALE.js+Release+Management+Procedure
> >>
> >> I 

Re: [VOTE] New PPMC Candidate: Gedd Johnson (@UncleGedd)

[Austin Bennett]

+1 (non-binding, etc)

Though... should this be public/on-dev-list?

On Thu, Mar 18, 2021 at 6:00 PM Joshua Poore  wrote:

> +1 from me (Flagon PPMC)
>
> > On Mar 18, 2021, at 8:59 PM, Joshua Poore  wrote:
> >
> > Hello,
> >
> > I am calling a VOTE to add Gedd Johnson (@UncleGedd) to the Apache
> Flagon (Incubating) Podling Project Management Committee PPMC.
> >
> > Gedd originates from one of our key user groups and has an appreciation
> for our project in an application context.
> > Gedd’s interest in the project is authentic—working with Flagon is no
> longer part of his every day duties
> > He has already contributed a number of valuable features to UserALE.js
> > He is interested in contributing to the design, development, and
> maintenance of ongoing developments (e.g., Distill)
> > He has already shown a willingness to participate in the community and
> work collaboratively
> > He shows willingness and interest to address issues that are not-so-fun
> as well as more complex tasks
> > His PR’s have been easy to evaluate, he takes critical feedback well,
> and his code is elegant
> >
> > For these reasons and for his willingness to contribute to the project
> in a manner consistent with the Independent Contributor License Agreement
> (which he has reviewed), I am nominating Gedd as a member of the PPMC and
> as a committer for the ASF.
> >
> > The VOTE ends one week from today (2021-03-24)
> >
> > The RESULT will be carried over to the IPMC.
> >
> > See voting guidelines at https://community.apache.org/newcommitter.html
> 
> >
> > Thanks,
> >
> > Josh
>
>

Re: Introduction @UncleGedd

[Austin Bennett]

In general more testing == better (at least until extreme).

Glad for that topic to be pushed.  And, welcome, @Gedd!

(from someone that mostly lurks/follows the community, rather than doing
much by way of actually contributing thus far!).



On Mon, Mar 15, 2021 at 8:35 AM Rob Foley  wrote:

> Sounds reasonable to me. There might be some tricky bits regarding
> certain mouse events, since Cypress doesn't let you do things like
> "hover", for example, without writing some vaguely hacky jQuery. Overall
> sounds helpful though.
>
> Rob
>
> On 3/15/2021 9:40 AM, Joshua Poore wrote:
> > Rob!
> >
> > What’s up!?
> >
> > I see where you’re coming from on Cypress—UserALEjs is not a user facing
> app. However, @UncleGedd is the second current or frmr user to think
> Cypress is a good idea. For my part, I see two possible, but not mutually
> exclusive benefits:
> >
> > 1. The user community Gedd is coming from rely more on UserALEjs’s
> custom logging and filtering capabilities than they do the ‘raw” log
> stream. Being careful with words: users are developers working with
> UserALEjs in their projects and/or data scientists analyzing UserALEjs
> data. Unit tests can/do flex aspects of our exports/API, but better testing
> will involve more sophisticated usage of custom logs, mapping statements,
> filters and option params. If Cypress proves to be an easy and efficient
> way of automating the integration tests I do with say our ./example
> index.html, I think it’s worth considering. Else we can think of beefing up
> unit tests.
> >
> > 2. Even if we don’t do a “full tilt” Cypress integration for UserALEjs,
> it would probably be useful to put together some examples somewhere and
> maybe do a screen-cap movie of how people can include userale payloads in
> their own apps Cypress testing. Especially, those that do a lot of
> filtering, mapping, and custom logging, it might be nice to provide tips
> and know-how for how to validate which logs are being produced, whether
> they have the desired structure, and whether their values are in the right
> format. Code coverage in testing is important for a lot of organizations, I
> think we would do well by users to scaffold them a bit in helping them test
> the code they are adding to support logging.
> >
> > I’m willing to see what kinds of examples we get for Cypress and raise
> for discussion how deeply or how we consider integrating them into the
> project. Sound reasonable? We can continue discussion on another thread.
> >
> > Josh
> >
> >> On Mar 14, 2021, at 1:09 PM, Rob Foley  wrote:
> >>
> >> Hi Gedd,
> >>
> >> Thanks for contributing. If you have any questions about Userale or any
> of its design decisions, feel free to reach out. Ditto on the Zoom/etc.
> front.
> >>
> >> @poorejc wrt Cypress, I've gotten a decent bit of experience writing
> Cypress tests in the last year or so. I don't quite see (at first) how it
> fits into Flagon-land. Can you tell me a bit more about that (another
> thread is fine).
> >>
> >> Regards,
> >> Rob
> >>
> >> On 3/13/2021 8:57 PM, Joshua Poore wrote:
> >>> Hi Gedd,
> >>>
> >>> Thanks again for the great contributions! We are always looking for
> new committers, especially those that were (are) users! Very familiar with
> the Kessel Run crowd. Maybe over a zoom or coffee we can catch up about
> that.
> >>>
> >>> I’ve added a few new tickets in our Journey Tests project. Over the
> next week, I’ll be digging into Cypress (seems what users want to do, and
> you!) and doing a little bug-hunting.
> >>>
> >>> Flagon is a great place to start your exploration of open-source—we’re
> a small community, and we’re just about to start a major refactor on our
> key analytical product (distill) to support python data pipelines with
> useralejs data. We might even explore Apache Superset integration. We’re
> also discussing graduation from the Apache Incubator, meaning that we would
> graduate as or to a top level project. So, it’s a really interesting
> project and time in that projects’ history to be involved. You can see how
> things are done at Apache and perhaps become an apache committer/member and
> get involved in a variety of projects. Some of our mentors for examples
> have had illustrious careers on projects like Solr and Tika. Good entry
> point for lots of interesting madness :)
> >>>
> >>> poorejc
> >>>
>  On Mar 13, 2021, at 11:57 AM, Gedd Johnson 
> wrote:
> 
>  Hello!
> 
>  My name is Gedd Johnson (UncleGedd  on
>  Github). I am currently a military officer working with a group called
>  Kessel Run. My previous team and I forked the Userale repo and made a
>  couple mods to fit our needs at the time. Since then, I have moved on
> to
>  other endeavors but wanted to get involved in the open source
> community; I
>  thought the Flagon project would be a good place to start.
> 
>  I'm actually on my way out of the military and have ample time to
> spare at

Re: [VOTE] Re: Deprecate/Retire Old UserALE projects

[Austin Bennett]

+1 -- based on rationale's listed.




On Sun, Jan 26, 2020 at 8:55 PM Joshua Poore  wrote:
>
> Hi Folks,
>
> I’m sorry for the delay. I’m going to call this to a VOTE. We’re going to go 
> with a Lazy Consensus on this one, meaning if “silence is acceptance”.
>
> The VOTE is to Deprecate/Retire Old UserALE projects:
>
> 1. UserALE v3
> 2. UserALE.pyqt5
>
> vote as follows:
>
> [+1] Let them sail forth into oblivion, or another repo
> [ 0 ] Same as not saying anything
> [ -1] Storage is cheap, broh!
>
> The VOTE will last for 72 hours.
>
> +1 for me.
> +1 carried forward from lewismc (below)
>
> > On Jan 15, 2020, at 11:08 PM, lewis john mcgibbney  
> > wrote:
> >
> > +1 please carry through to VOTE
> >
> > On Wed, Jan 15, 2020 at 19:10  wrote:
> >
> >>
> >> dev Digest 16 Jan 2020 03:10:49 - Issue 336
> >>
> >> Topics (messages 3177 through 3177)
> >>
> >> [DISCUSS] Deprecate/Retire Old UserALE projects
> >>3177 by: Joshua Poore
> >>
> >> Administrivia:
> >>
> >> -
> >> To post to the list, e-mail: dev@flagon.apache.org
> >> To unsubscribe, e-mail: dev-digest-unsubscr...@flagon.apache.org
> >> For additional commands, e-mail: dev-digest-h...@flagon.apache.org
> >>
> >> --
> >>
> >>
> >>
> >>
> >> -- Forwarded message --
> >> From: Joshua Poore 
> >> To: dev@flagon.apache.org
> >> Cc:
> >> Bcc:
> >> Date: Wed, 15 Jan 2020 22:10:45 -0500
> >> Subject: [DISCUSS] Deprecate/Retire Old UserALE projects
> >> Hi Folks,
> >>
> >> I’d like to welcome discussion about deprecating and removing old UserALE
> >> projects from our Apache Flagon parent project, which are not currently
> >> maintained. These include:
> >>
> >> 1. UserALE v3 - Rationale: predecessor of UserALE.js. This conformed more
> >> of js block-level implementation of UserALE as an API. UserALE.js was
> >> designed for script tag deployment removing the need for block style
> >> embeddings. Some time ago we reintroduced the ability to modify logs and
> >> customize those at the block-level. In other words, this version of UserALE
> >> is completely irrelevant.
> >>
> >> 2. UserALE.pyqt5 - Rationale: presently unsupported and unmaintained.
> >> Likely deprecated.
> >>
> >> Please feel free to DISCUSS - raise any concerns, questions, or the like.
> >> Discussion will be open for 72 hours, at which time I will call a VOTE. As
> >> this is not a release VOTE.
> >>
> >> Thanks and more to come!
> >>
> >> Josh
> >>
> > --
> > http://home.apache.org/~lewismc/
> > http://people.apache.org/keys/committer/lewismc
>

Re: [VOTE] Move UserALE.js and DISTILL Tickets to GitHub issues

[Austin Bennett]

+1 -- (rational) GitHub issues are easy

On Sun, Jan 26, 2020 at 9:03 PM Joshua Poore  wrote:
>
> Hi Folks,
>
> I’m moving straight to a VOTE on this one.
>
> Some users have expressed trepidation on pushing issues/tickets through JIRA. 
> Specifically, they find our labels, components, and issue search (which 
> exposes them to all Apache issues) daunting.
>
> I’d like to reduce barriers to entry and move our UserALE.js and Distill 
> Issues to GitHub Issues (INFRA taught me how). Issues and Boards can exist on 
> GitHub in a single place.
>
> I’m calling a lazy consensus VOTE on this, given that we’re either in a very 
> good place (UserALE.js) or refactoring these products (DISTILL). I’ve also 
> raised this numerous times before and have been met with no controversy.
>
> vote as follows:
>
> [+1] Single point of entry to code, issues, and boards sounds great!
> [ 0 ] Same as not saying anything
> [ -1] Pump the breaks, lets discuss more
>
> The VOTE will last for 72 hours.
>
> +1 for me

Re: Some broad questions!?

[Austin Bennett]

That's what I am hoping to understand -- making full use of the data :-)

It certainly goes beyond business analytics, funnels, heatmaps.



On Sun, Jan 26, 2020, 8:47 PM Joshua Poore  wrote:

> RE Elastic
>
> Historically, we chose it for two reasons:
>
> 1. We wanted to discriminate ourselves with very rich data (also verbose).
> Lucene back-ends made sense in supporting a query language that would allow
> making full use of that data.
>
> 2. Kibana is great and greatly reduces the overhead in supporting
> front-end dashboard. It has a great feel to it, its highly customizable,
> and a plugin culture is growing.
>
> At the end of the day, absolutely nothing is stopping anyone from shipping
> logs to another back-end. I did get a ticket the other day to support a DAL…
>
> Best,
>
> Josh
>
> > On Jan 25, 2020, at 8:58 PM, Austin Bennett 
> wrote:
> >
> > Great, thanks, Josh!  (no worries on timing).
> >
> > A longer term nagging question, that still seems relevant -- Are there
> > any specific reasons that you've anchored on (what seems to only be)
> > Elastic as a backend?  Naively, it seems could view Flagon as a way to
> > produce data, that then could go through a message queue and to one or
> > many different backends depending on desired consumption patterns.  Is
> > this more a matter of convenience - Elastic suffices and therefore
> > devote attention elsewhere -- or because Elastic does something
> > particularly unique given the context of Flagon.
> >
> > Cheers,
> > Austin
> >
> > On Sat, Jan 25, 2020 at 5:15 PM Joshua Poore  wrote:
> >>
> >> Austin—good to hear from you.
> >>
> >> Apologies for the delay. Have been working with users last few days and
> wanted to give your email the appropriate attention—some good questions.
> >>
> >> Replies inline
> >>
> >>> On Jan 22, 2020, at 4:31 PM, Austin Bennett <
> whatwouldausti...@gmail.com> wrote:
> >>>
> >>> Hi Flagon,
> >>>
> >>> Looking for info:
> >>>
> >>> * I don't see much on analysing the data that gets collected.  Very
> >>> interested in understanding the types of insights that people are
> >>> deriving.  Pointers very welcome (esp. to specific use cases).
> >>> Apologies if missing something obvious…
> >>
> >> Most of our users are interested purely in business analytics. Mostly
> we get requests for guidance on Funnel’s and Heatmaps. We have a crude
> funnel mocked in a Kibana dashboard which you can find in our Business
> Analytics Dashboard here:
> https://github.com/apache/incubator-flagon/tree/master/docker/kibana/6.8.2/Saved%20Objects
> <
> https://github.com/apache/incubator-flagon/tree/master/docker/kibana/6.8.2/Saved%20Objects
> >
> >>
> >> Of course you’ll need to set up an Elastic instance to use it. You can
> find a sandbox ELK project in the parent directory:
> https://github.com/apache/incubator-flagon/tree/master/docker <
> https://github.com/apache/incubator-flagon/tree/master/docker>
> >>
> >> In the Kibana visualizations and dashboards you’ll find a number of
> other viz elements that derive directly from user asks. You’ll need to
> customize a little bit given you’ll have different values from your logs,
> but there is a LOT of content there.
> >>
> >> We are working on a python package, too, for more advanced behavioral
> analytics. We haven’t been able to devote much time to it as we’ve been
> working on tightening up UserALE, but we’ve done some WIP experiments with
> an analytic pipeline (seriously, very much a WIP):
> https://github.com/apache/incubator-flagon-distill/tree/distill_toolkit_refactor/WIP-distill_examples
> <
> https://github.com/apache/incubator-flagon-distill/tree/distill_toolkit_refactor/WIP-distill_examples
> >
> >>>
> >>> * Additionally, is JIRA the best place to understand pinpoints and
> >>> areas for improvement?  Esp. upon recognizing value of using the data,
> >>> would be very interested in using my backend/data-eng experience to
> >>> help develop and increase the stability of system for high-scale
> >>> production use (sounds like successfully used places already).
> >>
> >> For now, yes, JIRA is the best place. We really do keep track of things
> well in JIRA. Most of the tickets in there are backlog ideas, wishes, task.
> We pull from the backlog into releases and track that way. In the very near
> term, we’ll be ditching JIRA and moving to Git Projects. JIRA seems to be a
> wall for our u

Re: Some broad questions!?

[Austin Bennett]

Great, thanks, Josh!  (no worries on timing).

A longer term nagging question, that still seems relevant -- Are there
any specific reasons that you've anchored on (what seems to only be)
Elastic as a backend?  Naively, it seems could view Flagon as a way to
produce data, that then could go through a message queue and to one or
many different backends depending on desired consumption patterns.  Is
this more a matter of convenience - Elastic suffices and therefore
devote attention elsewhere -- or because Elastic does something
particularly unique given the context of Flagon.

Cheers,
Austin

On Sat, Jan 25, 2020 at 5:15 PM Joshua Poore  wrote:
>
> Austin—good to hear from you.
>
> Apologies for the delay. Have been working with users last few days and 
> wanted to give your email the appropriate attention—some good questions.
>
> Replies inline
>
> > On Jan 22, 2020, at 4:31 PM, Austin Bennett  
> > wrote:
> >
> > Hi Flagon,
> >
> > Looking for info:
> >
> > * I don't see much on analysing the data that gets collected.  Very
> > interested in understanding the types of insights that people are
> > deriving.  Pointers very welcome (esp. to specific use cases).
> > Apologies if missing something obvious…
>
> Most of our users are interested purely in business analytics. Mostly we get 
> requests for guidance on Funnel’s and Heatmaps. We have a crude funnel mocked 
> in a Kibana dashboard which you can find in our Business Analytics Dashboard 
> here: 
> https://github.com/apache/incubator-flagon/tree/master/docker/kibana/6.8.2/Saved%20Objects
>  
> <https://github.com/apache/incubator-flagon/tree/master/docker/kibana/6.8.2/Saved%20Objects>
>
> Of course you’ll need to set up an Elastic instance to use it. You can find a 
> sandbox ELK project in the parent directory: 
> https://github.com/apache/incubator-flagon/tree/master/docker 
> <https://github.com/apache/incubator-flagon/tree/master/docker>
>
> In the Kibana visualizations and dashboards you’ll find a number of other viz 
> elements that derive directly from user asks. You’ll need to customize a 
> little bit given you’ll have different values from your logs, but there is a 
> LOT of content there.
>
> We are working on a python package, too, for more advanced behavioral 
> analytics. We haven’t been able to devote much time to it as we’ve been 
> working on tightening up UserALE, but we’ve done some WIP experiments with an 
> analytic pipeline (seriously, very much a WIP): 
> https://github.com/apache/incubator-flagon-distill/tree/distill_toolkit_refactor/WIP-distill_examples
>  
> <https://github.com/apache/incubator-flagon-distill/tree/distill_toolkit_refactor/WIP-distill_examples>
> >
> > * Additionally, is JIRA the best place to understand pinpoints and
> > areas for improvement?  Esp. upon recognizing value of using the data,
> > would be very interested in using my backend/data-eng experience to
> > help develop and increase the stability of system for high-scale
> > production use (sounds like successfully used places already).
>
> For now, yes, JIRA is the best place. We really do keep track of things well 
> in JIRA. Most of the tickets in there are backlog ideas, wishes, task. We 
> pull from the backlog into releases and track that way. In the very near 
> term, we’ll be ditching JIRA and moving to Git Projects. JIRA seems to be a 
> wall for our users. For now, feel free to jump in and add tickets labeled by 
> component:
>
> For UserALE and log pipeline add tickets to: 
> https://issues.apache.org/jira/browse/FLAGON-483?jql=project%20%3D%20FLAGON%20AND%20component%20%3D%20UserALE.js
>  
> <https://issues.apache.org/jira/browse/FLAGON-483?jql=project%20=%20FLAGON%20AND%20component%20=%20UserALE.js>
>
> For Analytical asks, add tickets to: 
> https://issues.apache.org/jira/browse/FLAGON-464?jql=project%20%3D%20FLAGON%20AND%20component%20%3D%20Distill
>  
> <https://issues.apache.org/jira/browse/FLAGON-464?jql=project%20=%20FLAGON%20AND%20component%20=%20Distill>
>
> For Stack/back-end (ELK) improvements, add tickets to: 
> https://issues.apache.org/jira/browse/FLAGON-466?jql=project%20%3D%20FLAGON%20AND%20component%20%3D%20stack
>  
> <https://issues.apache.org/jira/browse/FLAGON-466?jql=project%20=%20FLAGON%20AND%20component%20=%20stack>
>
> Every commit we make, traces to a ticket. However, JIRA feels unwieldy for a 
> lot of users. Feel free to add to JIRA, I will migrate to GIt Projects, when 
> we make our move.
> >
> > * Lastly, how would y'all characterize the docs vs state of the code
> > (is it believed things are well documented and not much drift -- docs
> > tend to lag behind).  The reposit

Some broad questions!?

[Austin Bennett]

Hi Flagon,

Looking for info:

* I don't see much on analysing the data that gets collected.  Very
interested in understanding the types of insights that people are
deriving.  Pointers very welcome (esp. to specific use cases).
Apologies if missing something obvious...

* Additionally, is JIRA the best place to understand pinpoints and
areas for improvement?  Esp. upon recognizing value of using the data,
would be very interested in using my backend/data-eng experience to
help develop and increase the stability of system for high-scale
production use (sounds like successfully used places already).

* Lastly, how would y'all characterize the docs vs state of the code
(is it believed things are well documented and not much drift -- docs
tend to lag behind).  The repository is not changing rapidly, so seems
like would be a slow drift if it has occurred.

Thanks,
Austin

Re: FLOGOS! Plz review logos

[Austin Bennett]

#2 looks super cool; still don't have a great sense of what project is
trying to do as to whether sufficiently in-line.

On Sat, Sep 28, 2019 at 9:38 PM Joshua C. Poore  wrote:

> Hi Folks,
>
> I've been doing some sketches on Flagon logos. Probably we'll want a few
> for various things, but we need a primary logo to use on Twitter,
> website, etc., etc. I can't get them to go through unscathed through the
> dev lists. You can find them at this link:
> https://cwiki.apache.org/confluence/display/FLAGON/Flagon+Logos
>
> These are just sketches I made. I have someone (probably) who can finish
> them off, touch them up for us and make them web-ready. Of course, if
> someone from the community would like to do that, I'll take it! Just
> remember that the final will be copyright ASF.
>
> I call the first: FlagLorean. Was inspired by Back to the Future and the
> old ORION films logo
> (
> https://www.google.com/search?q=orion+pictures=1C1CHBF_enUS863US863=lnms=isch=X=0ahUKEwj-4srQlvXkAhWOdd8KHXWgCfYQ_AUIEygC=1368=770#imgrc=NOPjZ1AuCpmMMM:).
>
> I wanted a throwback. I imagine this would have a metallic finish with
> some color inlets (negotiable). I call the second: FlagonSaveTheQueen.
> It speaks for itself, but was inspired with by the Pistols and Norse
> runes. For both, I wanted something that we could crop up and use for a
> web extension icon, which would be recognizable. I liked the idea of
> using the "ON" in Flagon as our icon. Both of these logos would give us
> something interesting to put in people's browsers, in that regard.
>
> I'm looking for feedback about what people would like to see on the
> website, wrt to a Logo. Whether either of these are moving in an
> interesting direction. Again, we need one primary logo, but a few others
> for Merch/Giveaways. FlagonSaveTheQueen will make a bad-ass patch, for
> example. Anyway, open to feedback and any other ideas. The sooner we
> pick some logos, the sooner we can get some cool shirts made :)
>
> Best,
>
> Josh
>
>
>
>

Re: Flagon!

[Austin Bennett]

Hi Joshua,

I will try to dig into the list history as well as codebase.  It seems
potentially quite useful.  As to ideas: haven't worked enough to
distinguish what it actually is from what it could be.

If you/others are willing to hop on a call would love to discuss and learn
more at some point (after this week's conference).

Cheers,
Austin


On Sun, Sep 8, 2019 at 5:49 PM Joshua Poore  wrote:

> Thanks! Always getting a little cooler... would love to hear any ideas you
> have!
>
> Unfortunately, we’re not at this con. Next one though...
>
> Joshua Poore
>
>
> > On Sep 8, 2019, at 8:33 PM, Austin Bennett 
> wrote:
> >
> > Looks super cool.
> >
> > I'm on the plane heading to ApacheCon -- anyone from the community around
> > Vegas this week?
>
>

Flagon!

[Austin Bennett]

Looks super cool.

I'm on the plane heading to ApacheCon -- anyone from the community around
Vegas this week?