[GitHub] [flagon] brucearctor commented on issue #27: Remove "incubating"

[via GitHub]

brucearctor commented on issue #27:
URL: https://github.com/apache/flagon/issues/27#issuecomment-1585987780

   https://github.com/apache/flagon/assets/5032356/16971eb1-ce8d-46a5-9684-a3c2be341107;>
   
   
   Notice incubating also appears in the link on the GH repos.  


-- 
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

[GitHub] [flagon] poorejc commented on issue #27: Remove "incubating"

[via GitHub]

poorejc commented on issue #27:
URL: https://github.com/apache/flagon/issues/27#issuecomment-1585842666

   Progress tracker:
   site/_docs
   - [x] UserALE.js
   - [ ] Distill
   - [ ] Tap
   - [ ] Update Apache Logo


-- 
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

[GitHub] [flagon] asfgit merged pull request #29: Update Gemfile

[via GitHub]

asfgit merged PR #29:
URL: https://github.com/apache/flagon/pull/29


-- 
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]

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 ,
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?
>
>

[GitHub] [flagon] poorejc opened a new issue, #31: Split 'Flagon' repo into 2 to make for easier site builds

[via GitHub]

poorejc opened a new issue, #31:
URL: https://github.com/apache/flagon/issues/31

   Create new repo and rename flagon-website. Maintain site assets in different 
repo than integrations.
   
   See: https://lists.apache.org/thread/lmvpfg4nvlswb6z0j71hq5byc3jmyod8


-- 
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

[GitHub] [flagon] poorejc opened a new issue, #30: Ruby versioning issue in Site build

[via GitHub]

poorejc opened a new issue, #30:
URL: https://github.com/apache/flagon/issues/30

   It looks like there is an issue in site dependencies that coerce Ruby 2.5 to 
run which breaks build. May be issue in RUBY_VERSION assignment. See below:
   
   `
=> ERROR [ 4/12] RUN bundle install 

   8.4s
   --   


> [ 4/12] RUN bundle install:   


   #0 4.336 Fetching gem metadata from https://rubygems.org/


   #0 8.006 Fetching gem metadata from https://rubygems.org/.   


   #0 8.039 Resolving dependencies...   


   #0 8.232 public_suffix-5.0.0 requires ruby version >= 2.6, which is 
incompatible with the
   #0 8.232 current version, ruby 2.5.1p57
   --
   Dockerfile:7
   
  5 | COPY Gemfile* /tmp/
  6 | WORKDIR /tmp
  7 | >>> RUN bundle install
  8 | 
  9 | ENV app /app
   
   ERROR: failed to solve: process "/bin/sh -c bundle install" did not complete 
successfully: exit code: 5
   (base) jpoore@MacBook-Pro-2 site % 
   `
   Active version of Ruby I'm running (via rbenv):
   
   `
   (base) jpoore@MacBook-Pro-2 site % ruby -v
   ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin22]
   `
   Confirmed that 2.5 isn't even installed on computer...


-- 
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

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

[via GitHub]

poorejc commented on PR #29:
URL: https://github.com/apache/flagon/pull/29#issuecomment-1585514138

   Culprit is either something in the public_suffix library or we have 
something coercing Ruby version to v 2.5 in the code and it's superceding my 
local and global settings for Ruby. I can get this branch to build if I regress 
Public_Suffix to 4.0.1. But just doesn't make sense--I'm guessing we have some 
weird setting that's set globally. Lame. I'll have to return to it later this 
weekend.


-- 
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

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

[via GitHub]

poorejc commented on PR #29:
URL: https://github.com/apache/flagon/pull/29#issuecomment-1585506877

   So, the last PR from a Dependabot on Master might be the culprit--I can't 
build your branch or master. I get the same error, which is related to a Ruby 
version collision. It says it expects v 2.6 and I'm running 2.5, when I'm not 
and I don't have that installed on my new box or old. I can build the 
asf-branch, which is just 1 functional commit behind master. I'm guessing the 
last Gemfile dependency has some engine constraint in it that we need to 
address. I think I'll try and regress  that dependency and then try and merge 
your PR.


-- 
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