John D. Ament wrote:
On Tue, Aug 2, 2016 at 3:57 PM Josh Elser<els...@apache.org> wrote:
- I think there is a very fair point brought up by Craig/Justin/John at
the gray line between "Apache Fluo" and "fluo.io". However, I will say
that I do *not* think this is remotely close to the level that we've
seen in other TLPs as of late (will avoid explicit finger-pointing).
That said, I think the outcome that the PPMC has came to on their own as
next steps is healthy (see dev@fluo list). I also plan to address why
some of these software tools which were developed in tandem with Fluo
(pre-Apache) were not included with the original incubation proposal (I
hadn't realized they were listed on the website as they were). I would
venture most are unintentional omissions as the website came verbatim
from pre-Apache fluo. The podling has already been responsive to my
nit-picks on ASF and Incubator branding requests that I put forth to them.
You have to remember, the incubator is focused on getting projects ready
for TLP. These issues tend to become more noticeable.
Yes, completely understood.
- One thing that initially worried me is that a software release was
being -1'd over podling branding (the later concession to separate the
topics did make me happy). Proper branding for podlings, especially ones
that have a pre-Apache life, is obviously tricky to do well and cycles
of the review are inevitable. However, given how difficult creating
properly-licensed ASF releases is, should branding concerns be lumped
into release votes? Is there another mechanism by which we as IPMC can
give feedback to podlings at a time which they are not already stressed
trying to make a software release?
There's certain things that block graduation, and things that block
releases. As far as I'm concerned, branding issues did not block this
release. Also please note that -1's on releases aren't vetoes. If you get
enough +1's it'll pass.
Yes, I do remember that they are majority votes. Because I've worked
with most of the PPMC members before, I'm well aware that they take to
heart the severity of getting a -1 from anyone.
An issue where pre-apache releases were not properly labeled on the
podlings the website caused me to vote a -1. Granted, the issue turned
into a branding problem. Upon closer inspection, looking at fluo, their
readme raised a few red flags from my point of view. I was trying to
figure out when they went for a full release (not just a pom file) what was
going to be involved. Upon looking at
https://github.com/apache/incubator-fluo/blob/master/README.md I
incorrectly got the impression that the only way to use fluo was to use
tools not developed at the ASF. This is a big red flag. This turned into
a really bad discussion over the use of fluo.io.
Thanks for the great synopsis. Your attention to detail is obviously
appreciated and I wholly understand where your concern came from. I know
the PPMC is already making positive steps here (their mailing list and
the further chatter on the failed VOTE thread).
I'm reminded of John's
https://wiki.apache.org/incubator/BrandingAuditJune2016 which was a
great high-level insight across podlings. Are branding-audits something
that mentors could drive with their PPMC directly with shepherds/IPMC
bringing their concerns directly to the PPMC/metnors (to avoid licensing
becoming entangled with branding)? IPMC would obviously still have the
ability to escalate things in very heinous situations, but -1'ing
releases for website issues doesn't sit right with me presently (I'm
happy to be taught otherwise, too).
Yes, I would love to see mentors push their podlings forward, and perhaps
even maintain this going forward.
Cool. I'll have to put some more thought into this as I'll have a few
other podlings under my belt which I should be paying as close attention
to their branding as you did.
Thanks again for your attention, John.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
