Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of aharui@adobe.com designates
 64.18.1.39 as permitted sender)
From: Alex Harui <aharui@adobe.com>
To: "flex-dev@incubator.apache.org" <flex-dev@incubator.apache.org>
Date: Tue, 1 Jan 2013 22:41:59 -0800
Subject: Re: [DISCUSS] Apache Flex SDK Installer 2.0 RC1
Thread-Topic: [DISCUSS] Apache Flex SDK Installer 2.0 RC1
Thread-Index: Ac3oaUOw1CzJUgr9TumtMePtXPCbzwASv/xd
Message-ID: <CD0916B7.4ABEC%aharui@adobe.com>
In-Reply-To: <08705248-C5F4-46BA-A626-5D6A2640DF0C@classsoftware.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-Entourage/13.13.0.120411
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Ok, here is my logic:

-From [1], a release is "anything that is published beyond the group that
owns it.".  Putting the config.xml on the site to be consumed by one of our
binaries makes it part of a release and requires a vote before it happens.
-Also from [1], " All releases are in the form of the source materials
needed to make changes to the software being released.".  The config file
gets changed with each release and therefore IMO it is considered source
materials even though it is not source code.
-From [2], "The role of the PMC from a Foundation perspective is oversight.
The main role of the PMC is not code and not coding - but to ensure that al=
l
legal issues are addressed, that procedure is followed, and that each and
every release is the product of the community as a whole. That is key to ou=
r
litigation protection mechanisms." and later "However those on the PMC are
kept to a higher standard. As the PMC, and the chair in particular, are eye=
s
and ears of the ASF Board, it is you that we rely on and need to trust to
provide legal oversight.  The board has the faculty to terminate a PMC at
any time by resolution."  As much as we want to get this release out the
door, the fact is it is more important to make sure we are following policy=
.

It is unfortunate that various logistical issues have prevented us from
getting our final dist folder.  But here we are and we have to work with
Apache policy.

[1] http://www.apache.org/dev/release#what
[2] http://www.apache.org/foundation/how-it-works.html#pmc


On 1/1/13 1:44 PM, "Justin Mclean" <justin@classsoftware.com> wrote:

> Hi,
>=20
>>> Would you consider the disclaimer page to be  part of the source?
>> The DISCLAIMER file is in the source kit for incubating releases.
> I was referring to the disclaimer link in the application not the DISCLAI=
MER
> file.
I don't think it is an issue if we pull up existing web pages, but IMO it i=
s
an issue to be publishing source materials on the site without a vote.
>=20
>> Source kits are (potentially filtered) dumps of what is in SVN.
> And that correct with the installer, there's a source kit which someone c=
an
> take and compile the application.
>=20
>> I'm pretty sure Apache regulations would override any vote.
> What "regulation" exactly? Can you point to me page that state that you c=
an't
> load XML files outside of it's SVN trunk?
>=20
>> This is potentially a legal issue
> What is the legal issue here? The installer will be voted on and distribu=
ted
> in the normal Apache Way (apache.org/dist). The XML file is also in SVN a=
t
> svn.apage.org that only Apache committers can access and change. The inst=
aller
> will only download official Apache releases that have been voted on and p=
laced
> in apache.org/dist.
>=20
> I guess worse case a committer could modify the file XML file in SVN to
> download another Apache binary kit but I think we would notice that and f=
ix.
>=20
> Thanks,
> Justin
>=20

--=20
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui