On Tue, May 8, 2012 at 3:03 AM, Bruno Mahé <bm...@apache.org> wrote: > First, thank you very much for taking the time to write a thoughtful reply. > > > On 05/08/2012 02:08 PM, Greg Stein wrote: >... >>> as well as we don't >>> distribute other Apache software either. >> >> I found a bunch of Apache software in there. >> >> So I'd say you're distributing it. >> >> (not that I believe that is a problem, but let's try and get things >> straight here) >> > > But all these files are convenience artefacts. They are not part of a > release.
Sure. > I don't see any difference from the Google protocolbuffer binary > artefacts found in Apache Hadoop convenience artefacts. Except that > instead of all of them being hidden into a giant tarball, they are > organized openly inside a repository. I don't care what other projects do. We're talking about Bigtop right now. (I can comment on Hadoop/protobuf, but will not do so in this thread) >>> Since you keep on doing this mistake, there is surely a >>> misunderstanding. So it would probably be easier if you could point us >>> to other Apache (or non-Apache) software being distributed as part as >>> any Apache Bigtop (incubating) releases on which members have voted on? >> >> I can see anybody looking at that URL location believing that you're >> distributing both Bigtop *AND* other Apache software. >> >> If you're using a different definition of "distributing", then we need >> to resolve that situation. I see lots of ASF software being >> distributed via that URL. > > I don't think I am using a different definition of "distributing. But I > would like to stress out that I make a clear distinction between what is > distributed as part of an Apache release and what is distributed as part > of a convenience artefact. Agreed. There *is* a distinction. My point was that placing them both in the same directory (URL; whatever) makes it *appear* they are combined. And based on that appearance, people are (empirically demonstrated) getting confused. But stepping back a little bit. You are distributing two things: 1) Apache Bigtop (incubating) 2) Convenience artifacts Do you agree with that? > Here is a quote from Owen: "I'm strictly -1 > on releasing any version of Bigtop with Hue or any other non-Apache > software as part of the release." > And we truly do not include anything else then Apache Bigtop > (incubating) in Apache Bigtop (incubating) releases. And as far as I can > tell, the issue Owen is having is related to convenience artefacts, not > releases. Fine. Relax. So he misspoke in one single sentence. It happens. Move on, already. I will offer a piece of advice here: if you ever write an email with somebody's name in it, then please step back and reconsider. A technical/procedural/whatever discussion *does not* require people's names to be productive. Speak to the issue at hand, the problem being raised, the disconnect that has occurred. Continuing to bring Owen's name into this discussion is a complete distraction. In short: omit names. It really helps. > We use these upstream projects as dependencies. We don't distribute > directly other software in the convenience artefacts of Apache Bigtop > (incubating). You distribute *some* software. I don't know that it matters what that software is, but simply the fact that you're distributing two things: Bigtop, and "other stuff". If you agree with that, then let's talk about people's concerns with the "other stuff" part. (I don't think anybody has raised any issue with the Apache Bigtop (incubating) part of the release, so assuming that's true, let's just please drop that part, stop harping on it, and move on to the relevant part of the discussion) >... >> It is true that votes only apply to Bigtop releases and not those >> artifacts under bigtop-0.3.0-incubating/repos/. >> >> It is also true that (in normal PMC operation) it is not possible to >> veto a release. I have no strong opinion, but would believe the that a >> podling can also make a release with three IPMC +1 votes (and, again, >> vetoes do not apply). Note: IPMC votes, not PPMC votes. If somebody >> raises a -1, then I suspect getting those IPMC votes might be >> difficult until the concern is discussed. >> >> Regarding the release artifacts: I don't have any strong opinions >> right now. I can see the confusion with them all in the same location. >> I can also see that Infra should probably get involved in some way to >> deal with mirroring issues and to somehow distinguish, verify, and >> validate these binary artifacts. > > What confuses me the most, is that Owen's issue is with the convenience > artefacts, not with the release itself. So there is no real reason to -1 > releases if they are not the issue. Whatever. Let's assume he misspoke and restart the conversation instead of rehashing this over and over. Let's not try and state what he should or should not do, and whether he has any "real reason" to do so. > And if I understand correctly from what you are saying, there is really > nothing preventing us from continuing, providing the Apache Bigtop > (incubating) community is in agreement (ie. enough +1 on tickets and > enough +1 from IPMC members for releases). Correct. All ASF releases require three +1 votes from PMC members. For podlings, that means Incubator PMC members. (the PPMC is a construct of the IPMC; it has no bearing on ASF releases) > Although I would rather end > up with everyone agreeing. That is the best plan. Discord is never a good thing. > But in the worst case scenario, we can always stop publishing > convenience artefacts as part of Apache releases, and host these > convenience artefacts outside of the Apache Infrastructure as > contributors and bypass all these concerns. Whatever you would like to do. It seems the only point of real discussion here is what to do with hosting artifacts that are NOT ASF products. (eg. HUE) Is that the real discussion point? Non-ASF products? Note: many ASF products incorporate third-party source (that match our licensing policies). This is normal and not a problem. So what is the differentiator? Is it simply that the ASF has compiled it first? Is that really a problem? > Note also that Infra has already been involved. Yup. Saw. Cheers, -g --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
