You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Brian Fox <br...@infinity.nu> on 2009/04/28 17:12:15 UTC
Clarification on the release requirements
I'm trying to play catch-up on the previous discussion regarding maven
based releases.
On http://www.apache.org/dev/release.html#what the following is written:
"The Apache Software Foundation produces open source software. All
releases are in the form of the source materials needed to make changes
to the software being released. In some cases, binary/bytecode packages
are also produced as a convenience to users that might not have the
appropriate tools to build a compiled version of the source. In all such
cases, the binary/bytecode package must have the same version number as
the source release and may only add binary/bytecode files that are the
result of compiling that version of the source code release."
Then in the question and answer it says this:
(http://www.apache.org/dev/release.html#distribute-raw-artifact)
"Can I Distribute A Raw Artifact
ASF distributions typically contain additional material together with
the artifacts. This material may include documentation concerning the
release but must contain LICENSE and NOTICE files.
Raw artifacts may be distributed if they contain LICENSE and NOTICE
files. For example, the java artifact format is based on a compressed
directory structure and those projects wishing to distribute raw jars
place LICENSE and NOTICE files in the META-INF directory within the jar."
At first glance, these seem to be contradictory. Is the second paragraph
really just providing an enabling statement for the binary clause in the
first? If so, I might suggest the question be renamed to:
"What are the requirements to distribute A Raw Artifact in addition to
my source?
ASF distributions typically contain additional material together with
the artifacts. This material may include documentation concerning the
release but must contain LICENSE and NOTICE files.
Raw artifacts may be distributed if they contain LICENSE and NOTICE
files. For example, the java artifact format is based on a compressed
directory structure and those projects wishing to distribute raw jars
place LICENSE and NOTICE files in the META-INF directory within the jar.
Note that a Raw Artifact does not superceede the requirement defined
here http://www.apache.org/dev/release.html#what that all releases be
primarily of a source. The Raw Artifact is in addition to the source
release".
Additionally, are there any written guidelines of what exactly comprises
the "form" mentioned here: "All releases are in the form of the source
materials"
Specifically, does a tag in scm count?
Does this form need to include _everything_ that might be in the tag? ie
things needed to run tests that are not exactly part of the final
executable source code/binary? In many cases the test resources may be
significantly larger than the source itself.
What steps are allowed for a user to take the "form" and use it to
build? Obviously they may need to unzip something, or checkout
something. Are other tools allowed?
Specifically if a tool was available to convert maven sources jars into
a buildable source tree, is that acceptable?
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Niclas Hedhman wrote:
> On Wed, Apr 29, 2009 at 12:28 AM, David Jencks <da...@yahoo.com> wrote:
>
>> For a C project, does a source distro have to include make files? If so,
>> why doesn'ti it have to include make and the compiler as well? I'm no C
>> expert but I believe it's possible although perhaps impractical to build a
>> project using just the compiler...
>
> All C/C++ projects that I have downloaded 'recently' (last 5years or
> so) all comes complete, typically listing the "system requirements",
> which may be gnu C compiler, Make, Autoconf and often a bunch of
> libraries of particular versions.
When used properly by a project; autoconf (automake) are not required
of the end-user / builder. They are able to generate an appropriate
configure script and package the relevant components, as source, with
appropriate licensing exceptions.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Apr 29, 2009 at 12:28 AM, David Jencks <da...@yahoo.com> wrote:
> For a C project, does a source distro have to include make files? If so,
> why doesn'ti it have to include make and the compiler as well? I'm no C
> expert but I believe it's possible although perhaps impractical to build a
> project using just the compiler...
All C/C++ projects that I have downloaded 'recently' (last 5years or
so) all comes complete, typically listing the "system requirements",
which may be gnu C compiler, Make, Autoconf and often a bunch of
libraries of particular versions.
In my personal opinion, I am not fond of cyclic system requirements,
e.g. Gnu C compiler depends on an earlier version of itself or that
Maven core has a system reqiurement of Maven plugins that in turn
depend on Maven core. But I have said that I understand the trickiness
on having Maven bootstrap itself from scratch, and will not push it
for Maven. Ideally, Maven would bootstrap itself via something like
Ant, Make or shell scripts. Listing "Linux" as a system requirement
for building Maven is IMHO better than listing "Maven" or "online
access and a previous version of Maven will be used...", but I don't
hope for such.
> BTW --although IMO this belongs on the maven list -- I assume this tool
> would extract the pom from the (binary) jar and the source from the source
> jar and make a maven project lacking tests?
IMHO, "lacking tests" sounds like a really, really bad idea. PMC
members are expected to at least run minimal tests on their platform
especially to catch problems related to platform dependent
corner-cases.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by David Jencks <da...@yahoo.com>.
On Apr 28, 2009, at 9:45 AM, Brian Fox wrote:
>
>
>>
>> I think that such a tool is not necessary, although it would be
>> handy. I think that the source jars maven produces satisfy the
>> requirement to be the source materials mentioned in the first
>> quote. While this obviously does not produce something that is
>> immediately buildable with a single short command line, as soon as
>> you ask for anything else you get into a continuum that leads to
>> including all the dependencies, the entire maven distro, the java
>> compiler, and the jvm and presumably the operating system and
>> hardware. IMO everything that isn't in the source jar consists of
>> "helpful hints about how you might like to build this source should
>> you be so inclined" and is not required in the (source) distribution.
>>
> This is what I'm trying to determine. What are the real requirements
> of what this form? I don't want to waste time building a solution
> that is ultimately still not meeting the legal requirements.
>
>> For a C project, does a source distro have to include make files?
>> If so, why doesn'ti it have to include make and the compiler as
>> well? I'm no C expert but I believe it's possible although
>> perhaps impractical to build a project using just the compiler...
>>
> That's where I was going with the thoughts....
>> BTW --although IMO this belongs on the maven list -- I assume this
>> tool would extract the pom from the (binary) jar and the source
>> from the source jar and make a maven project lacking tests?
>>
> I don't think so yet, this is a question about what the legal
> requirements for releases are, and this should be met by all
> releases regardless of the tool. Once that's clear, then we can
> attempt to make the Apache releases using Maven easier to do. FWIW,
> I recently started in this direction by moving some of the things we
> do in the Maven build itself up to the Apache wide pom so that new
> projects have a lower hurdle to get compliant releases. The changes
> derived from this discussion should follow the same path once they
> are implemented. That is to say it's not Maven source itself that
> has to change because people outside of ASF obviously use it with
> different requirements, but the build process we use with Maven at
> Apache needs to be enhanced.
As usual with my communication brevity got the better of clarity :-) I
agree that what such a hypothetical tool should do should be discussed
here... I was speculating on how it might be implemented.
The following is really covered by the preceding discussion but I'd
like to be even more explicit...
Most of the apache projects that use maven that I know of do something
that produces a zip and tar.gz file that is the "distribution" and
includes various stuff including the source files and some build
instructions.
In my opinion this is unnecessary and the source jars produced by
maven for instance by the release profile in the proposed apache pom v
6 are adequate. I'd like this principle to be clearly established and
stated or clearly refuted.
For instance, IIUC felix is producing zip and tar.gz files for each
jar they release and have declined to use the apache 6 pom because of
the custom release profile that is needed to produce these. (They have
other reasons too, such as the v6 pom not being released yet :-) --
I'm overstating the case to make a point) IMO this profusion of
artifacts leads primarily to confusion.
thanks
david jencks
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Brian Fox <br...@infinity.nu>.
>
> I think that such a tool is not necessary, although it would be
> handy. I think that the source jars maven produces satisfy the
> requirement to be the source materials mentioned in the first quote.
> While this obviously does not produce something that is immediately
> buildable with a single short command line, as soon as you ask for
> anything else you get into a continuum that leads to including all the
> dependencies, the entire maven distro, the java compiler, and the jvm
> and presumably the operating system and hardware. IMO everything that
> isn't in the source jar consists of "helpful hints about how you might
> like to build this source should you be so inclined" and is not
> required in the (source) distribution.
>
This is what I'm trying to determine. What are the real requirements of
what this form? I don't want to waste time building a solution that is
ultimately still not meeting the legal requirements.
> For a C project, does a source distro have to include make files? If
> so, why doesn'ti it have to include make and the compiler as well?
> I'm no C expert but I believe it's possible although perhaps
> impractical to build a project using just the compiler...
>
That's where I was going with the thoughts....
> BTW --although IMO this belongs on the maven list -- I assume this
> tool would extract the pom from the (binary) jar and the source from
> the source jar and make a maven project lacking tests?
>
I don't think so yet, this is a question about what the legal
requirements for releases are, and this should be met by all releases
regardless of the tool. Once that's clear, then we can attempt to make
the Apache releases using Maven easier to do. FWIW, I recently started
in this direction by moving some of the things we do in the Maven build
itself up to the Apache wide pom so that new projects have a lower
hurdle to get compliant releases. The changes derived from this
discussion should follow the same path once they are implemented. That
is to say it's not Maven source itself that has to change because people
outside of ASF obviously use it with different requirements, but the
build process we use with Maven at Apache needs to be enhanced.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Santiago Gala <sa...@gmail.com>.
El mar, 28-04-2009 a las 09:28 -0700, David Jencks escribió:
(... lots of discussions that I don't want to enter to discuss ...)
Strictly my opinion:
> For a C project, does a source distro have to include make files? If
Yes (for Makefiles).
> so, why doesn'ti it have to include make and the compiler as well?
It doesn't. Because, while the Makefile has a certain amount of "source"
in it. i.e., a Makefile is a creative expression on project
dependencies, relations between modules, and rules to build the project
artifacts.
OTOH, make and the compiler are part of the so-called "system
dependencies" and include no creative expression at all related to our
project, but only about transforming a language source code into a
platform machine code, which everybody agrees is in a different plane.
> I'm no C expert but I believe it's possible although perhaps
> impractical to build a project using just the compiler...
>
My opinion is relative to what common software engineering practices
regard as "source distributions". The typical criteria is:
something you can "./configure && make && make test && sudo make
install" to deploy. There might be slight differences in build systems,
but all are variations of the above.
In fact, a number of FLOSS projects will not compile or run easily
without the original Makefile info, as they need specific compiler flags
to avoid bugs in certain compilers breaking the compilation.
> thanks
> david jencks
Regards
Santiago
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by David Jencks <da...@yahoo.com>.
On Apr 28, 2009, at 8:12 AM, Brian Fox wrote:
> I'm trying to play catch-up on the previous discussion regarding
> maven based releases.
>
> On http://www.apache.org/dev/release.html#what the following is
> written:
>
> "The Apache Software Foundation produces open source software. All
> releases are in the form of the source materials needed to make
> changes to the software being released. In some cases, binary/
> bytecode packages are also produced as a convenience to users that
> might not have the appropriate tools to build a compiled version of
> the source. In all such cases, the binary/bytecode package must have
> the same version number as the source release and may only add
> binary/bytecode files that are the result of compiling that version
> of the source code release."
>
> Then in the question and answer it says this: (http://www.apache.org/dev/release.html#distribute-raw-artifact
> )
>
>
> "Can I Distribute A Raw Artifact
>
> ASF distributions typically contain additional material together
> with the artifacts. This material may include documentation
> concerning the release but must contain LICENSE and NOTICE files.
>
> Raw artifacts may be distributed if they contain LICENSE and NOTICE
> files. For example, the java artifact format is based on a
> compressed directory structure and those projects wishing to
> distribute raw jars place LICENSE and NOTICE files in the META-INF
> directory within the jar."
>
>
> At first glance, these seem to be contradictory. Is the second
> paragraph really just providing an enabling statement for the binary
> clause in the first? If so, I might suggest the question be renamed
> to:
>
> "What are the requirements to distribute A Raw Artifact in addition
> to my source?
>
> ASF distributions typically contain additional material together
> with the artifacts. This material may include documentation
> concerning the release but must contain LICENSE and NOTICE files.
>
> Raw artifacts may be distributed if they contain LICENSE and NOTICE
> files. For example, the java artifact format is based on a
> compressed directory structure and those projects wishing to
> distribute raw jars place LICENSE and NOTICE files in the META-INF
> directory within the jar.
>
> Note that a Raw Artifact does not superceede the requirement
> defined here http://www.apache.org/dev/release.html#what that all
> releases be primarily of a source. The Raw Artifact is in addition
> to the source release".
I think this is an improvement.
>
>
> Additionally, are there any written guidelines of what exactly
> comprises the "form" mentioned here: "All releases are in the form
> of the source materials"
>
> Specifically, does a tag in scm count?
> Does this form need to include _everything_ that might be in the
> tag? ie things needed to run tests that are not exactly part of the
> final executable source code/binary? In many cases the test
> resources may be significantly larger than the source itself.
> What steps are allowed for a user to take the "form" and use it to
> build? Obviously they may need to unzip something, or checkout
> something. Are other tools allowed?
> Specifically if a tool was available to convert maven sources jars
> into a buildable source tree, is that acceptable?
I think that such a tool is not necessary, although it would be
handy. I think that the source jars maven produces satisfy the
requirement to be the source materials mentioned in the first quote.
While this obviously does not produce something that is immediately
buildable with a single short command line, as soon as you ask for
anything else you get into a continuum that leads to including all the
dependencies, the entire maven distro, the java compiler, and the jvm
and presumably the operating system and hardware. IMO everything that
isn't in the source jar consists of "helpful hints about how you might
like to build this source should you be so inclined" and is not
required in the (source) distribution.
For a C project, does a source distro have to include make files? If
so, why doesn'ti it have to include make and the compiler as well?
I'm no C expert but I believe it's possible although perhaps
impractical to build a project using just the compiler...
BTW --although IMO this belongs on the maven list -- I assume this
tool would extract the pom from the (binary) jar and the source from
the source jar and make a maven project lacking tests?
thanks
david jencks
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Apr 29, 2009 at 4:21 AM, Jochen Wiedmann
<jo...@gmail.com> wrote:
> Most projects, which are using Maven as the build system, would want
> to create "classical" distributions anyways. (The exception being
> basically Maven plugins.)
Personally I would like to see Maven's own distribution in a format
that doesn't require an online connection. It is rather common to end
up in companies that don't allow downloads "just like that", and
everything needs to be manually requested and pulled into internal
networks.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Nathan Beyer <nd...@apache.org>.
On Tue, Apr 28, 2009 at 6:21 PM, Brian Fox <br...@infinity.nu> wrote:
>
>
> Roy T. Fielding wrote:
>>
>> On Apr 28, 2009, at 1:45 PM, Brian Fox wrote:
>>>
>>> I'm attempting to get answer to existing legal question marks. Like David
>>> Jenks said:
>>> "
>>> In my opinion this is unnecessary and the source jars produced by maven
>>> for instance by the release profile in the proposed apache pom v 6 are
>>> adequate. I'd like this principle to be clearly established and stated or
>>> clearly refuted."
>>>
>>> Can we start there?
>>
>> <snip>
>> If you can do that with Maven, great. If you can't, then you can't
>> call a Maven build a release -- it is just another form of binary
>> packaging that cannot be distributed until after the release is
>> cut and approved in source form. Binary packages MUST be built from
>> the SIGNED and RELEASED source package, NOT FROM SUBVERSION TAGS.
>>
> This level of detail is definately not on the site that I've been able to
> find. The current example release process validates certain conditions and
> then makes a tag. That tag is then checked out and in the same motion, the
> binaries are produced and the source tar'd up and everything signed. All of
> these things, the source archives and binaries are then validated and voted
> upon.
I presume this detail could be posted as commentary and additional doc
- there's a queue for patches to the main web site, correct? Lets do
that.
However, I didn't find Roy's comment to be surprising in anyway,
that's the way I understand the policies.
>
> The end result is the same, the source archives contain the same code that
> produced the binaries, which is in agreement with the documented policy on
> the site:
>
> "In all such cases, the binary/bytecode package must have the same version
> number as the source release and may only add binary/bytecode files that are
> the result of compiling that version of the source code release."
>
> It seems like semantics that source must be tared, signed, untared and then
> rebuilt if it's all being done in the same action. Do we agree or disagree?
>
I certainly don't speak for Roy, but I presume you can safely
substitute 'tar' for 'jar', 'zip' or any archive format, as long as
the archive file containing the source is signed.
-Nathan
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Santiago Gala <sa...@gmail.com>.
El mié, 29-04-2009 a las 09:50 -0400, Brian Fox escribió:
> I'm glad to wake up and find the discussion going in the direction that
> I was hoping it would, that is towards writing these things down and
> then getting some member approval to make sure it gets the "official"
> stamp and associated project buy in.
>
> The fundamental difference seems to be that Maven uses the svn tag as
> the master source to produce both the source archives and binaries that
> are voted on, and Httpd first makes a source archive that is then used
> to build. These are slight differences on the same theme. (there is a
> further issue for some maven projects that don't produce the
> encompassing archive but that can be corrected).
>
> Assuming the build must execute on a source archive and not a tag, we
> would have to build new tooling to support it. I don't think however
> that this would be used very much outside of the ASF. I've trained
Source linux distributions such as gentoo or arch have a very hard time
with maven based packages, to the extent that there is no "maven" gentoo
ebuild, only "maven-bin", as they are unable to build from sources...
I guess package maintainer for binary based distributions such as RHEL,
Ubuntu, etc. would have more packaged java if they could actually build
from sources themselves. QA via build and test repeatable procedures is
a very big part of the value they add in the ecosystem, and having non
consistent build systems does not help adoption. And no, I don't think
having to do it "the maven way" helps.
Regards
Santiago
> hundreds of users on the maven release process at many companies and
> never once have I been asked to first produce a source archive and then
> use it to build. Everyone considers the tag to be sancrosanct and they
> want to be sure that they can build from the tag, not some tarball that
> is disconnected from the scm.
>
> That's not to say that we won't create a solution for ASF projects, but
> it seems to be that everyone should be in agreement that this is a
> required shift before we go and build a one-off chunk of code. I would
> like to suggest that given so many projects are doing it differently for
> such a long period of time, that perhaps this subtle change is really
> not such a fundamental problem provided that the main goal is to produce
> a buildable sourcearchive and that the order is less important.
>
> David Crossley wrote:
> > Joe Schaefer wrote:
> >
> >> Ralph Goers wrote:
> >>
> >>> While I absolutely agree with this process, without board approved documentation
> >>> it gets left up to each PMC to determine this. I'm sure Brian's goal is to
> >>> understand the recommendation and then modify the appropriate Maven components
> >>> so that this process can be followed. Is there no way to get this posted on the
> >>> site so that it is crystal clear and won't get changed unless the membership
> >>> expresses a desire to change it?
> >>>
> >> Policy documents like this one are delegated to infrastucture, which is supposed
> >> to be overseeing all commits to the /dev section of the website.
> >>
> >
> > And ASF Members have commit rights and can participate at Infra.
> > Committers can also participate and may be enabled via the
> > "infrastructure-interest" group.
> > See "Updating the Infrastructure web site"
> > http://www.apache.org/dev/infra-site.html
> >
> > -David
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by sebb <se...@gmail.com>.
On 29/04/2009, Brian Fox <br...@infinity.nu> wrote:
> I'm glad to wake up and find the discussion going in the direction that I
> was hoping it would, that is towards writing these things down and then
> getting some member approval to make sure it gets the "official" stamp and
> associated project buy in.
>
> The fundamental difference seems to be that Maven uses the svn tag as the
> master source to produce both the source archives and binaries that are
> voted on, and Httpd first makes a source archive that is then used to build.
> These are slight differences on the same theme. (there is a further issue
> for some maven projects that don't produce the encompassing archive but that
> can be corrected).
>
> Assuming the build must execute on a source archive and not a tag, we would
> have to build new tooling to support it. I don't think however that this
> would be used very much outside of the ASF. I've trained hundreds of users
> on the maven release process at many companies and never once have I been
> asked to first produce a source archive and then use it to build. Everyone
> considers the tag to be sancrosanct
Unfortunately that is not the case here. Tags have been deleted and
recreated in order to do a new release. [Yes, I've tried complaining
about this, but it seems to be built into some processes, whether
necessary or not is not clear].
Of course one can use TAG+revision instead, but I've yet to see that used.
It would be good to get an ASF-wide formal ruling on this too.
> and they want to be sure that they can
> build from the tag, not some tarball that is disconnected from the scm.
>
> That's not to say that we won't create a solution for ASF projects, but it
> seems to be that everyone should be in agreement that this is a required
> shift before we go and build a one-off chunk of code. I would like to
> suggest that given so many projects are doing it differently for such a long
> period of time, that perhaps this subtle change is really not such a
> fundamental problem provided that the main goal is to produce a buildable
> sourcearchive and that the order is less important.
>
>
> David Crossley wrote:
>
> > Joe Schaefer wrote:
> >
> >
> > > Ralph Goers wrote:
> > >
> > >
> > > > While I absolutely agree with this process, without board approved
> documentation it gets left up to each PMC to determine this. I'm sure
> Brian's goal is to understand the recommendation and then modify the
> appropriate Maven components so that this process can be followed. Is there
> no way to get this posted on the site so that it is crystal clear and won't
> get changed unless the membership expresses a desire to change it?
> > > >
> > > >
> > > Policy documents like this one are delegated to infrastucture, which is
> supposed
> > > to be overseeing all commits to the /dev section of the website.
> > >
> > >
> >
> > And ASF Members have commit rights and can participate at Infra.
> > Committers can also participate and may be enabled via the
> > "infrastructure-interest" group.
> > See "Updating the Infrastructure web site"
> > http://www.apache.org/dev/infra-site.html
> >
> > -David
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Apr 29, 2009 at 3:50 PM, Brian Fox <br...@infinity.nu> wrote:
> Assuming the build must execute on a source archive and not a tag, [...]
I don't think this is the case.
I think it's fine as long as the release manager produces a source
package that a) matches the sources tagged in svn, and b) produces the
other release artifacts when built.
IMHO it makes little difference whether that package is a direct
export of an svn tag or the result of an assembly build. It's the
content of the package, not the way (or when) it was created, that
matters.
I personally prefer packaging a direct svn export, as it minimizes the
risk of a broken assembly configuration missing some parts or
including too much, but that's just me. Even the httpd source packages
aren't direct svn exports.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Brian Fox <br...@infinity.nu>.
I'm glad to wake up and find the discussion going in the direction that
I was hoping it would, that is towards writing these things down and
then getting some member approval to make sure it gets the "official"
stamp and associated project buy in.
The fundamental difference seems to be that Maven uses the svn tag as
the master source to produce both the source archives and binaries that
are voted on, and Httpd first makes a source archive that is then used
to build. These are slight differences on the same theme. (there is a
further issue for some maven projects that don't produce the
encompassing archive but that can be corrected).
Assuming the build must execute on a source archive and not a tag, we
would have to build new tooling to support it. I don't think however
that this would be used very much outside of the ASF. I've trained
hundreds of users on the maven release process at many companies and
never once have I been asked to first produce a source archive and then
use it to build. Everyone considers the tag to be sancrosanct and they
want to be sure that they can build from the tag, not some tarball that
is disconnected from the scm.
That's not to say that we won't create a solution for ASF projects, but
it seems to be that everyone should be in agreement that this is a
required shift before we go and build a one-off chunk of code. I would
like to suggest that given so many projects are doing it differently for
such a long period of time, that perhaps this subtle change is really
not such a fundamental problem provided that the main goal is to produce
a buildable sourcearchive and that the order is less important.
David Crossley wrote:
> Joe Schaefer wrote:
>
>> Ralph Goers wrote:
>>
>>> While I absolutely agree with this process, without board approved documentation
>>> it gets left up to each PMC to determine this. I'm sure Brian's goal is to
>>> understand the recommendation and then modify the appropriate Maven components
>>> so that this process can be followed. Is there no way to get this posted on the
>>> site so that it is crystal clear and won't get changed unless the membership
>>> expresses a desire to change it?
>>>
>> Policy documents like this one are delegated to infrastucture, which is supposed
>> to be overseeing all commits to the /dev section of the website.
>>
>
> And ASF Members have commit rights and can participate at Infra.
> Committers can also participate and may be enabled via the
> "infrastructure-interest" group.
> See "Updating the Infrastructure web site"
> http://www.apache.org/dev/infra-site.html
>
> -David
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by David Crossley <cr...@apache.org>.
Joe Schaefer wrote:
> Ralph Goers wrote:
> >
> > While I absolutely agree with this process, without board approved documentation
> > it gets left up to each PMC to determine this. I'm sure Brian's goal is to
> > understand the recommendation and then modify the appropriate Maven components
> > so that this process can be followed. Is there no way to get this posted on the
> > site so that it is crystal clear and won't get changed unless the membership
> > expresses a desire to change it?
>
> Policy documents like this one are delegated to infrastucture, which is supposed
> to be overseeing all commits to the /dev section of the website.
And ASF Members have commit rights and can participate at Infra.
Committers can also participate and may be enabled via the
"infrastructure-interest" group.
See "Updating the Infrastructure web site"
http://www.apache.org/dev/infra-site.html
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Ralph Goers <ra...@dslextreme.com>
> To: legal-discuss@apache.org
> Sent: Tuesday, April 28, 2009 8:07:53 PM
> Subject: Re: Clarification on the release requirements
>
>
> On Apr 28, 2009, at 4:43 PM, Roy T. Fielding wrote:
>
> > On Apr 28, 2009, at 4:21 PM, Brian Fox wrote:
> >>>
> >>>
> >> This level of detail is definately not on the site that I've been able to
> find.
> >
> > It has been described many times, documented many times, and
> > periodically watered down by folks who don't know what they
> > are doing.
>
> You never cease to make me laugh!
> >
> >
> >> The current example release process validates certain conditions and then
> makes a tag. That tag is then checked out and in the same motion, the binaries
> are produced and the source tar'd up and everything signed. All of these things,
> the source archives and binaries are then validated and voted upon.
> >>
> >> The end result is the same, the source archives contain the same code that
> produced the binaries, which is in agreement with the documented policy on the
> site:
> >>
> >> "In all such cases, the binary/bytecode package must have the same version
> number as the source release and may only add binary/bytecode files that are the
> result of compiling that version of the source code release."
> >>
> >> It seems like semantics that source must be tared, signed, untared and then
> rebuilt if it's all being done in the same action. Do we agree or disagree?
> >
> > No, it is not semantics. You assume that everything was tar'd correctly
> > and completely, which is not a valid assumption. Also, voting on binary
> > artifacts is inherently stupid because their quality cannot be verified.
> > That's why we specifically tell people not to vote on binaries, because
> > it just weakens the meaning of voting.
>
> While I absolutely agree with this process, without board approved documentation
> it gets left up to each PMC to determine this. I'm sure Brian's goal is to
> understand the recommendation and then modify the appropriate Maven components
> so that this process can be followed. Is there no way to get this posted on the
> site so that it is crystal clear and won't get changed unless the membership
> expresses a desire to change it?
Policy documents like this one are delegated to infrastucture, which is supposed
to be overseeing all commits to the /dev section of the website.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 28, 2009, at 4:43 PM, Roy T. Fielding wrote:
> On Apr 28, 2009, at 4:21 PM, Brian Fox wrote:
>>>
>>>
>> This level of detail is definately not on the site that I've been
>> able to find.
>
> It has been described many times, documented many times, and
> periodically watered down by folks who don't know what they
> are doing.
You never cease to make me laugh!
>
>
>> The current example release process validates certain conditions
>> and then makes a tag. That tag is then checked out and in the same
>> motion, the binaries are produced and the source tar'd up and
>> everything signed. All of these things, the source archives and
>> binaries are then validated and voted upon.
>>
>> The end result is the same, the source archives contain the same
>> code that produced the binaries, which is in agreement with the
>> documented policy on the site:
>>
>> "In all such cases, the binary/bytecode package must have the same
>> version number as the source release and may only add binary/
>> bytecode files that are the result of compiling that version of the
>> source code release."
>>
>> It seems like semantics that source must be tared, signed, untared
>> and then rebuilt if it's all being done in the same action. Do we
>> agree or disagree?
>
> No, it is not semantics. You assume that everything was tar'd
> correctly
> and completely, which is not a valid assumption. Also, voting on
> binary
> artifacts is inherently stupid because their quality cannot be
> verified.
> That's why we specifically tell people not to vote on binaries,
> because
> it just weakens the meaning of voting.
While I absolutely agree with this process, without board approved
documentation it gets left up to each PMC to determine this. I'm sure
Brian's goal is to understand the recommendation and then modify the
appropriate Maven components so that this process can be followed. Is
there no way to get this posted on the site so that it is crystal
clear and won't get changed unless the membership expresses a desire
to change it?
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Gilles Scokart <gs...@gmail.com>.
In case it helps :
Apache Ant (and subpojects) release process differ from Roy statement on 2
points :
1. We build both binary and source release together
2. We vote on both binary and source release
That's also the approach I have learned in the incubator. And seeing the
different votes in the incubator that seems to be the most frequently used
approach.
Even if these 2 differences seems important, I don't think they
fundamentally are when you take into account the root principle : Our
official release is the source release.
Indeed, the quality of the source release is not reduced because we build
and vote binary together (source release is done directly from the sources,
and 3 votes for binary+source are still 3 votes for sources).
However, it is true that it might be confusing. By voting source and
binaries, people tend to forget that the official release is the source
release. Or people might expect the same level of quality and trustability
for the binary release than for the source release.
Gilles Scokart
2009/4/29 Niclas Hedhman <ni...@hedhman.org>
> I personally think that an audit of PMCs is in order, because as David
> hints, I think many PMCs are too eager to get stuff through the door
> that corners are cut, probably unknowingly.
>
>
Re: Clarification on the release requirements
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Apr 29, 2009 at 8:54 AM, Nathan Beyer <nd...@apache.org> wrote:
>> Anyway... lets assume the process you describe is both apache policy and
>> desirable. Clearly all the ant scripts and maven release profiles I've
>> seen don't follow the policy. Let's try to think of some maven proecesses
>> that would. I'm going to assume that any release process for java software
>> needs to produce both source and binary artifacts that can be voted on at
>> once, since I'm pretty sure not voting on binary artifacts would be rejected
>> as impractical by most or all java projects.
>
> I disagree with this generalization. The Java projects I've
> participated in vote on source, not binary artifacts. However, I must
> admit that votes tend to be based on a particular revision in
> Subversion, rather than a source archive.
I agree with the sentiment that many (most) PMC members are either not
aware of, or are lazy, how releases are intended to be made. That is
not an excuse though, to flagrantly ignore the intent.
I personally think that an audit of PMCs is in order, because as David
hints, I think many PMCs are too eager to get stuff through the door
that corners are cut, probably unknowingly.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Nathan Beyer <nd...@apache.org>.
On Tue, Apr 28, 2009 at 7:26 PM, David Jencks <da...@yahoo.com> wrote:
>
> On Apr 28, 2009, at 4:43 PM, Roy T. Fielding wrote:
>
>> On Apr 28, 2009, at 4:21 PM, Brian Fox wrote:
>>>
>>> Roy T. Fielding wrote:
>>>>
>>>> On Apr 28, 2009, at 1:45 PM, Brian Fox wrote:
>>>>>
>>>>> I'm attempting to get answer to existing legal question marks. Like
>>>>> David Jenks said:
>>>>> "
>>>>> In my opinion this is unnecessary and the source jars produced by maven
>>>>> for instance by the release profile in the proposed apache pom v 6 are
>>>>> adequate. I'd like this principle to be clearly established and stated or
>>>>> clearly refuted."
>>>>>
>>>>> Can we start there?
>>>>
>>>> <snip>
>>>> If you can do that with Maven, great. If you can't, then you can't
>>>> call a Maven build a release -- it is just another form of binary
>>>> packaging that cannot be distributed until after the release is
>>>> cut and approved in source form. Binary packages MUST be built from
>>>> the SIGNED and RELEASED source package, NOT FROM SUBVERSION TAGS.
>>>>
>>> This level of detail is definately not on the site that I've been able to
>>> find.
>>
>> It has been described many times, documented many times, and
>> periodically watered down by folks who don't know what they
>> are doing.
>
> Could be. I am not aware of any projects anywhere, at apache or elsewhere,
> that follow this to release anything. (I only know about java projects).
> Without exception every project I know about builds the "source" release
> artifact at the same time as the binary artifacts. Are there any java
> projects here at apache that follow the procedure Roy describes?
>
>>
>>
>>> The current example release process validates certain conditions and then
>>> makes a tag. That tag is then checked out and in the same motion, the
>>> binaries are produced and the source tar'd up and everything signed. All of
>>> these things, the source archives and binaries are then validated and voted
>>> upon.
>>>
>>> The end result is the same, the source archives contain the same code
>>> that produced the binaries, which is in agreement with the documented policy
>>> on the site:
>>>
>>> "In all such cases, the binary/bytecode package must have the same
>>> version number as the source release and may only add binary/bytecode files
>>> that are the result of compiling that version of the source code release."
>>>
>>> It seems like semantics that source must be tared, signed, untared and
>>> then rebuilt if it's all being done in the same action. Do we agree or
>>> disagree?
>>
>> No, it is not semantics. You assume that everything was tar'd correctly
>> and completely, which is not a valid assumption. Also, voting on binary
>> artifacts is inherently stupid because their quality cannot be verified.
>> That's why we specifically tell people not to vote on binaries, because
>> it just weakens the meaning of voting.
>
> Well, I could argue that you can't tell the quality of source code without
> compiling it and seeing if it works by testing. Quality can mean many
> things.
>
> Anyway... lets assume the process you describe is both apache policy and
> desirable. Clearly all the ant scripts and maven release profiles I've
> seen don't follow the policy. Let's try to think of some maven proecesses
> that would. I'm going to assume that any release process for java software
> needs to produce both source and binary artifacts that can be voted on at
> once, since I'm pretty sure not voting on binary artifacts would be rejected
> as impractical by most or all java projects.
I disagree with this generalization. The Java projects I've
participated in vote on source, not binary artifacts. However, I must
admit that votes tend to be based on a particular revision in
Subversion, rather than a source archive.
-Nathan
>
> 1. release process creates a scm tag, svn exports out the entire project at
> once (including possibly hundreds of maven projects), archives the whole
> thing, unpacks the archive, and performs the existing (e.g. maven) build.
>
> 2. release process creates an scm tag, checks it out, and builds source jars
> for each maven module that include all the java source, other main
> resources, and a (possibly modified to avoid trying to run tests) pom that
> will build the jar from the included source. These source jars are unpacked
> one by one to build the binary artifacts. No overall archive of the entire
> tag is needed. In particular no test code is included.
>
> Irrespective of how practical or advisable these processes are, is there any
> doubt they follow the policy Roy enunciated?
>
> thanks
> david jencks
>
>>
>>
>> ....Roy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Brian Fox <br...@infinity.nu>.
On Sat, May 9, 2009 at 11:09 PM, Brett Porter <br...@apache.org> wrote:
>
> On 10/05/2009, at 12:29 PM, Brian Fox wrote:
>
> Everything I saw was folks arguing about who had the right to decide on a
>> change that everyone seemed to agree on. If I missed it, can you please
>> point to the message ID where you pointed out that discrepancy?
>>
>
> I pointed it out several times on _this_ thread, that the docs and current
> practice didn't jive with what Roy said. This was never resolved here and I
> didn't see any point in bringing it up again once the other train was in
> motion.
>
>
> I thought it was clear in the reasoning I put with the patch, that I tried
> to capture what Roy said about building the binaries from source but push
> the responsibility to the RM to be sure they do the right thing than dictate
> it be done a certain way that may not make sense for some projects. I hoped
> that I hadn't watered it down too much, but I haven't heard any complaints.
>
> So, is there any actual issue with what got applied to the site in the end?
>
I can't say, I'm not Roy ;-)
>
> - Brett
>
Re: Clarification on the release requirements
Posted by Brett Porter <br...@apache.org>.
On 10/05/2009, at 12:29 PM, Brian Fox wrote:
> Everything I saw was folks arguing about who had the right to decide
> on a change that everyone seemed to agree on. If I missed it, can
> you please point to the message ID where you pointed out that
> discrepancy?
>
> I pointed it out several times on _this_ thread, that the docs and
> current practice didn't jive with what Roy said. This was never
> resolved here and I didn't see any point in bringing it up again
> once the other train was in motion.
I thought it was clear in the reasoning I put with the patch, that I
tried to capture what Roy said about building the binaries from source
but push the responsibility to the RM to be sure they do the right
thing than dictate it be done a certain way that may not make sense
for some projects. I hoped that I hadn't watered it down too much, but
I haven't heard any complaints.
So, is there any actual issue with what got applied to the site in the
end?
- Brett
Re: Clarification on the release requirements
Posted by Brian Fox <br...@infinity.nu>.
On Sat, May 9, 2009 at 9:33 PM, Brett Porter <br...@apache.org> wrote:
>
> On 10/05/2009, at 1:14 AM, Brian Fox wrote:
>
> I originally had hopes that we could drive this to some consensus and
>> carve it and begin the process of bringing projects into compliance with
>> whatever was decided. Unfortunately, the thread got hijacked to a
>> non-publically archived list (site-dev) where there apparently is no voting.
>>
>
> I don't think that's a fair characterization. I had no intention of
> hijacking the thread, I was trying to do something constructive with a
> decidedly non-constructive thread, in the place documented on the site
> currently as the place to discuss it. I told everyone where I was posting
> it. I thought it was publicly archived, I was wrong, but I'm sure we can fix
> that.
>
It had the effect of killing the discussion that I don't think was
completely non-constructive. There were some detours but it seemed like we
might have been getting somewhere. In hindsight, perhaps this isn't the
right list. However at the time, I assumed the release requirements derived
from legal requirements...and I was following up on the previous thread in
this list.
Based on the participation here, we got more varied input than what we saw
on the other list. I also think that the site-dev list might be appropriate
for wordsmithing some parts of dev related docs, but I don't believe that
foundation wide policy decisions should be made in the same fashion as
documenting things like how to use svn.
>
>
> People just make patches and the few people watching that list offer
>> suggestions which may or may not be included (or wiped away with whole new
>> patches) and then the documents are simply changed. If you're a member and
>> have access to those archives, I suggest you take a read for yourself,
>> perhaps it will be eye-opening for you as it was for me.
>>
>> The current changes that resulted from this didn't really go too far over
>> what was there and have the unfortunate side effect that there is still some
>> discrepancy in the oral tradition and what everyone does, meaning this will
>> come back eventually.
>>
>
> Everything I saw was folks arguing about who had the right to decide on a
> change that everyone seemed to agree on. If I missed it, can you please
> point to the message ID where you pointed out that discrepancy?
>
I pointed it out several times on _this_ thread, that the docs and current
practice didn't jive with what Roy said. This was never resolved here and I
didn't see any point in bringing it up again once the other train was in
motion.
>
> - Brett
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: Clarification on the release requirements
Posted by David Jencks <da...@yahoo.com>.
On May 9, 2009, at 8:14 AM, Brian Fox wrote:
>
>
> On Sat, May 9, 2009 at 10:59 AM, Lawrence Rosen
> <lr...@rosenlaw.com> wrote:
> Henri Yandell projected:
> > * Two lawyers wondered why this was wasting space on legal-discuss@.
>
> The rest of your 11 "clarifications" of project release made a
> little sense
> but, speaking for myself, this one misrepresents my opinion. (I
> won't speak
> for Jeff, though.)
>
> I think this is a very important topic to bring up at ASF, and I
> honestly
> believe that Roy's words, and a detailed description of the process
> you use
> to release software (as that process has evolved over time), ought
> to be
> carved somewhere on the ASF website. New members like me and new
> software
> projects that seek to join ASF would find this information useful.
>
> I originally had hopes that we could drive this to some consensus
> and carve it and begin the process of bringing projects into
> compliance with whatever was decided. Unfortunately, the thread got
> hijacked to a non-publically archived list (site-dev) where there
> apparently is no voting. People just make patches and the few people
> watching that list offer suggestions which may or may not be
> included (or wiped away with whole new patches) and then the
> documents are simply changed. If you're a member and have access to
> those archives, I suggest you take a read for yourself, perhaps it
> will be eye-opening for you as it was for me.
>
> The current changes that resulted from this didn't really go too far
> over what was there and have the unfortunate side effect that there
> is still some discrepancy in the oral tradition and what everyone
> does, meaning this will come back eventually.
From my point of view that is an accurate but rather polite
description of what happened. I'm rather disappointed but don't have
time to pursue it further right now.
thanks
david jencks
>
>
>
> And as a trademark lawyer for ASF, I'm really interested to
> understand the
> technical and voting process that members go through before the
> Apache brand
> is stamped on our software.
>
> /Larry
>
>
>
> > -----Original Message-----
> > From: Henri Yandell [mailto:hyandell@gmail.com]
> > Sent: Saturday, May 09, 2009 1:45 AM
> > To: legal-discuss@apache.org; lrosen@rosenlaw.com
> > Subject: Re: Clarification on the release requirements
> >
> > On Thu, Apr 30, 2009 at 10:40 AM, Lawrence Rosen <lrosen@rosenlaw.com
> >
> > wrote:
> > >> > Can we get this carved in marble somewhere? /Larry
> > >
> > > Jeff Thompson responded:
> > >> That would have to be a pretty big marble, or, I guess, very
> small
> > >> writing. ...
> > >
> > > Perhaps Jeff will volunteer to summarize this thread as ten bullet
> > items?
> > > :-)
> >
> > * Roy declared official policy based on tribal knowledge as known to
> > some sect at Apache (the C guys as usual).
> > * The next step is always a 100+ mail thread.
> > * Java guys in general professed ignorance to mask unhappiness at
> > having to be like the C guys.
> > * The Maven guys rallied around to push in the direction they're
> already
> > going.
> > * Joe made a land grab for Infra on being not only the maintainers
> of
> > dev/, but also the authors.
> > * General tech approach picks holes in the C method by suggesting
> the
> > RM might have them vote on a trick.
> > * Jochen suggests a compromise also known as the current Java
> approach.
> > * Git gets brought up because it's better than SVN.
> > * Two lawyers wondered why this was wasting space on legal-discuss@.
> > * Henri offended everyone by making rude and incorrect statements
> > regarding the thread.
> >
> > As a special bonus - #11:
> >
> > * Nothing much happens. Life goes on as usual in projects using a
> > perfectly reasonable release process in most people's eyes, dev/
> gets
> > something put in it that will still cause arguments and as no one is
> > told there has been a critical change it takes years to get out
> > through social networking where people use the dev/ page as
> > justification of their read. Hopefully we only end up with one set
> of
> > opinions floating out there, but more likely it ends up splintering
> > into three separate interpretations that end up as a thread on a
> > random mailing list 2 years later to deal with yet another detail.
> >
> > Personal thoughts.....
> >
> > If the unit tests pass, the release is good. What's all this "and we
> > test it on our particular platform before a +1"? [yeah, turns out
> the
> > testing you do is dependent on the project and I work on easy
> > projects].
> >
> > Sod the "you must build a source release, then build the binary".
> It's
> > easy enough to do what we're all doing and add a step to confirm
> that
> > the binary we build from the source release matches our binary
> > release.
> >
> > If someone does not believe that the release manager built from the
> > SVN tag, then they can also build source from SVN and compare.
> >
> > I'm amazed there's not been a suggestion that we build an
> application
> > to solve it. That's the real technical Godwin's Law - when a process
> > is being argued about and someone starts saying we should write
> > software.
> >
> > -- looking forward to discussing this topic at ApacheCon --
> >
> > Hen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: Clarification on the release requirements
Posted by Brett Porter <br...@apache.org>.
On 10/05/2009, at 1:14 AM, Brian Fox wrote:
> I originally had hopes that we could drive this to some consensus
> and carve it and begin the process of bringing projects into
> compliance with whatever was decided. Unfortunately, the thread got
> hijacked to a non-publically archived list (site-dev) where there
> apparently is no voting.
I don't think that's a fair characterization. I had no intention of
hijacking the thread, I was trying to do something constructive with a
decidedly non-constructive thread, in the place documented on the site
currently as the place to discuss it. I told everyone where I was
posting it. I thought it was publicly archived, I was wrong, but I'm
sure we can fix that.
> People just make patches and the few people watching that list offer
> suggestions which may or may not be included (or wiped away with
> whole new patches) and then the documents are simply changed. If
> you're a member and have access to those archives, I suggest you
> take a read for yourself, perhaps it will be eye-opening for you as
> it was for me.
>
> The current changes that resulted from this didn't really go too far
> over what was there and have the unfortunate side effect that there
> is still some discrepancy in the oral tradition and what everyone
> does, meaning this will come back eventually.
Everything I saw was folks arguing about who had the right to decide
on a change that everyone seemed to agree on. If I missed it, can you
please point to the message ID where you pointed out that discrepancy?
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Brian Fox <br...@infinity.nu>.
On Sat, May 9, 2009 at 10:59 AM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
> Henri Yandell projected:
> > * Two lawyers wondered why this was wasting space on legal-discuss@.
>
> The rest of your 11 "clarifications" of project release made a little sense
> but, speaking for myself, this one misrepresents my opinion. (I won't speak
> for Jeff, though.)
>
> I think this is a very important topic to bring up at ASF, and I honestly
> believe that Roy's words, and a detailed description of the process you use
> to release software (as that process has evolved over time), ought to be
> carved somewhere on the ASF website. New members like me and new software
> projects that seek to join ASF would find this information useful.
I originally had hopes that we could drive this to some consensus and carve
it and begin the process of bringing projects into compliance with whatever
was decided. Unfortunately, the thread got hijacked to a non-publically
archived list (site-dev) where there apparently is no voting. People just
make patches and the few people watching that list offer suggestions which
may or may not be included (or wiped away with whole new patches) and then
the documents are simply changed. If you're a member and have access to
those archives, I suggest you take a read for yourself, perhaps it will be
eye-opening for you as it was for me.
The current changes that resulted from this didn't really go too far over
what was there and have the unfortunate side effect that there is still some
discrepancy in the oral tradition and what everyone does, meaning this will
come back eventually.
>
> And as a trademark lawyer for ASF, I'm really interested to understand the
> technical and voting process that members go through before the Apache
> brand
> is stamped on our software.
>
> /Larry
>
>
>
> > -----Original Message-----
> > From: Henri Yandell [mailto:hyandell@gmail.com]
> > Sent: Saturday, May 09, 2009 1:45 AM
> > To: legal-discuss@apache.org; lrosen@rosenlaw.com
> > Subject: Re: Clarification on the release requirements
> >
> > On Thu, Apr 30, 2009 at 10:40 AM, Lawrence Rosen <lr...@rosenlaw.com>
> > wrote:
> > >> > Can we get this carved in marble somewhere? /Larry
> > >
> > > Jeff Thompson responded:
> > >> That would have to be a pretty big marble, or, I guess, very small
> > >> writing. ...
> > >
> > > Perhaps Jeff will volunteer to summarize this thread as ten bullet
> > items?
> > > :-)
> >
> > * Roy declared official policy based on tribal knowledge as known to
> > some sect at Apache (the C guys as usual).
> > * The next step is always a 100+ mail thread.
> > * Java guys in general professed ignorance to mask unhappiness at
> > having to be like the C guys.
> > * The Maven guys rallied around to push in the direction they're already
> > going.
> > * Joe made a land grab for Infra on being not only the maintainers of
> > dev/, but also the authors.
> > * General tech approach picks holes in the C method by suggesting the
> > RM might have them vote on a trick.
> > * Jochen suggests a compromise also known as the current Java approach.
> > * Git gets brought up because it's better than SVN.
> > * Two lawyers wondered why this was wasting space on legal-discuss@.
> > * Henri offended everyone by making rude and incorrect statements
> > regarding the thread.
> >
> > As a special bonus - #11:
> >
> > * Nothing much happens. Life goes on as usual in projects using a
> > perfectly reasonable release process in most people's eyes, dev/ gets
> > something put in it that will still cause arguments and as no one is
> > told there has been a critical change it takes years to get out
> > through social networking where people use the dev/ page as
> > justification of their read. Hopefully we only end up with one set of
> > opinions floating out there, but more likely it ends up splintering
> > into three separate interpretations that end up as a thread on a
> > random mailing list 2 years later to deal with yet another detail.
> >
> > Personal thoughts.....
> >
> > If the unit tests pass, the release is good. What's all this "and we
> > test it on our particular platform before a +1"? [yeah, turns out the
> > testing you do is dependent on the project and I work on easy
> > projects].
> >
> > Sod the "you must build a source release, then build the binary". It's
> > easy enough to do what we're all doing and add a step to confirm that
> > the binary we build from the source release matches our binary
> > release.
> >
> > If someone does not believe that the release manager built from the
> > SVN tag, then they can also build source from SVN and compare.
> >
> > I'm amazed there's not been a suggestion that we build an application
> > to solve it. That's the real technical Godwin's Law - when a process
> > is being argued about and someone starts saying we should write
> > software.
> >
> > -- looking forward to discussing this topic at ApacheCon --
> >
> > Hen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
RE: Clarification on the release requirements
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Henri Yandell projected:
> * Two lawyers wondered why this was wasting space on legal-discuss@.
The rest of your 11 "clarifications" of project release made a little sense
but, speaking for myself, this one misrepresents my opinion. (I won't speak
for Jeff, though.)
I think this is a very important topic to bring up at ASF, and I honestly
believe that Roy's words, and a detailed description of the process you use
to release software (as that process has evolved over time), ought to be
carved somewhere on the ASF website. New members like me and new software
projects that seek to join ASF would find this information useful.
And as a trademark lawyer for ASF, I'm really interested to understand the
technical and voting process that members go through before the Apache brand
is stamped on our software.
/Larry
> -----Original Message-----
> From: Henri Yandell [mailto:hyandell@gmail.com]
> Sent: Saturday, May 09, 2009 1:45 AM
> To: legal-discuss@apache.org; lrosen@rosenlaw.com
> Subject: Re: Clarification on the release requirements
>
> On Thu, Apr 30, 2009 at 10:40 AM, Lawrence Rosen <lr...@rosenlaw.com>
> wrote:
> >> > Can we get this carved in marble somewhere? /Larry
> >
> > Jeff Thompson responded:
> >> That would have to be a pretty big marble, or, I guess, very small
> >> writing. ...
> >
> > Perhaps Jeff will volunteer to summarize this thread as ten bullet
> items?
> > :-)
>
> * Roy declared official policy based on tribal knowledge as known to
> some sect at Apache (the C guys as usual).
> * The next step is always a 100+ mail thread.
> * Java guys in general professed ignorance to mask unhappiness at
> having to be like the C guys.
> * The Maven guys rallied around to push in the direction they're already
> going.
> * Joe made a land grab for Infra on being not only the maintainers of
> dev/, but also the authors.
> * General tech approach picks holes in the C method by suggesting the
> RM might have them vote on a trick.
> * Jochen suggests a compromise also known as the current Java approach.
> * Git gets brought up because it's better than SVN.
> * Two lawyers wondered why this was wasting space on legal-discuss@.
> * Henri offended everyone by making rude and incorrect statements
> regarding the thread.
>
> As a special bonus - #11:
>
> * Nothing much happens. Life goes on as usual in projects using a
> perfectly reasonable release process in most people's eyes, dev/ gets
> something put in it that will still cause arguments and as no one is
> told there has been a critical change it takes years to get out
> through social networking where people use the dev/ page as
> justification of their read. Hopefully we only end up with one set of
> opinions floating out there, but more likely it ends up splintering
> into three separate interpretations that end up as a thread on a
> random mailing list 2 years later to deal with yet another detail.
>
> Personal thoughts.....
>
> If the unit tests pass, the release is good. What's all this "and we
> test it on our particular platform before a +1"? [yeah, turns out the
> testing you do is dependent on the project and I work on easy
> projects].
>
> Sod the "you must build a source release, then build the binary". It's
> easy enough to do what we're all doing and add a step to confirm that
> the binary we build from the source release matches our binary
> release.
>
> If someone does not believe that the release manager built from the
> SVN tag, then they can also build source from SVN and compare.
>
> I'm amazed there's not been a suggestion that we build an application
> to solve it. That's the real technical Godwin's Law - when a process
> is being argued about and someone starts saying we should write
> software.
>
> -- looking forward to discussing this topic at ApacheCon --
>
> Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Henri Yandell <hy...@gmail.com>
> To: legal-discuss@apache.org; lrosen@rosenlaw.com
> Sent: Saturday, May 9, 2009 4:45:11 AM
> Subject: Re: Clarification on the release requirements
>
> On Thu, Apr 30, 2009 at 10:40 AM, Lawrence Rosen wrote:
> >> > Can we get this carved in marble somewhere? /Larry
> >
> > Jeff Thompson responded:
> >> That would have to be a pretty big marble, or, I guess, very small
> >> writing. ...
> >
> > Perhaps Jeff will volunteer to summarize this thread as ten bullet items?
> > :-)
>
> * Roy declared official policy based on tribal knowledge as known to
> some sect at Apache (the C guys as usual).
> * The next step is always a 100+ mail thread.
> * Java guys in general professed ignorance to mask unhappiness at
> having to be like the C guys.
> * The Maven guys rallied around to push in the direction they're already going.
> * Joe made a land grab for Infra on being not only the maintainers of
> dev/, but also the authors.
Not even close.
> * General tech approach picks holes in the C method by suggesting the
> RM might have them vote on a trick.
> * Jochen suggests a compromise also known as the current Java approach.
> * Git gets brought up because it's better than SVN.
> * Two lawyers wondered why this was wasting space on legal-discuss@.
> * Henri offended everyone by making rude and incorrect statements
> regarding the thread.
>
> As a special bonus - #11:
>
> * Nothing much happens. Life goes on as usual in projects using a
> perfectly reasonable release process in most people's eyes, dev/ gets
> something put in it that will still cause arguments and as no one is
> told there has been a critical change it takes years to get out
> through social networking where people use the dev/ page as
> justification of their read. Hopefully we only end up with one set of
> opinions floating out there, but more likely it ends up splintering
> into three separate interpretations that end up as a thread on a
> random mailing list 2 years later to deal with yet another detail.
>
> Personal thoughts.....
>
> If the unit tests pass, the release is good. What's all this "and we
> test it on our particular platform before a +1"? [yeah, turns out the
> testing you do is dependent on the project and I work on easy
> projects].
>
> Sod the "you must build a source release, then build the binary". It's
> easy enough to do what we're all doing and add a step to confirm that
> the binary we build from the source release matches our binary
> release.
>
> If someone does not believe that the release manager built from the
> SVN tag, then they can also build source from SVN and compare.
>
> I'm amazed there's not been a suggestion that we build an application
> to solve it. That's the real technical Godwin's Law - when a process
> is being argued about and someone starts saying we should write
> software.
Good christ Henri, I just posted the url of a 150 line perl script which
does exactly that. What a waste of time participating in this thread
has been for me.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Henri Yandell <hy...@gmail.com>.
On Thu, Apr 30, 2009 at 10:40 AM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
>> > Can we get this carved in marble somewhere? /Larry
>
> Jeff Thompson responded:
>> That would have to be a pretty big marble, or, I guess, very small
>> writing. ...
>
> Perhaps Jeff will volunteer to summarize this thread as ten bullet items?
> :-)
* Roy declared official policy based on tribal knowledge as known to
some sect at Apache (the C guys as usual).
* The next step is always a 100+ mail thread.
* Java guys in general professed ignorance to mask unhappiness at
having to be like the C guys.
* The Maven guys rallied around to push in the direction they're already going.
* Joe made a land grab for Infra on being not only the maintainers of
dev/, but also the authors.
* General tech approach picks holes in the C method by suggesting the
RM might have them vote on a trick.
* Jochen suggests a compromise also known as the current Java approach.
* Git gets brought up because it's better than SVN.
* Two lawyers wondered why this was wasting space on legal-discuss@.
* Henri offended everyone by making rude and incorrect statements
regarding the thread.
As a special bonus - #11:
* Nothing much happens. Life goes on as usual in projects using a
perfectly reasonable release process in most people's eyes, dev/ gets
something put in it that will still cause arguments and as no one is
told there has been a critical change it takes years to get out
through social networking where people use the dev/ page as
justification of their read. Hopefully we only end up with one set of
opinions floating out there, but more likely it ends up splintering
into three separate interpretations that end up as a thread on a
random mailing list 2 years later to deal with yet another detail.
Personal thoughts.....
If the unit tests pass, the release is good. What's all this "and we
test it on our particular platform before a +1"? [yeah, turns out the
testing you do is dependent on the project and I work on easy
projects].
Sod the "you must build a source release, then build the binary". It's
easy enough to do what we're all doing and add a step to confirm that
the binary we build from the source release matches our binary
release.
If someone does not believe that the release manager built from the
SVN tag, then they can also build source from SVN and compare.
I'm amazed there's not been a suggestion that we build an application
to solve it. That's the real technical Godwin's Law - when a process
is being argued about and someone starts saying we should write
software.
-- looking forward to discussing this topic at ApacheCon --
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: Clarification on the release requirements
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
> > Can we get this carved in marble somewhere? /Larry
Jeff Thompson responded:
> That would have to be a pretty big marble, or, I guess, very small
> writing. ...
Perhaps Jeff will volunteer to summarize this thread as ten bullet items?
:-)
/Larry
> -----Original Message-----
> From: Jeffrey Thompson [mailto:jthom@us.ibm.com]
> Sent: Wednesday, April 29, 2009 8:02 PM
> To: legal-discuss@apache.org
> Cc: legal-discuss@apache.org
> Subject: RE: Clarification on the release requirements
>
>
> "Lawrence Rosen" <lr...@rosenlaw.com> wrote on 04/29/2009 03:42:19 PM:
>
> > From:
> >
> > "Lawrence Rosen" <lr...@rosenlaw.com>
> >
> > To:
> >
> > <le...@apache.org>
> >
> > Date:
> >
> > 04/29/2009 03:43 PM
> >
> > Subject:
> >
> > RE: Clarification on the release requirements
> >
> > Roy Fielding wrote:
> > > The release process is critical because it is the point at which
> > > the ASF as an organization approves a release to the public. It is
> > > the point at which the ASF's liability and goodwill comes into play.
> > > The checkpoints are necessary to ensure that we don't release a
> product
> > > that isn't open source or that hasn't been reviewed by the peers,
> > > since either one would seriously damage the foundation. The
> > > consistency is necessary because it establishes a well-worn set
> > > of procedures that distinguish ASF projects from those at
> > > Sourceforge or Google code.
> >
> > Can we get this carved in marble somewhere? /Larry
> >
> >
> That would have to be a pretty big marble, or, I guess, very small
> writing. . ..
>
>
> OK, I admit. Its been a long day.
>
> Jeff
>
> Counsel, IBM Corporation
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: Clarification on the release requirements
Posted by Jeffrey Thompson <jt...@us.ibm.com>.
"Lawrence Rosen" <lr...@rosenlaw.com> wrote on 04/29/2009 03:42:19 PM:
> From:
>
> "Lawrence Rosen" <lr...@rosenlaw.com>
>
> To:
>
> <le...@apache.org>
>
> Date:
>
> 04/29/2009 03:43 PM
>
> Subject:
>
> RE: Clarification on the release requirements
>
> Roy Fielding wrote:
> > The release process is critical because it is the point at which
> > the ASF as an organization approves a release to the public. It is
> > the point at which the ASF's liability and goodwill comes into play.
> > The checkpoints are necessary to ensure that we don't release a product
> > that isn't open source or that hasn't been reviewed by the peers,
> > since either one would seriously damage the foundation. The
> > consistency is necessary because it establishes a well-worn set
> > of procedures that distinguish ASF projects from those at
> > Sourceforge or Google code.
>
> Can we get this carved in marble somewhere? /Larry
>
>
That would have to be a pretty big marble, or, I guess, very small
writing. . ..
OK, I admit. Its been a long day.
Jeff
Counsel, IBM Corporation
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Brian Fox <br...@infinity.nu>.
I don't mind taking a stab at a draft, once there's some agreement.
Lawrence Rosen wrote:
> Roy Fielding wrote:
>
>> The release process is critical because it is the point at which
>> the ASF as an organization approves a release to the public. It is
>> the point at which the ASF's liability and goodwill comes into play.
>> The checkpoints are necessary to ensure that we don't release a product
>> that isn't open source or that hasn't been reviewed by the peers,
>> since either one would seriously damage the foundation. The
>> consistency is necessary because it establishes a well-worn set
>> of procedures that distinguish ASF projects from those at
>> Sourceforge or Google code.
>>
>
> Can we get this carved in marble somewhere? /Larry
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: Clarification on the release requirements
Posted by Lawrence Rosen <lr...@rosenlaw.com>.
Roy Fielding wrote:
> The release process is critical because it is the point at which
> the ASF as an organization approves a release to the public. It is
> the point at which the ASF's liability and goodwill comes into play.
> The checkpoints are necessary to ensure that we don't release a product
> that isn't open source or that hasn't been reviewed by the peers,
> since either one would seriously damage the foundation. The
> consistency is necessary because it establishes a well-worn set
> of procedures that distinguish ASF projects from those at
> Sourceforge or Google code.
Can we get this carved in marble somewhere? /Larry
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Apr 28, 2009, at 5:26 PM, David Jencks wrote:
> On Apr 28, 2009, at 4:43 PM, Roy T. Fielding wrote:
>> No, it is not semantics. You assume that everything was tar'd
>> correctly
>> and completely, which is not a valid assumption. Also, voting on
>> binary
>> artifacts is inherently stupid because their quality cannot be
>> verified.
>> That's why we specifically tell people not to vote on binaries,
>> because
>> it just weakens the meaning of voting.
>
> Well, I could argue that you can't tell the quality of source code
> without compiling it and seeing if it works by testing. Quality
> can mean many things.
Of course, which is why we require a person to download the signed
source
code package, compile it as provided, and test the resulting executable
on their own platform *before* voting +1 on the release version.
> Anyway... lets assume the process you describe is both apache
> policy and desirable. Clearly all the ant scripts and maven
> release profiles I've seen don't follow the policy. Let's try to
> think of some maven proecesses that would. I'm going to assume
> that any release process for java software needs to produce both
> source and binary artifacts that can be voted on at once, since I'm
> pretty sure not voting on binary artifacts would be rejected as
> impractical by most or all java projects.
Wrong. All java projects are here at the ASF because they agreed
to abide by our release process in one form or another. The details
may differ by project, but the checkpoints are always the same.
Every once in a while a board member notices that some project has
gone off in the wilds and isn't following the process, at which point
they are informed that the project will follow our policy or be
shut down. I have yet to see a project successfully justify ignoring
those checkpoints just because they use a stupid build tool.
The release process is critical because it is the point at which
the ASF as an organization approves a release to the public. It is
the point at which the ASF's liability and goodwill comes into play.
The checkpoints are necessary to ensure that we don't release a product
that isn't open source or that hasn't been reviewed by the peers,
since either one would seriously damage the foundation. The
consistency is necessary because it establishes a well-worn set
of procedures that distinguish ASF projects from those at
Sourceforge or Google code.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by John Casey <ca...@gmail.com>.
> Agreed. When i was doing the abovementioned docs i came to
> understand that each PMC has lots of leeway in creating
> their processes, as long as some fundamental principles
> are adhered to. Some stuff is important to be consistent
> across ASF-wide.
>
The minimal common requirements are what we need written in stone
somewhere. If these principles haven't changed in 10 years, I think
it's safe to say they are inviolable...so it'd be okay to write them
that way. As for common sense or obviousness, I think this thread is a
demonstration that we'd be assuming too much in thinking that everyone
keeps this list in their heads. Having a document for this stuff will
also provide a checklist for implementers, to make sure we haven't
missed anything for which we might be smacked upside the head
(*cough*). :)
-john
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Improved Release Documentation [WAS Re: Clarification on the
release requirements]
Posted by Brian Fox <br...@infinity.nu>.
Robert Burrell Donkin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Brian Fox wrote:
>
>> Niclas Hedhman wrote:
>>
>>> On Wed, Apr 29, 2009 at 9:44 AM, Brian Fox <br...@infinity.nu> wrote:
>>>
>>>
>>>
>>>> How can you audit the PMCs when these policies are not even documented
>>>> anywhere? Perhaps the membership isn't even aware of these policies
>>>> to start
>>>> with and thus there might be wide disagreement? One can't know until
>>>> it's
>>>> written down and everyone can see it clearly.
>>>>
>>>>
>>> I wrote somewhere "advisory audit", meaning detection in malpractice
>>> and help to rectify.
>>>
>>> Clarifications to documents is of course better, BUT it also feels
>>> that ASF has grown so fast that many don't get TheApacheWay in this
>>> area, which saddens me.
>>>
>>>
>>>
>>>
>>>
>> Clarifications to the documents is the _only_ way to solve this once and
>> for all...otherwise everything is just an opinion, there's nothing
>> official. If there is, please point me to it. I think the process as
>> described so far is pretty overbearing, but that's just my opinion for
>> now and as such pretty irrelevant. We can't really build a proper
>> process on unofficial opinions, mine or anyone else's. (well we could,
>> but then we'd be back to the discussion again and again).
>>
>
> documentation != policy
>
> but yes, we need better documentation (we've know that for years)
>
> IMO one of the problems (and reasons why i stopped writing documentation
> for the foundation) is that they had started to be taken as the
> immutable gospel when it represented my own interpretation of the
> unspoken consensus
>
>
>> I can hear the passion in Roy's emails but what surprises me is that if
>> it's so fundamental and passionate, that it is completely not covered
>> anywhere public. And because of that, the current (seemingly not legit
>> process) is so widespread throughout the organization, which no offense
>> intended, makes me curious if we have the whole story so far.
>>
>
> historically, apache has tried to run on as little policy as possible.
> documentation, guidelines, strong opinions fine but policy is hard to
> frame and consensus difficult to achieve. too much detailed policy also
> has the disadvantage that it reduces the agility of an organisation and
> the diversity of experiment within it.
>
> <legal-committee-hat>
> it's taken a while but the current processes used at apache are now
> mostly ok from a legal perspective. due diligence is done, licenses are
> checked, releases are reviewed by the PMC and voted upon. i do not see
> that detailed process policy on the release process is within the scope
> of our role.
> </legal-committee-hat>
>
> IMO the right vehicle for improved release standards and practice is
> through developing better descriptive documentation in the incubator. i
> switched my documentation efforts there but i've been focussed more on
> coding over the last few years.
>
> i would like to see a collective effort to finish off the guidelines and
> best practice advice especially in the release area. IMHO this would be
> the most positive way to solve this problem. however, IMHO a diversity
> of opinions is needed.
>
> anyone else interested?
>
+1
> - - robert
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkn5c2kACgkQQ617goCdfgOFOQCfd8Nb0+o4a8/E47myAnaVJgmG
> CVUAoOLCw7+rS3wS+qo/yXBsa1XIjvxF
> =OxO2
> -----END PGP SIGNATURE-----
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Improved Release Documentation [WAS Re: Clarification on the release
requirements]
Posted by Robert Burrell Donkin <rd...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brian Fox wrote:
>
>
> Niclas Hedhman wrote:
>> On Wed, Apr 29, 2009 at 9:44 AM, Brian Fox <br...@infinity.nu> wrote:
>>
>>
>>> How can you audit the PMCs when these policies are not even documented
>>> anywhere? Perhaps the membership isn't even aware of these policies
>>> to start
>>> with and thus there might be wide disagreement? One can't know until
>>> it's
>>> written down and everyone can see it clearly.
>>>
>>
>> I wrote somewhere "advisory audit", meaning detection in malpractice
>> and help to rectify.
>>
>> Clarifications to documents is of course better, BUT it also feels
>> that ASF has grown so fast that many don't get TheApacheWay in this
>> area, which saddens me.
>>
>>
>>
>>
> Clarifications to the documents is the _only_ way to solve this once and
> for all...otherwise everything is just an opinion, there's nothing
> official. If there is, please point me to it. I think the process as
> described so far is pretty overbearing, but that's just my opinion for
> now and as such pretty irrelevant. We can't really build a proper
> process on unofficial opinions, mine or anyone else's. (well we could,
> but then we'd be back to the discussion again and again).
documentation != policy
but yes, we need better documentation (we've know that for years)
IMO one of the problems (and reasons why i stopped writing documentation
for the foundation) is that they had started to be taken as the
immutable gospel when it represented my own interpretation of the
unspoken consensus
> I can hear the passion in Roy's emails but what surprises me is that if
> it's so fundamental and passionate, that it is completely not covered
> anywhere public. And because of that, the current (seemingly not legit
> process) is so widespread throughout the organization, which no offense
> intended, makes me curious if we have the whole story so far.
historically, apache has tried to run on as little policy as possible.
documentation, guidelines, strong opinions fine but policy is hard to
frame and consensus difficult to achieve. too much detailed policy also
has the disadvantage that it reduces the agility of an organisation and
the diversity of experiment within it.
<legal-committee-hat>
it's taken a while but the current processes used at apache are now
mostly ok from a legal perspective. due diligence is done, licenses are
checked, releases are reviewed by the PMC and voted upon. i do not see
that detailed process policy on the release process is within the scope
of our role.
</legal-committee-hat>
IMO the right vehicle for improved release standards and practice is
through developing better descriptive documentation in the incubator. i
switched my documentation efforts there but i've been focussed more on
coding over the last few years.
i would like to see a collective effort to finish off the guidelines and
best practice advice especially in the release area. IMHO this would be
the most positive way to solve this problem. however, IMHO a diversity
of opinions is needed.
anyone else interested?
- - robert
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkn5c2kACgkQQ617goCdfgOFOQCfd8Nb0+o4a8/E47myAnaVJgmG
CVUAoOLCw7+rS3wS+qo/yXBsa1XIjvxF
=OxO2
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Brian Fox wrote:
>
> I can hear the passion in Roy's emails but what surprises me is that if
> it's so fundamental and passionate, that it is completely not covered
> anywhere public. And because of that, the current (seemingly not legit
> process) is so widespread throughout the organization, which no offense
> intended, makes me curious if we have the whole story so far.
Original; http://httpd.apache.org/dev/voting.html - this is pre-existence
of the foundation itself.
Details are often modified for the specific situations of the code, but the
essential principals remain the same. E.g. the currently observed httpd
guidelines are at;
http://httpd.apache.org/dev/guidelines.html
http://httpd.apache.org/dev/release.html
Roy will undoubtedly point out some mistake in these (and probably just
commit a correction).
For example, evens-odds release number patterns? Totally a situational
choice of the PMC. ABI Versioning rules? Entirely different from, say,
the APR project.
But voting guidelines? Static, involatile artifact. Principal that any
PMC member may assemble a source candidate for release, for consideration
by an up or down vote of the majority by project members? Fixed, to
prevent any individual from blocking progress of a project.
Anyways, just an original document to ponder; it's probably long past
time for the absolute requirements to be harvested and gathered at
http://www.apache.org/dev/;
http://web.archive.org/web/20010516002155/http://dev.apache.org/
was then migrated to http://httpd.apache.org/dev/ in late 2001/early 2002,
breaking the links to some of this information.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Ralph Goers <ra...@dslextreme.com>.
This is ridiculous. I spent 5 minutes looking at a few projects and
came up with web pages that are just as "authorative" as http://httpd.apache.org/release.html
. I'm sure there are many more.
http://commons.apache.org/releases/index.html and http://wiki.apache.org/commons/CreatingReleases
http://cocoon.apache.org/1199_1_1.html
http://wiki.apache.org/myfaces/ReleaseHowTo
http://incubator.apache.org/guides/releasemanagement.html
http://jackrabbit.apache.org/creating-releases.html.
These are all pages managed by the respective project PMCs. If there
is a common policy the various projects need to adhere to then it
needs to be in http://www.apache.org/dev. Obviously the current
releases page there is sufficiently ambiguous that most of these (if
not all - I didn't read them all) don't follow the process outlined by
Roy.
Ralph
On Apr 28, 2009, at 9:04 PM, Nathan Beyer wrote:
> I'd agree that the policy Roy mentioned isn't concretely defined in a
> single document, but I think it's more than just an oral history.
>
> Between the HTTP Server's release doc [1], which documents the exact
> steps Roy mentioned, and release documents in /dev [2], I believe the
> intent is there. Most of the docs related to releases actually ask for
> help [3] to be completed.
>
> What are people waiting for to submit patches to these documents?
>
> BTW - it seems like it's time to move this discussion elsewhere, as
> this has gone past legal questions and into ASF policy, though I'm not
> sure where would be best to move it.
>
> -Nathan
>
> [1] http://httpd.apache.org/dev/release.html
> [2] http://www.apache.org/dev/#releases
> [3] http://www.apache.org/dev/release-signing.html#help
>
>
> On Tue, Apr 28, 2009 at 10:05 PM, John Casey
> <ca...@gmail.com> wrote:
>> IMHO, we're in a position to do better than an oral history for
>> Apache.
>>
>> I know we've all spent quite a lot of time over the years
>> implementing
>> someone else's specification. That's what we've tried to do with
>> Maven, to the best of our understanding. We've revised the plugin
>> suite time and again to accommodate (and improve our adherence to)
>> the
>> release process as we understood it here at ASF. Obviously, there are
>> quite a few fairly prominent people around here who can't agree on
>> how
>> to release software, so why on earth would we not write something up
>> that reflects the concreteness being expressed here? If we did,
>> authors of build tools might have a specification to follow, and get
>> this right.
>>
>> I for one have no interest whatsoever in which alternative is
>> "correct". My only interest is finding a clear, well-documented set
>> of
>> standards that I can implement in Maven.
>>
>> BTW, listing those standards in this thread is not good enough IMO.
>> There needs to be a good place where people like me can go to learn
>> (and use as a reference) what _exactly_ is the Apache Way.
>>
>> Cheers,
>>
>> -john
>>
>> On Tue, Apr 28, 2009 at 10:01 PM, Brian Fox <br...@infinity.nu>
>> wrote:
>>>
>>>
>>> Niclas Hedhman wrote:
>>>>
>>>> On Wed, Apr 29, 2009 at 9:44 AM, Brian Fox <br...@infinity.nu>
>>>> wrote:
>>>>
>>>>
>>>>>
>>>>> How can you audit the PMCs when these policies are not even
>>>>> documented
>>>>> anywhere? Perhaps the membership isn't even aware of these
>>>>> policies to
>>>>> start
>>>>> with and thus there might be wide disagreement? One can't know
>>>>> until it's
>>>>> written down and everyone can see it clearly.
>>>>>
>>>>
>>>> I wrote somewhere "advisory audit", meaning detection in
>>>> malpractice
>>>> and help to rectify.
>>>>
>>>> Clarifications to documents is of course better, BUT it also feels
>>>> that ASF has grown so fast that many don't get TheApacheWay in this
>>>> area, which saddens me.
>>>>
>>>>
>>>>
>>>>
>>>
>>> Clarifications to the documents is the _only_ way to solve this
>>> once and for
>>> all...otherwise everything is just an opinion, there's nothing
>>> official. If
>>> there is, please point me to it. I think the process as described
>>> so far is
>>> pretty overbearing, but that's just my opinion for now and as such
>>> pretty
>>> irrelevant. We can't really build a proper process on unofficial
>>> opinions,
>>> mine or anyone else's. (well we could, but then we'd be back to the
>>> discussion again and again).
>>>
>>> I can hear the passion in Roy's emails but what surprises me is
>>> that if it's
>>> so fundamental and passionate, that it is completely not covered
>>> anywhere
>>> public. And because of that, the current (seemingly not legit
>>> process) is so
>>> widespread throughout the organization, which no offense intended,
>>> makes me
>>> curious if we have the whole story so far.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>
>>>
>>
>>
>>
>> --
>> John Casey
>> ---
>> Maven Developer (http://maven.apache.org)
>> ---
>> Blog: http://www.ejlife.net/blogs/buildchimp
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
John Casey wrote:
> This is going to sound stupid maybe, but I would never think to look
> at httpd's release docs in order to learn about the official process
> for all of ASF, even though I know that's the founding project. As far
> as intent goes, unfortunately it's nearly impossible to write code
> that automates intentions.
Right - My point wasn't that you are expected to be psychic, the point
is that resources on dev.apache.org went poof when www.apache.org was
reorganized, and httpd.apache.org (and other TLP.apache.org sites) came
into being.
So the question - how the heck does anyone know these things? Where are
they written down? Etc... well, that's an issue that needs addressing.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by John Casey <ca...@gmail.com>.
This is going to sound stupid maybe, but I would never think to look
at httpd's release docs in order to learn about the official process
for all of ASF, even though I know that's the founding project. As far
as intent goes, unfortunately it's nearly impossible to write code
that automates intentions.
As I'm sure my contributions to this thread show, I'm probably not the
person you want writing patches for the release process document; it's
apparent that my understanding of the process needs correction. BTW,
I've read the releases FAQ, and was under the impression that Maven
wasn't doing so terribly bad at its job here at ASF...
On Wed, Apr 29, 2009 at 12:04 AM, Nathan Beyer <nd...@apache.org> wrote:
> I'd agree that the policy Roy mentioned isn't concretely defined in a
> single document, but I think it's more than just an oral history.
>
> Between the HTTP Server's release doc [1], which documents the exact
> steps Roy mentioned, and release documents in /dev [2], I believe the
> intent is there. Most of the docs related to releases actually ask for
> help [3] to be completed.
>
> What are people waiting for to submit patches to these documents?
>
> BTW - it seems like it's time to move this discussion elsewhere, as
> this has gone past legal questions and into ASF policy, though I'm not
> sure where would be best to move it.
>
> -Nathan
>
> [1] http://httpd.apache.org/dev/release.html
> [2] http://www.apache.org/dev/#releases
> [3] http://www.apache.org/dev/release-signing.html#help
>
>
> On Tue, Apr 28, 2009 at 10:05 PM, John Casey <ca...@gmail.com> wrote:
>> IMHO, we're in a position to do better than an oral history for Apache.
>>
>> I know we've all spent quite a lot of time over the years implementing
>> someone else's specification. That's what we've tried to do with
>> Maven, to the best of our understanding. We've revised the plugin
>> suite time and again to accommodate (and improve our adherence to) the
>> release process as we understood it here at ASF. Obviously, there are
>> quite a few fairly prominent people around here who can't agree on how
>> to release software, so why on earth would we not write something up
>> that reflects the concreteness being expressed here? If we did,
>> authors of build tools might have a specification to follow, and get
>> this right.
>>
>> I for one have no interest whatsoever in which alternative is
>> "correct". My only interest is finding a clear, well-documented set of
>> standards that I can implement in Maven.
>>
>> BTW, listing those standards in this thread is not good enough IMO.
>> There needs to be a good place where people like me can go to learn
>> (and use as a reference) what _exactly_ is the Apache Way.
>>
>> Cheers,
>>
>> -john
>>
>> On Tue, Apr 28, 2009 at 10:01 PM, Brian Fox <br...@infinity.nu> wrote:
>>>
>>>
>>> Niclas Hedhman wrote:
>>>>
>>>> On Wed, Apr 29, 2009 at 9:44 AM, Brian Fox <br...@infinity.nu> wrote:
>>>>
>>>>
>>>>>
>>>>> How can you audit the PMCs when these policies are not even documented
>>>>> anywhere? Perhaps the membership isn't even aware of these policies to
>>>>> start
>>>>> with and thus there might be wide disagreement? One can't know until it's
>>>>> written down and everyone can see it clearly.
>>>>>
>>>>
>>>> I wrote somewhere "advisory audit", meaning detection in malpractice
>>>> and help to rectify.
>>>>
>>>> Clarifications to documents is of course better, BUT it also feels
>>>> that ASF has grown so fast that many don't get TheApacheWay in this
>>>> area, which saddens me.
>>>>
>>>>
>>>>
>>>>
>>>
>>> Clarifications to the documents is the _only_ way to solve this once and for
>>> all...otherwise everything is just an opinion, there's nothing official. If
>>> there is, please point me to it. I think the process as described so far is
>>> pretty overbearing, but that's just my opinion for now and as such pretty
>>> irrelevant. We can't really build a proper process on unofficial opinions,
>>> mine or anyone else's. (well we could, but then we'd be back to the
>>> discussion again and again).
>>>
>>> I can hear the passion in Roy's emails but what surprises me is that if it's
>>> so fundamental and passionate, that it is completely not covered anywhere
>>> public. And because of that, the current (seemingly not legit process) is so
>>> widespread throughout the organization, which no offense intended, makes me
>>> curious if we have the whole story so far.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>
>>>
>>
>>
>>
>> --
>> John Casey
>> ---
>> Maven Developer (http://maven.apache.org)
>> ---
>> Blog: http://www.ejlife.net/blogs/buildchimp
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
--
John Casey
---
Maven Developer (http://maven.apache.org)
---
Blog: http://www.ejlife.net/blogs/buildchimp
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by David Crossley <cr...@apache.org>.
Jason van Zyl wrote:
> Nathan Beyer wrote:
> >
> >I'd agree that the policy Roy mentioned isn't concretely defined in a
> >single document, but I think it's more than just an oral history.
A lot of it is common-sense, once one understands the principles
of how/why the ASF operates/exists, e.g. due process because we are
a corporation; open source releases go at a.o/dist; PMCs responsible
at the project level; protected if we follow due process; etc.
> >Between the HTTP Server's release doc [1], which documents the exact
> >steps Roy mentioned, and release documents in /dev [2], I believe the
> >intent is there. Most of the docs related to releases actually ask for
> >help [3] to be completed.
> >
> >What are people waiting for to submit patches to these documents?
Hear, hear.
I tried a while ago to help document some things at a.o/dev
and expand the "how it works" doc. A lot of stuff is not
written down. While there is good stuff in the mail archives,
and a lot is obvious, it helps to have it in docs so that we
can minimise such endless discussion and misunderstanding.
> As no one thinks documents in the HTTPD project are specific to the
> entire organization. I'm sure the vast majority of committers, who are
> Java developers, are not going to look at the HTTPD project for
> release guidelines. I don't think anyone could reasonably infer that
> after 10 years of existence organizational wide guidelines are
> actually not at an organizational level. If it's not clearly
> documented at an organizational level then it's anecdotal not
> prescriptive. What's on mailing lists, what people talk about at
> ApacheCon, or what's buried on the HTTPD site is not something a
> typical committer here is going to have access to or know how to find.
> That's obvious from the discussion.
When i started with Forrest as its initial chair,
it felt obvious to me to create our "project guidelines"
and release process documents by looking at other projects.
HTTP Server because it was the initial project and so
would demonstrate the principles, and Ant because i was led
there by Stefan's excellent "how to mirror" document.
> This information has been poorly past on because 7-8 years ago none of
> the Java projects I started volunteering for used these guidelines. So
> obviously no one knew what Roy was talking about even then. Something
> was lost way, way back. I followed what was already being used, no one
> told me to look at HTTPD, there's never been any workshops at any
> ApacheCons about releases, it's vague at best for projects starting in
> the incubator.
>
> When the Maven, Geronimo and CXF project cooperated to improve the
> release tooling for Maven not a single one of us knew about that
> document in HTTPD. There are also huge debates every year that come up
> again and again about the legal validity and release process so,
> again, obviously we are not there at an organization level.
>
> Whatever the rules are, they need to be clear, accepted and well
> documented at an organization level so that everyone can follow them.
Agreed. When i was doing the abovementioned docs i came to
understand that each PMC has lots of leeway in creating
their processes, as long as some fundamental principles
are adhered to. Some stuff is important to be consistent
across ASF-wide.
-David
> >BTW - it seems like it's time to move this discussion elsewhere, as
> >this has gone past legal questions and into ASF policy, though I'm not
> >sure where would be best to move it.
> >
> >-Nathan
> >
> >[1] http://httpd.apache.org/dev/release.html
> >[2] http://www.apache.org/dev/#releases
> >[3] http://www.apache.org/dev/release-signing.html#help
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Ralph Goers <ra...@dslextreme.com>.
I would suggest that to be accepted whatever gets written up should be
discussed on the members list before being (semi)permanently posted on
the web site. A good starting point would be to just take what Roy
wrote and discuss that. The major difference between what projects
seem to be doing and what he is advocating is the binary distribution
builds are currently done from svn, not the packaged source
distribution.
On Apr 28, 2009, at 10:40 PM, Niclas Hedhman wrote:
> On Wed, Apr 29, 2009 at 1:20 PM, Jason van Zyl
> <jv...@sonatype.com> wrote:
>> Something was lost way,
>> way back. I followed what was already being used, no one told me to
>> look at
>> HTTPD, there's never been any workshops at any ApacheCons about
>> releases,
>> it's vague at best for projects starting in the incubator.
>
>> Whatever the rules are, they need to be clear, accepted and well
>> documented
>> at an organization level so that everyone can follow them.
>
> I/We hear you, and I'll try to chip in over the weekend if the
> "government" allows me.
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://www.qi4j.org - New Energy for Java
>
> I live here; http://tinyurl.com/2qq9er
> I work here; http://tinyurl.com/2ymelc
> I relax here; http://tinyurl.com/2cgsug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Apr 29, 2009 at 1:20 PM, Jason van Zyl <jv...@sonatype.com> wrote:
> Something was lost way,
> way back. I followed what was already being used, no one told me to look at
> HTTPD, there's never been any workshops at any ApacheCons about releases,
> it's vague at best for projects starting in the incubator.
> Whatever the rules are, they need to be clear, accepted and well documented
> at an organization level so that everyone can follow them.
I/We hear you, and I'll try to chip in over the weekend if the
"government" allows me.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Jason van Zyl <jv...@sonatype.com>.
On 28-Apr-09, at 9:04 PM, Nathan Beyer wrote:
> I'd agree that the policy Roy mentioned isn't concretely defined in a
> single document, but I think it's more than just an oral history.
>
> Between the HTTP Server's release doc [1], which documents the exact
> steps Roy mentioned, and release documents in /dev [2], I believe the
> intent is there. Most of the docs related to releases actually ask for
> help [3] to be completed.
>
> What are people waiting for to submit patches to these documents?
>
As no one thinks documents in the HTTPD project are specific to the
entire organization. I'm sure the vast majority of committers, who are
Java developers, are not going to look at the HTTPD project for
release guidelines. I don't think anyone could reasonably infer that
after 10 years of existence organizational wide guidelines are
actually not at an organizational level. If it's not clearly
documented at an organizational level then it's anecdotal not
prescriptive. What's on mailing lists, what people talk about at
ApacheCon, or what's buried on the HTTPD site is not something a
typical committer here is going to have access to or know how to find.
That's obvious from the discussion.
This information has been poorly past on because 7-8 years ago none of
the Java projects I started volunteering for used these guidelines. So
obviously no one knew what Roy was talking about even then. Something
was lost way, way back. I followed what was already being used, no one
told me to look at HTTPD, there's never been any workshops at any
ApacheCons about releases, it's vague at best for projects starting in
the incubator.
When the Maven, Geronimo and CXF project cooperated to improve the
release tooling for Maven not a single one of us knew about that
document in HTTPD. There are also huge debates every year that come up
again and again about the legal validity and release process so,
again, obviously we are not there at an organization level.
Whatever the rules are, they need to be clear, accepted and well
documented at an organization level so that everyone can follow them.
> BTW - it seems like it's time to move this discussion elsewhere, as
> this has gone past legal questions and into ASF policy, though I'm not
> sure where would be best to move it.
>
> -Nathan
>
> [1] http://httpd.apache.org/dev/release.html
> [2] http://www.apache.org/dev/#releases
> [3] http://www.apache.org/dev/release-signing.html#help
>
>
> On Tue, Apr 28, 2009 at 10:05 PM, John Casey
> <ca...@gmail.com> wrote:
>> IMHO, we're in a position to do better than an oral history for
>> Apache.
>>
>> I know we've all spent quite a lot of time over the years
>> implementing
>> someone else's specification. That's what we've tried to do with
>> Maven, to the best of our understanding. We've revised the plugin
>> suite time and again to accommodate (and improve our adherence to)
>> the
>> release process as we understood it here at ASF. Obviously, there are
>> quite a few fairly prominent people around here who can't agree on
>> how
>> to release software, so why on earth would we not write something up
>> that reflects the concreteness being expressed here? If we did,
>> authors of build tools might have a specification to follow, and get
>> this right.
>>
>> I for one have no interest whatsoever in which alternative is
>> "correct". My only interest is finding a clear, well-documented set
>> of
>> standards that I can implement in Maven.
>>
>> BTW, listing those standards in this thread is not good enough IMO.
>> There needs to be a good place where people like me can go to learn
>> (and use as a reference) what _exactly_ is the Apache Way.
>>
>> Cheers,
>>
>> -john
>>
>> On Tue, Apr 28, 2009 at 10:01 PM, Brian Fox <br...@infinity.nu>
>> wrote:
>>>
>>>
>>> Niclas Hedhman wrote:
>>>>
>>>> On Wed, Apr 29, 2009 at 9:44 AM, Brian Fox <br...@infinity.nu>
>>>> wrote:
>>>>
>>>>
>>>>>
>>>>> How can you audit the PMCs when these policies are not even
>>>>> documented
>>>>> anywhere? Perhaps the membership isn't even aware of these
>>>>> policies to
>>>>> start
>>>>> with and thus there might be wide disagreement? One can't know
>>>>> until it's
>>>>> written down and everyone can see it clearly.
>>>>>
>>>>
>>>> I wrote somewhere "advisory audit", meaning detection in
>>>> malpractice
>>>> and help to rectify.
>>>>
>>>> Clarifications to documents is of course better, BUT it also feels
>>>> that ASF has grown so fast that many don't get TheApacheWay in this
>>>> area, which saddens me.
>>>>
>>>>
>>>>
>>>>
>>>
>>> Clarifications to the documents is the _only_ way to solve this
>>> once and for
>>> all...otherwise everything is just an opinion, there's nothing
>>> official. If
>>> there is, please point me to it. I think the process as described
>>> so far is
>>> pretty overbearing, but that's just my opinion for now and as such
>>> pretty
>>> irrelevant. We can't really build a proper process on unofficial
>>> opinions,
>>> mine or anyone else's. (well we could, but then we'd be back to the
>>> discussion again and again).
>>>
>>> I can hear the passion in Roy's emails but what surprises me is
>>> that if it's
>>> so fundamental and passionate, that it is completely not covered
>>> anywhere
>>> public. And because of that, the current (seemingly not legit
>>> process) is so
>>> widespread throughout the organization, which no offense intended,
>>> makes me
>>> curious if we have the whole story so far.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>
>>>
>>
>>
>>
>> --
>> John Casey
>> ---
>> Maven Developer (http://maven.apache.org)
>> ---
>> Blog: http://www.ejlife.net/blogs/buildchimp
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
Simplex sigillum veri. (Simplicity is the seal of truth.)
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Nathan Beyer <nd...@apache.org>.
I'd agree that the policy Roy mentioned isn't concretely defined in a
single document, but I think it's more than just an oral history.
Between the HTTP Server's release doc [1], which documents the exact
steps Roy mentioned, and release documents in /dev [2], I believe the
intent is there. Most of the docs related to releases actually ask for
help [3] to be completed.
What are people waiting for to submit patches to these documents?
BTW - it seems like it's time to move this discussion elsewhere, as
this has gone past legal questions and into ASF policy, though I'm not
sure where would be best to move it.
-Nathan
[1] http://httpd.apache.org/dev/release.html
[2] http://www.apache.org/dev/#releases
[3] http://www.apache.org/dev/release-signing.html#help
On Tue, Apr 28, 2009 at 10:05 PM, John Casey <ca...@gmail.com> wrote:
> IMHO, we're in a position to do better than an oral history for Apache.
>
> I know we've all spent quite a lot of time over the years implementing
> someone else's specification. That's what we've tried to do with
> Maven, to the best of our understanding. We've revised the plugin
> suite time and again to accommodate (and improve our adherence to) the
> release process as we understood it here at ASF. Obviously, there are
> quite a few fairly prominent people around here who can't agree on how
> to release software, so why on earth would we not write something up
> that reflects the concreteness being expressed here? If we did,
> authors of build tools might have a specification to follow, and get
> this right.
>
> I for one have no interest whatsoever in which alternative is
> "correct". My only interest is finding a clear, well-documented set of
> standards that I can implement in Maven.
>
> BTW, listing those standards in this thread is not good enough IMO.
> There needs to be a good place where people like me can go to learn
> (and use as a reference) what _exactly_ is the Apache Way.
>
> Cheers,
>
> -john
>
> On Tue, Apr 28, 2009 at 10:01 PM, Brian Fox <br...@infinity.nu> wrote:
>>
>>
>> Niclas Hedhman wrote:
>>>
>>> On Wed, Apr 29, 2009 at 9:44 AM, Brian Fox <br...@infinity.nu> wrote:
>>>
>>>
>>>>
>>>> How can you audit the PMCs when these policies are not even documented
>>>> anywhere? Perhaps the membership isn't even aware of these policies to
>>>> start
>>>> with and thus there might be wide disagreement? One can't know until it's
>>>> written down and everyone can see it clearly.
>>>>
>>>
>>> I wrote somewhere "advisory audit", meaning detection in malpractice
>>> and help to rectify.
>>>
>>> Clarifications to documents is of course better, BUT it also feels
>>> that ASF has grown so fast that many don't get TheApacheWay in this
>>> area, which saddens me.
>>>
>>>
>>>
>>>
>>
>> Clarifications to the documents is the _only_ way to solve this once and for
>> all...otherwise everything is just an opinion, there's nothing official. If
>> there is, please point me to it. I think the process as described so far is
>> pretty overbearing, but that's just my opinion for now and as such pretty
>> irrelevant. We can't really build a proper process on unofficial opinions,
>> mine or anyone else's. (well we could, but then we'd be back to the
>> discussion again and again).
>>
>> I can hear the passion in Roy's emails but what surprises me is that if it's
>> so fundamental and passionate, that it is completely not covered anywhere
>> public. And because of that, the current (seemingly not legit process) is so
>> widespread throughout the organization, which no offense intended, makes me
>> curious if we have the whole story so far.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>
>
>
> --
> John Casey
> ---
> Maven Developer (http://maven.apache.org)
> ---
> Blog: http://www.ejlife.net/blogs/buildchimp
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by John Casey <ca...@gmail.com>.
IMHO, we're in a position to do better than an oral history for Apache.
I know we've all spent quite a lot of time over the years implementing
someone else's specification. That's what we've tried to do with
Maven, to the best of our understanding. We've revised the plugin
suite time and again to accommodate (and improve our adherence to) the
release process as we understood it here at ASF. Obviously, there are
quite a few fairly prominent people around here who can't agree on how
to release software, so why on earth would we not write something up
that reflects the concreteness being expressed here? If we did,
authors of build tools might have a specification to follow, and get
this right.
I for one have no interest whatsoever in which alternative is
"correct". My only interest is finding a clear, well-documented set of
standards that I can implement in Maven.
BTW, listing those standards in this thread is not good enough IMO.
There needs to be a good place where people like me can go to learn
(and use as a reference) what _exactly_ is the Apache Way.
Cheers,
-john
On Tue, Apr 28, 2009 at 10:01 PM, Brian Fox <br...@infinity.nu> wrote:
>
>
> Niclas Hedhman wrote:
>>
>> On Wed, Apr 29, 2009 at 9:44 AM, Brian Fox <br...@infinity.nu> wrote:
>>
>>
>>>
>>> How can you audit the PMCs when these policies are not even documented
>>> anywhere? Perhaps the membership isn't even aware of these policies to
>>> start
>>> with and thus there might be wide disagreement? One can't know until it's
>>> written down and everyone can see it clearly.
>>>
>>
>> I wrote somewhere "advisory audit", meaning detection in malpractice
>> and help to rectify.
>>
>> Clarifications to documents is of course better, BUT it also feels
>> that ASF has grown so fast that many don't get TheApacheWay in this
>> area, which saddens me.
>>
>>
>>
>>
>
> Clarifications to the documents is the _only_ way to solve this once and for
> all...otherwise everything is just an opinion, there's nothing official. If
> there is, please point me to it. I think the process as described so far is
> pretty overbearing, but that's just my opinion for now and as such pretty
> irrelevant. We can't really build a proper process on unofficial opinions,
> mine or anyone else's. (well we could, but then we'd be back to the
> discussion again and again).
>
> I can hear the passion in Roy's emails but what surprises me is that if it's
> so fundamental and passionate, that it is completely not covered anywhere
> public. And because of that, the current (seemingly not legit process) is so
> widespread throughout the organization, which no offense intended, makes me
> curious if we have the whole story so far.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
--
John Casey
---
Maven Developer (http://maven.apache.org)
---
Blog: http://www.ejlife.net/blogs/buildchimp
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Brian Fox <br...@infinity.nu>.
Niclas Hedhman wrote:
> On Wed, Apr 29, 2009 at 9:44 AM, Brian Fox <br...@infinity.nu> wrote:
>
>
>> How can you audit the PMCs when these policies are not even documented
>> anywhere? Perhaps the membership isn't even aware of these policies to start
>> with and thus there might be wide disagreement? One can't know until it's
>> written down and everyone can see it clearly.
>>
>
> I wrote somewhere "advisory audit", meaning detection in malpractice
> and help to rectify.
>
> Clarifications to documents is of course better, BUT it also feels
> that ASF has grown so fast that many don't get TheApacheWay in this
> area, which saddens me.
>
>
>
>
Clarifications to the documents is the _only_ way to solve this once and
for all...otherwise everything is just an opinion, there's nothing
official. If there is, please point me to it. I think the process as
described so far is pretty overbearing, but that's just my opinion for
now and as such pretty irrelevant. We can't really build a proper
process on unofficial opinions, mine or anyone else's. (well we could,
but then we'd be back to the discussion again and again).
I can hear the passion in Roy's emails but what surprises me is that if
it's so fundamental and passionate, that it is completely not covered
anywhere public. And because of that, the current (seemingly not legit
process) is so widespread throughout the organization, which no offense
intended, makes me curious if we have the whole story so far.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Apr 29, 2009 at 9:44 AM, Brian Fox <br...@infinity.nu> wrote:
> How can you audit the PMCs when these policies are not even documented
> anywhere? Perhaps the membership isn't even aware of these policies to start
> with and thus there might be wide disagreement? One can't know until it's
> written down and everyone can see it clearly.
I wrote somewhere "advisory audit", meaning detection in malpractice
and help to rectify.
Clarifications to documents is of course better, BUT it also feels
that ASF has grown so fast that many don't get TheApacheWay in this
area, which saddens me.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Brian Fox <br...@infinity.nu>.
> Yes, there are doubts.
>
> 1. The signed 'source release' is to be downloaded, unpacked and
> built by each voting PMC member.
>
> 2. The binary built by such PMC member should be compared to the
> proposed binary release, and tested on the available platform of that
> PMC member.
>
> Personally, I don't vote if I don't have time or opportunity for other
> reasons to do this. But looking at the time lapsed from [Vote] to the
> first +1 of a PMC member other than the release manager, one can often
> see zero effort in such procedure (it takes more than 2 minutes).
>
> How can Maven as a tool help?
> I am not sure... But Maven PMC could look into its own release process
> first and ensure that the intent (as Roy tried to explain to high
> level of detail) is followed. That alone should surface what can be
> improved, I am sure. However, I also fear that Maven, as well as many
> other, PMCs don't have the 'gut feeling' on what the release
> requirement really is, and might fail to see that anything wrong is
> going on. Hence my suggestion elsewhere that perhaps an advisory audit
> is in order.
>
How can you audit the PMCs when these policies are not even documented
anywhere? Perhaps the membership isn't even aware of these policies to
start with and thus there might be wide disagreement? One can't know
until it's written down and everyone can see it clearly.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Apr 29, 2009 at 8:26 AM, David Jencks <da...@yahoo.com> wrote:
> 1. release process creates a scm tag, svn exports out the entire project at
> once (including possibly hundreds of maven projects), archives the whole
> thing, unpacks the archive, and performs the existing (e.g. maven) build.
> 2. release process creates an scm tag, checks it out, and builds source jars
> for each maven module that include all the java source, other main
> resources, and a (possibly modified to avoid trying to run tests) pom that
> will build the jar from the included source. These source jars are unpacked
> one by one to build the binary artifacts. No overall archive of the entire
> tag is needed. In particular no test code is included.
>
> Irrespective of how practical or advisable these processes are, is there any
> doubt they follow the policy Roy enunciated?
Yes, there are doubts.
1. The signed 'source release' is to be downloaded, unpacked and
built by each voting PMC member.
2. The binary built by such PMC member should be compared to the
proposed binary release, and tested on the available platform of that
PMC member.
Personally, I don't vote if I don't have time or opportunity for other
reasons to do this. But looking at the time lapsed from [Vote] to the
first +1 of a PMC member other than the release manager, one can often
see zero effort in such procedure (it takes more than 2 minutes).
How can Maven as a tool help?
I am not sure... But Maven PMC could look into its own release process
first and ensure that the intent (as Roy tried to explain to high
level of detail) is followed. That alone should surface what can be
improved, I am sure. However, I also fear that Maven, as well as many
other, PMCs don't have the 'gut feeling' on what the release
requirement really is, and might fail to see that anything wrong is
going on. Hence my suggestion elsewhere that perhaps an advisory audit
is in order.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Guillaume Nodet <gu...@worldonline.fr>.
On Wed, Apr 29, 2009 at 16:32, Emmanuel Lecharny <el...@apache.org> wrote:
>>> True, but we are not talking about a glimpse here. It's much more
>>> about 72 hours, during which all the PMCs will svn co the tag, build
>>> the release, and +1 it. In the mean time, the code base might have
>>> been compromized. Not likely, but possible.
>>
>> We never to that for just that reason. We produce both if something is wrong
>> we throw both away and start over.
>
> You are assuming the RM is the only one who create both packages, and
> every other PMCs just validate the packages. This is not a very common
> use case.
Other PMC members should build the binary packages, either from the
tag, or from the source distribution generated by maven (which are the
same in projects I work on).
> Typically, that leads to serious problems. For instance, last week, we
> tried to release a version of Apache Directory. If the RM was the only
> one to generate the packages, then we would have missed a serious
> build issue on some faster machine. Thus we usually check out the
> code, and validate the build, before validating the package once
> everyone agree that the release is ready.
>
> You will reply that once this first phase (ie, check that the build is
> ok) is done, then the RM can now produce the signed source tarball and
> the signed release, but in this case, I think that you rely on the RM
> only, not the PMCs, because you have no way to check that the source
> tarball is the one used to produce the binaries. I know we trust the
> RM, but I see where it can be seen as a breach in the brocess.
The staging repositories are exactly for that. I always vote on both
binaries + source distribution + svn tag actually.
I don't think voting on an svn revision is any better, actually I
think it's worse because someone can commit something between the
moment the release is voted and the moment the release is packaged.
If something goes wrong and the release has to be recut, we usually
delete the svn tag, delete the staging repo and restart another vote
with a new tag and a new staging repo.
> More commonly, I think that the build should be done based on the
> signed sources, not from SVN.
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Apr 29, 2009 at 3:56 PM, sebb <se...@gmail.com> wrote:
> However, a new package can easily be created and signed, and that does
> happen when problems are found during voting. I've yet to see a vote
> where the instance of the package is declared as part of the vote.
I typically include the SHA1 hash of the source package in all the
release votes I start. See for example
http://markmail.org/message/pzg3w4uacvoq75mb.
When I vote on a release thread that doesn't come with a checksum, I
usually include the checksum of the source package along with my +1
vote.
Doing so binds the release vote to the exact bits being voted on.
We also never reuse a version number after a failed release vote. Like
in httpd, a failed release simply results in a "hole" in the sequence
of version numbers.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Emmanuel Lecharny <el...@apache.org>.
> The SVN tag alone is not enough; the revision is also required.
>
> In fact even the SVN tag+revision does not quite guarantee an
> unchanging set of files in the repository, as it is possible to delete
> files entirely from the repository.
>
> Even ignoring SVN deletions, an SVN tag+revision is still not
> constant, as different OSes represent EOLs in different ways. These
> differences can (and do) have an effect on the build output.
>
> So I think a buildable source archive should remain the primary
> artefact that is voted on.
+1.
> However, the SVN history and contents is also important, so IMO
> another check should be made to ensure that the files in SVN agree
> with the files in the source archive.
That's not necessary. The vote is done on the signed sources (ie, the
tarball), so it is supposed to be validated by the PMCs. No need to
compare the sources with SVN's files. At least, if we don't care to
check that SVN hasn't been compromised since the tarball creation...
There should be nothing in the
> source archive that is not in SVN (apart perhaps from locally
> generated config files),
+1. Otherwise, the tarball hasn't been generated correctly or SVN has
been compromised since the last co.
and there should be nothing in the SVN tag
> that is not in the source archive, apart from a few files such as the
> DOAP or SVN status files.
+1.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Ceki Gulcu <ce...@qos.ch>.
Jochen Wiedmann wrote:
>
> I think it demonstrates that we shouldn't require a particular
> procedure, because the applicability of such procedures depends on a
> multitude of factors. Instead, we should assume *reasonable*
> principles like reproducability. (Discussing whether tags can be moved
> is, IMO, not reasonable, in particular, because it can be traced in
> SVN.)
>
> For example, if we can take the SVN tag as a source, then that's
> sufficiently reproducable for me. I can live (and I'd assume that
> everyone else can) with the requirement to export this tag to an
> archive, both for users convenience and to express the fact that a
> "release" has been performed. (Note, that there are usually more SVN
> tags than releases!)
>
> OTOH, source jar files are definitely insufficient: For example, you
> can't build the thing without a POM file or Ant script, it lacks
> inputs for generating sources, and so on.
>
> If we could agree to that, then we could leave the technical details
> (for example, cut archive first, then create the tag, or vice versa)
> to the proponents of the respective build systems, SCM systems, and so
> on - and that's where it belongs to, IMO.
Sounds like the voice of reason.
> Jochen
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Brian Fox <br...@infinity.nu>.
Jochen Wiedmann wrote:
> On Thu, Apr 30, 2009 at 9:33 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
>
>
>>> But perhaps that's just splitting hairs :)
>>>
>> Not at all.
>>
>
> I think it demonstrates that we shouldn't require a particular
> procedure, because the applicability of such procedures depends on a
> multitude of factors. Instead, we should assume *reasonable*
> principles like reproducability. (Discussing whether tags can be moved
> is, IMO, not reasonable, in particular, because it can be traced in
> SVN.)
>
> For example, if we can take the SVN tag as a source, then that's
> sufficiently reproducable for me. I can live (and I'd assume that
> everyone else can) with the requirement to export this tag to an
> archive, both for users convenience and to express the fact that a
> "release" has been performed. (Note, that there are usually more SVN
> tags than releases!)
>
> OTOH, source jar files are definitely insufficient: For example, you
> can't build the thing without a POM file or Ant script, it lacks
> inputs for generating sources, and so on.
>
> If we could agree to that, then we could leave the technical details
> (for example, cut archive first, then create the tag, or vice versa)
> to the proponents of the respective build systems, SCM systems, and so
> on - and that's where it belongs to, IMO.
>
>
>
>
Well said, +1. The results are the important thing and it's on the
shoulders of the PMC to meet some basic requirements during voting. If
the source archive is totally junk, it should be uncovered at that time.
How it gets produced is very dependent on things that change from
project to project, lets agree on some simple principals and make sure
all releases meet them. I'll take a stab:
1) each release must at a minimum: a) have a tag in the associated scm
system for traceability reasons and b) produce a signed tarball that is
sufficient to build or otherwise produce the product by the users. This
would typically take the form of an archive of the source tree
comprising the release and generally match the contents of the tag.
2) binaries are provided as a convenience to the users. If they are
provided, the version given to them must match exactly to the version of
the source used to produce the binary. (the existing text on the site is
sufficient for this part imo)
3) all artifacts (source and binary) must be cryptographically signed.
Voting occurs on the set of produced, signed artifacts. The validation
that these artifacts meet the above requirements is performed by the PMC
during the voting process.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Thu, Apr 30, 2009 at 9:33 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
>> But perhaps that's just splitting hairs :)
>
> Not at all.
I think it demonstrates that we shouldn't require a particular
procedure, because the applicability of such procedures depends on a
multitude of factors. Instead, we should assume *reasonable*
principles like reproducability. (Discussing whether tags can be moved
is, IMO, not reasonable, in particular, because it can be traced in
SVN.)
For example, if we can take the SVN tag as a source, then that's
sufficiently reproducable for me. I can live (and I'd assume that
everyone else can) with the requirement to export this tag to an
archive, both for users convenience and to express the fact that a
"release" has been performed. (Note, that there are usually more SVN
tags than releases!)
OTOH, source jar files are definitely insufficient: For example, you
can't build the thing without a POM file or Ant script, it lacks
inputs for generating sources, and so on.
If we could agree to that, then we could leave the technical details
(for example, cut archive first, then create the tag, or vice versa)
to the proponents of the respective build systems, SCM systems, and so
on - and that's where it belongs to, IMO.
Jochen
--
Don't trust a government that doesn't trust you.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Brett Porter <br...@apache.org>.
On 01/05/2009, at 5:45 AM, Joe Schaefer wrote:
> The site-cvs list is overseen by infra and has an open subscription
> policy.
>
> In other words, anyone can review changes to /dev/release.html, but
> only
> members, pmc-chairs, people with apsite karma, and the
> infrastructure team
> can make changes to it. Any changes to said policy are supposed to be
> discussed on the infrastructure@ list, unless there is an issue
> regarding
> the legal risks associated with what we've written down.
At the risk of introducing an infinite loop, http://www.apache.org/dev/infra-mail.html#site-dev
says that it is responsible for changes to the site (including that
page), and is also an open list. I'll be requesting that we change the
reply-to of site-cvs to site-dev instead of infra@ to reflect this.
site-dev is under the oversight of infrastructure, but as Joe said
while infra has the responsibility, the ones that get to make changes
is anyone with commit or willing to submit a patch.
The practice I've seen used there for non-trivial changes is review-
then-commit, which while not strictly necessary alleviates concerns
such as robert's that an opinion might later get taken as the one
truth because it should get some review. It is also much easier to
debate exact wording than rolling email threads.
All, I'll be submitting a patch there now with an explanation, which I
hope covers the useful parts of this thread. Please feel free to toss
your +1's, vetoes, or suggested improvements over there.
Incidentally, writing the patch and this email took exactly 50% of the
time it took to originally read this thread in one sitting.
Thanks,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Brian Fox <br...@infinity.nu>
> To: legal-discuss@apache.org
> Sent: Thursday, April 30, 2009 3:10:01 PM
> Subject: Re: Clarification on the release requirements
>
>
>
> Joe Schaefer wrote:
> > It's a either policy question, which in this case happens to be "overseen and
> > enforced" (however laxly) by infra. Or it's a set of best practice
> guidelines,
> > which appear to be under development in the incubator.
> I wasn't aware that Infra and/or Incubator determined ASF policy,
The people who determine a policy at the ASF are usually the people
who have commit rights to the document containing the policy.
> my mistaken assumption was that it was for the nuts and bolts
> of the machinery that supports the projects and for new projects joining.
Infra has needs of its own regarding policy. One of those
needs is the ability to actually make compliance decisions
based on the document in question.
>From the svn authorization file:
[/infrastructure/site]
@infrastructure = rw
@members = rw
@pmc-chairs = rw
@apsite = rw
* = r
>From the svn mailer file:
# Site and site-tools
[/infrastructure/site]
for_paths = infrastructure/(site|site-tools)/
to_addr = site-cvs@apache.org
And here's the headers for site-cvs@. Note the reply-to part:
hermes% less ~/lists/apache.org/site-cvs/headeradd
Precedence: bulk
List-Help: <mailto:<#l#>-help@<#h#>>
List-Unsubscribe: <mailto:<#l#>-unsubscribe@<#h#>>
List-Post: <mailto:<#l#>@<#h#>>
List-Id: <<#l#>.<#h#>>
Reply-To: infrastructure@apache.org
The site-cvs list is overseen by infra and has an open subscription policy.
In other words, anyone can review changes to /dev/release.html, but only
members, pmc-chairs, people with apsite karma, and the infrastructure team
can make changes to it. Any changes to said policy are supposed to be
discussed on the infrastructure@ list, unless there is an issue regarding
the legal risks associated with what we've written down.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Brian Fox <br...@infinity.nu>.
Joe Schaefer wrote:
> It's a either policy question, which in this case happens to be "overseen and
> enforced" (however laxly) by infra. Or it's a set of best practice guidelines,
> which appear to be under development in the incubator.
I wasn't aware that Infra and/or Incubator determined ASF policy, my
mistaken assumption was that it was for the nuts and bolts of the
machinery that supports the projects and for new projects joining.
> Either way, bothering a
> bunch of attorneys who follow this list seems to me to be either an attempt to
> go over infra/incubator's head, or else it's a simple misunderstanding of the
> nature of the issues. Pick one.
>
>
As I stated in the opening email, I was following up on the previous
discussion that started on this list. It seemed at that point that the
release guidelines derived from the need to legally protect the ASF.
>> I guess it's lose lose either way, but I for one would like to lose by getting
>> to some set of guidelines that everyone can agree upon and then go build the tools.
>>
>
> Figure out if you want guidelines or enforceable policy, and pick the group you need
> to work with to get what you want done. Simply sending an email to a mailing list
> does not constitute doing work: offering specific wording or better yet, an actual
> patch, is far more productive.
>
>
>
I did that in my opening email actually, but there were some things not
clear enough for me simply to go off and dream up. Hence my initial
questions that started down this road.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Brian Fox <br...@infinity.nu>
> To: legal-discuss@apache.org
> Sent: Thursday, April 30, 2009 2:18:49 PM
> Subject: Re: Clarification on the release requirements
> It's simple. We're trying to produce a set of tools that encapsulate industry
> best practices for our users.
I thought we had a webpage for determining what best practices are
with respect to releases at the ASF? In fact, I see one linked from
the /dev/release.html page:
http://incubator.apache.org/guides/releasemanagement.html#best-practice
> We also happen to be our own users and have other
> ASF users so it would be nice to completely understand the requirements to build
> the correct tools. Maven specifically is constantly hit with statements like in
> the previous maven release thread that claim Maven doesn't do it right. Well, if
> you look at the current documentation it's not surprising because it's vague. If
> the intent is to make them vague and leave it to the PMC, fine, say so clearly.
> Otherwise lets make sure everyone agrees so we can fix it once and for all.
> Ignoring it doesn't solve anything.
>
> If we don't do anything about the perceived problems, we're called negligent. If
> we start a discussion to try and get to the bottom of it, we're arguing.
It's a either policy question, which in this case happens to be "overseen and
enforced" (however laxly) by infra. Or it's a set of best practice guidelines,
which appear to be under development in the incubator. Either way, bothering a
bunch of attorneys who follow this list seems to me to be either an attempt to
go over infra/incubator's head, or else it's a simple misunderstanding of the
nature of the issues. Pick one.
> I guess it's lose lose either way, but I for one would like to lose by getting
> to some set of guidelines that everyone can agree upon and then go build the tools.
Figure out if you want guidelines or enforceable policy, and pick the group you need
to work with to get what you want done. Simply sending an email to a mailing list
does not constitute doing work: offering specific wording or better yet, an actual
patch, is far more productive.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Brian Fox <br...@infinity.nu>.
Joe Schaefer wrote:
>>>
>>>
>> It may be a ridiculous stretch, but the point I get from it is that each build
>> has slightly different requirements for what should and shouldn't be required to
>> be released. We should leave it up to the PMCs to decide based on some
>> underlying fundamental rules.
>>
>
> I don't think you've said anything new in the above, since Roy seems to be stating
> what those rules actually are.
Roy laid out a process as opposed to a set of guidelines that can be
used by projects to define an adequate process. There's a big difference
imo. If what Roy wrote down is the process and gospel, then fine, it
should be engraved in stone. However, like I said before, since it
apparently hasn't been operating this way foundation wide for some
period of time, perhaps some discussion is required to get to a set of
guidelines everyone can live with. This is so far the start of the
discussion. I imagine once we can agree on some guidelines, they would
need to be written up and seen by a wider audience.
> If there's some discrepancy in the documentation
> of those rules at http://www.apache.org/dev/release.html, than IMO that should be
> raised on the infrastructure@ list, since it is infra who oversees the contents of
> that url.
>
>
That would be the logical conclusion to the problem, but i'm not sure
Infra is the correct location to define the content, merely to get it
applied once decided.
> And nothing. Apache has several Perl projects that work in exactly that way, and
> most of the time we Perl hackers are rather non-plussed about what all the arguing
> is about in the Java community regarding release process.
It's simple. We're trying to produce a set of tools that encapsulate
industry best practices for our users. We also happen to be our own
users and have other ASF users so it would be nice to completely
understand the requirements to build the correct tools. Maven
specifically is constantly hit with statements like in the previous
maven release thread that claim Maven doesn't do it right. Well, if you
look at the current documentation it's not surprising because it's
vague. If the intent is to make them vague and leave it to the PMC,
fine, say so clearly. Otherwise lets make sure everyone agrees so we can
fix it once and for all. Ignoring it doesn't solve anything.
If we don't do anything about the perceived problems, we're called
negligent. If we start a discussion to try and get to the bottom of it,
we're arguing. I guess it's lose lose either way, but I for one would
like to lose by getting to some set of guidelines that everyone can
agree upon and then go build the tools.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Brian Fox <br...@infinity.nu>
> To: legal-discuss@apache.org
> Sent: Thursday, April 30, 2009 1:17:10 PM
> Subject: Re: Clarification on the release requirements
>
>
>
> Joe Schaefer wrote:
> > Yeah, that's a fairly rediculous stretch IMO. Having build *scripts* that are
> > Apache-release-compatible but generated by other non-Apache open-source
> > projects,
> > and dorking with the Apache project's actual source code, are two entirely
> > different things. Yes, I've personally witnessed release duds being created
> > by
> > an RM who used outdated auto-tools, but going the extra mile and having the RM
> > actually
> > check-in all the generated files that are included in the releasable tarball
> > is a
> > fairly pointless exercise IMO. The *tarball* is the signed, authoritative
> > object,
> > not the tag. If the tarball wasn't generated by the RM from a tag using a
> > well-documented and repeatable process, something's wrong with the project's
> > release documentation.
> >
>
> It may be a ridiculous stretch, but the point I get from it is that each build
> has slightly different requirements for what should and shouldn't be required to
> be released. We should leave it up to the PMCs to decide based on some
> underlying fundamental rules.
I don't think you've said anything new in the above, since Roy seems to be stating
what those rules actually are. If there's some discrepancy in the documentation
of those rules at http://www.apache.org/dev/release.html, than IMO that should be
raised on the infrastructure@ list, since it is infra who oversees the contents of
that url.
> Noone disagrees here that a source archive is
> desirable and required. Clearly there is a disagreement about the exact steps
> required to produce this archive, AND if a tag should exist and what it should
> contain. I don't think those will ever be solved by a universal set of rules.
> > FWIW you don't have these issues in scripting languages like Perl, since the
> language provides its own support for building and testing the software. There
> > you can just tar up an svn export and put it to a vote.
> >
> >
> >
> And?
And nothing. Apache has several Perl projects that work in exactly that way, and
most of the time we Perl hackers are rather non-plussed about what all the arguing
is about in the Java community regarding release process. We actually struggle to
even see the need for voting on a tarball other than to meet the org's
requirements, since they don't contain anything extraneous to what's in svn, and
there are no binaries to build, just different packaging for the Windows world.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Brian Fox <br...@infinity.nu>.
Joe Schaefer wrote:
> ----- Original Message ----
>
>
>> From: David Jencks <da...@yahoo.com>
>> To: legal-discuss@apache.org
>> Sent: Thursday, April 30, 2009 12:54:10 PM
>> Subject: Re: Clarification on the release requirements
>>
>>
>> On Apr 30, 2009, at 9:18 AM, John Casey wrote:
>>
>>
>>> On Thu, Apr 30, 2009 at 9:50 AM, sebb wrote:
>>>
>>>> Even ignoring SVN deletions, an SVN tag+revision is still not
>>>> constant, as different OSes represent EOLs in different ways. These
>>>> differences can (and do) have an effect on the build output.
>>>>
>>>>
>>> If this is true, then simply checking out the sources on one machine
>>> and archiving them may mean that the sources will produce different
>>> (flawed?) results when unpacked and built on another machine. So in
>>> the case you mention, the signed source archive is no guarantee that
>>> the build would be reproducible. With a verified tag in SCM, at least
>>> we know that we have the opportunity to research the history on any
>>> particular piece of code, in the event we did uncover a flaw in the
>>> release after the fact. This isn't just theoretical, either; I use
>>> this history, along with the debug information in the binaries we
>>> produce, to trace through Maven all the time in search of bugs.
>>> Without a definite, direct link between SCM and binaries, this would
>>> be a _lot_ less dependable.
>>>
>> I completely agree.
>>
>> To go out on a limb...
>>
>> I wasn't aware until the last couple of days that the C based projects don't
>> produce a copy of what's in svn as their source archive. I've been thinking
>> about this situation and can't see any fundamental difference between a C
>> project including a generated configure script (not from svn) and a java project
>> converting all the java source to jasmin (basically "java assembly language")
>> and releasing that instead of the java files. In both situations the resulting
>> archive includes stuff derived from svn that can be used to build working
>> binaries. While I don't think anyone would call a bunch of jasmin files a
>> "source release" I don't see how something with a generated script can be
>> either.
>>
>
> Yeah, that's a fairly rediculous stretch IMO. Having build *scripts* that are
> Apache-release-compatible but generated by other non-Apache open-source projects,
> and dorking with the Apache project's actual source code, are two entirely
> different things. Yes, I've personally witnessed release duds being created by
> an RM who used outdated auto-tools, but going the extra mile and having the RM actually
> check-in all the generated files that are included in the releasable tarball is a
> fairly pointless exercise IMO. The *tarball* is the signed, authoritative object,
> not the tag. If the tarball wasn't generated by the RM from a tag using a
> well-documented and repeatable process, something's wrong with the project's
> release documentation.
>
It may be a ridiculous stretch, but the point I get from it is that each
build has slightly different requirements for what should and shouldn't
be required to be released. We should leave it up to the PMCs to decide
based on some underlying fundamental rules. Noone disagrees here that a
source archive is desirable and required. Clearly there is a
disagreement about the exact steps required to produce this archive, AND
if a tag should exist and what it should contain. I don't think those
will ever be solved by a universal set of rules.
> FWIW you don't have these issues in scripting languages like Perl, since the
> language provides its own support for building and testing the software. There
> you can just tar up an svn export and put it to a vote.
>
>
>
And?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: David Jencks <da...@yahoo.com>
> To: legal-discuss@apache.org
> Sent: Thursday, April 30, 2009 12:54:10 PM
> Subject: Re: Clarification on the release requirements
>
>
> On Apr 30, 2009, at 9:18 AM, John Casey wrote:
>
> > On Thu, Apr 30, 2009 at 9:50 AM, sebb wrote:
> >>
> >> Even ignoring SVN deletions, an SVN tag+revision is still not
> >> constant, as different OSes represent EOLs in different ways. These
> >> differences can (and do) have an effect on the build output.
> >>
> >
> > If this is true, then simply checking out the sources on one machine
> > and archiving them may mean that the sources will produce different
> > (flawed?) results when unpacked and built on another machine. So in
> > the case you mention, the signed source archive is no guarantee that
> > the build would be reproducible. With a verified tag in SCM, at least
> > we know that we have the opportunity to research the history on any
> > particular piece of code, in the event we did uncover a flaw in the
> > release after the fact. This isn't just theoretical, either; I use
> > this history, along with the debug information in the binaries we
> > produce, to trace through Maven all the time in search of bugs.
> > Without a definite, direct link between SCM and binaries, this would
> > be a _lot_ less dependable.
>
> I completely agree.
>
> To go out on a limb...
>
> I wasn't aware until the last couple of days that the C based projects don't
> produce a copy of what's in svn as their source archive. I've been thinking
> about this situation and can't see any fundamental difference between a C
> project including a generated configure script (not from svn) and a java project
> converting all the java source to jasmin (basically "java assembly language")
> and releasing that instead of the java files. In both situations the resulting
> archive includes stuff derived from svn that can be used to build working
> binaries. While I don't think anyone would call a bunch of jasmin files a
> "source release" I don't see how something with a generated script can be
> either.
Yeah, that's a fairly rediculous stretch IMO. Having build *scripts* that are
Apache-release-compatible but generated by other non-Apache open-source projects,
and dorking with the Apache project's actual source code, are two entirely
different things. Yes, I've personally witnessed release duds being created by
an RM who used outdated auto-tools, but going the extra mile and having the RM actually
check-in all the generated files that are included in the releasable tarball is a
fairly pointless exercise IMO. The *tarball* is the signed, authoritative object,
not the tag. If the tarball wasn't generated by the RM from a tag using a
well-documented and repeatable process, something's wrong with the project's
release documentation.
FWIW you don't have these issues in scripting languages like Perl, since the
language provides its own support for building and testing the software. There
you can just tar up an svn export and put it to a vote.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by David Jencks <da...@yahoo.com>.
On Apr 30, 2009, at 9:18 AM, John Casey wrote:
> On Thu, Apr 30, 2009 at 9:50 AM, sebb <se...@gmail.com> wrote:
>>
>> Even ignoring SVN deletions, an SVN tag+revision is still not
>> constant, as different OSes represent EOLs in different ways. These
>> differences can (and do) have an effect on the build output.
>>
>
> If this is true, then simply checking out the sources on one machine
> and archiving them may mean that the sources will produce different
> (flawed?) results when unpacked and built on another machine. So in
> the case you mention, the signed source archive is no guarantee that
> the build would be reproducible. With a verified tag in SCM, at least
> we know that we have the opportunity to research the history on any
> particular piece of code, in the event we did uncover a flaw in the
> release after the fact. This isn't just theoretical, either; I use
> this history, along with the debug information in the binaries we
> produce, to trace through Maven all the time in search of bugs.
> Without a definite, direct link between SCM and binaries, this would
> be a _lot_ less dependable.
I completely agree.
To go out on a limb...
I wasn't aware until the last couple of days that the C based projects
don't produce a copy of what's in svn as their source archive. I've
been thinking about this situation and can't see any fundamental
difference between a C project including a generated configure script
(not from svn) and a java project converting all the java source to
jasmin (basically "java assembly language") and releasing that instead
of the java files. In both situations the resulting archive includes
stuff derived from svn that can be used to build working binaries.
While I don't think anyone would call a bunch of jasmin files a
"source release" I don't see how something with a generated script can
be either.
IMO such an artifact with non-scm content is just as much a
"convenience binary" as a java binary jar file and voting on it is
logically equivalent to voting on java binaries.
thanks
david jencks
>
>
> Just my $0.02.
>
> -john
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Joe Schaefer <jo...@yahoo.com>
> To: legal-discuss@apache.org
> Sent: Thursday, May 7, 2009 5:20:51 PM
> Subject: Re: Clarification on the release requirements
>
>
> ----- Original Message ----
>
> > From: Doug Cutting
> > To: legal-discuss@apache.org
> > Sent: Thursday, May 7, 2009 3:15:56 PM
> > Subject: Re: Clarification on the release requirements
> >
> > sebb wrote:
> > > It's not the RM that is likely to change SVN during a vote.
> >
> > Sigh.
> >
> > Yes, but it is the release manager who'd have to lose their workspace before
> > they tagged and have to reconstruct it carefully, making sure that they
> > reconstructed the identical state, and if they were not able to confidently do
>
> > so to perhaps create a new candidate build and restart the vote. In practice,
>
> > this has never been an issue, and, in theory, it does not pose a threat, since
>
> > we trust our release managers to be competent to correctly handle this.
>
> FWIW I recently created
>
> https://svn.apache.org/repos/private/committers/tools/release/compare_dirs.pl
s/release/releases/, sorry.
>
> so voters can validate the various packages against an svn location (or each
> other).
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Doug Cutting <cu...@apache.org>
> To: legal-discuss@apache.org
> Sent: Thursday, May 7, 2009 3:15:56 PM
> Subject: Re: Clarification on the release requirements
>
> sebb wrote:
> > It's not the RM that is likely to change SVN during a vote.
>
> Sigh.
>
> Yes, but it is the release manager who'd have to lose their workspace before
> they tagged and have to reconstruct it carefully, making sure that they
> reconstructed the identical state, and if they were not able to confidently do
> so to perhaps create a new candidate build and restart the vote. In practice,
> this has never been an issue, and, in theory, it does not pose a threat, since
> we trust our release managers to be competent to correctly handle this.
FWIW I recently created
https://svn.apache.org/repos/private/committers/tools/release/compare_dirs.pl
so voters can validate the various packages against an svn location (or each other).
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Doug Cutting <cu...@apache.org>.
sebb wrote:
> It's not the RM that is likely to change SVN during a vote.
Sigh.
Yes, but it is the release manager who'd have to lose their workspace
before they tagged and have to reconstruct it carefully, making sure
that they reconstructed the identical state, and if they were not able
to confidently do so to perhaps create a new candidate build and restart
the vote. In practice, this has never been an issue, and, in theory, it
does not pose a threat, since we trust our release managers to be
competent to correctly handle this.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by sebb <se...@gmail.com>.
On 07/05/2009, Doug Cutting <cu...@apache.org> wrote:
> sebb wrote:
>
> > But how do you know whether it has changed if you don't record the
> revision?
> >
>
> The same way we ever know whether things have changed. The release master
> reads the dev mailing list.
It's possible for SVN commit messages to get lost.
> The release master keeps the workspace around
> that was used to create the release. Etc. If there is a concern that the
> branch might change, then the release master can checkpoint the build with a
> tag. In practice, this is not required. In general, we trust the release
> master not to screw this up.
It's not the RM that is likely to change SVN during a vote.
>
> Doug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Doug Cutting <cu...@apache.org>.
sebb wrote:
> But how do you know whether it has changed if you don't record the revision?
The same way we ever know whether things have changed. The release
master reads the dev mailing list. The release master keeps the
workspace around that was used to create the release. Etc. If there is
a concern that the branch might change, then the release master can
checkpoint the build with a tag. In practice, this is not required. In
general, we trust the release master not to screw this up.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by sebb <se...@gmail.com>.
On 07/05/2009, Doug Cutting <cu...@apache.org> wrote:
> sebb wrote:
>
> > So why not create an RC tag in the first place?
> >
>
> Laziness, mostly. If the branch suffices, why bother?
>
>
> > And how do you ensure that the branch is not updated during the voting?
> >
>
> If it does, then a tag could be made post-fact to the version that matches
> that voted on. I don't think this has ever happened, though.
>
But how do you know whether it has changed if you don't record the revision?
> Doug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Doug Cutting <cu...@apache.org>.
sebb wrote:
> So why not create an RC tag in the first place?
Laziness, mostly. If the branch suffices, why bother?
> And how do you ensure that the branch is not updated during the voting?
If it does, then a tag could be made post-fact to the version that
matches that voted on. I don't think this has ever happened, though.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by sebb <se...@gmail.com>.
On 07/05/2009, Doug Cutting <cu...@apache.org> wrote:
> Jason van Zyl wrote:
>
> > Without question the single most popular form of building from source
> > in Java projects is not from source archives. In Maven all our users
> > always try and build from tags.
> >
>
> That's not true of Apache Java projects I've worked on. In these, release
> artifacts are built (source and binary), voted on, and, if the vote passes,
> a tag is created. Releases are built from a branch, and the branch is not
> altered during voting. If someone wanted to alter a branch during voting,
> then a temporary release candidate tag could be used to checkpoint the
> branch.
So why not create an RC tag in the first place?
And how do you ensure that the branch is not updated during the voting?
Projects I've worked on create an RCn tag from which the builds are done.
If a vote fails, an RCn+1 tag is created.
If the vote succeeds, the final RC tag is renamed to the release tag.
Unused tags are deleted later if required.
This way, the tag is always immutable (though it would not harm to
document the revision as well).
> In these Java projects, tags are a convenience, not a necessity.
Strictly speaking, that is always the case, so long as the SVN
revision number is documented.
> Doug
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Fri, May 1, 2009 at 12:49 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> Only very infrequently does someone actually build the source on their own.
How infrequent must it be to be neglected?
I come across 3 use cases of sourceballs;
1. Linux distributors typically build from sources.
2. I often download Java sources to modify for experiments.
3. I often come across custom versions inside development teams. I
have over the last year seen custom Struts, Axis and a couple of
non-Apache stuff.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 30, 2009, at 8:33 PM, Niclas Hedhman wrote:
> On Fri, May 1, 2009 at 1:45 AM, Jason van Zyl <jv...@sonatype.com>
> wrote:
>
>> Without question the single most popular form of building from
>> source in
>> Java projects is not from source archives. In Maven all our users
>> always try
>> and build from tags.
>
> Is that by choice or force?
> For instance, could you please point me to the source tarball of Maven
> Release plugin? Because AFAICT, it is only available as "tag";
> http://maven.apache.org/plugins/maven-release-plugin/source-repository.html
>
> Perhaps you meant something else...
Actually, Jason's post isn't quite accurate. As he said, most java
projects build their own stuff from tags checked out from the source
repository. These days by far the most popular way of using other
people's source is from the binary jars. Most developers appreciate
having the source jars for using with their IDEs for debugging. Only
very infrequently does someone actually build the source on their
own. This was true even before Maven came along. Prior to that you
would find the binary jars checked into the project's source control
in a lib directory.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Fri, May 1, 2009 at 1:45 AM, Jason van Zyl <jv...@sonatype.com> wrote:
> Without question the single most popular form of building from source in
> Java projects is not from source archives. In Maven all our users always try
> and build from tags.
Is that by choice or force?
For instance, could you please point me to the source tarball of Maven
Release plugin? Because AFAICT, it is only available as "tag";
http://maven.apache.org/plugins/maven-release-plugin/source-repository.html
Perhaps you meant something else...
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Doug Cutting <cu...@apache.org>.
David Jencks wrote:
> 1. I may be putting words in his mouth but I think Jason was trying to
> say that building from svn checkouts/exports is more usual that building
> from unpacked source archives for those who want to build a binary of a
> released artifact for themselves.
I have no idea which is more common. Prior to release, folks do check
that the unpacked source archives can build and pass some tests. Lots
of folks (most?) use the released binary artifacts as-is.
Many folks create patched builds. I don't know whether they start from
the release source archives versus a subversion tag or branch, probably
some of each. If they want all the safeguards of the Apache release
process then they ought to build from the release source archives.
> I think that to follow the release.xml procedures you'd have to include
> the rev number from which the release artifacts are built in the vote
> and not create the tag after the vote.
In Hadoop anyway, the SVN revision is built into the release artifact
that is voted on. In any case, we vote on the source code, not a tag.
We trust that the release master is competent to create a tag that
corresponds to the source code voted on, as a convenience.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by David Jencks <da...@yahoo.com>.
On May 7, 2009, at 10:03 AM, Doug Cutting wrote:
> Jason van Zyl wrote:
>> Without question the single most popular form of building from source
>> in Java projects is not from source archives. In Maven all our users
>> always try and build from tags.
>
> That's not true of Apache Java projects I've worked on. In these,
> release artifacts are built (source and binary), voted on, and, if
> the vote passes, a tag is created. Releases are built from a
> branch, and the branch is not altered during voting. If someone
> wanted to alter a branch during voting, then a temporary release
> candidate tag could be used to checkpoint the branch.
>
> In these Java projects, tags are a convenience, not a necessity.
1. I may be putting words in his mouth but I think Jason was trying to
say that building from svn checkouts/exports is more usual that
building from unpacked source archives for those who want to build a
binary of a released artifact for themselves. AFAICT the behavior of
the projects you mention support this generalization.
2. The process you describe appears to me to be contrary to the
current draft of the release.xml guidelines being constructed on site-
dev:
+<p>The foundation of every ASF release is a known, identified, and
+immutable scm location, such as svn path and revision. Every artifact
+in a release must be derived from this scm location by a documented and
+repeatable process, such as a build script.
+</p>
+
I think that to follow the release.xml procedures you'd have to
include the rev number from which the release artifacts are built in
the vote and not create the tag after the vote.
thanks
david jencks
>
>
> Doug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Doug Cutting <cu...@apache.org>.
Jason van Zyl wrote:
> Without question the single most popular form of building from source
> in Java projects is not from source archives. In Maven all our users
> always try and build from tags.
That's not true of Apache Java projects I've worked on. In these,
release artifacts are built (source and binary), voted on, and, if the
vote passes, a tag is created. Releases are built from a branch, and
the branch is not altered during voting. If someone wanted to alter a
branch during voting, then a temporary release candidate tag could be
used to checkpoint the branch.
In these Java projects, tags are a convenience, not a necessity.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Jason van Zyl <jv...@sonatype.com>.
On 30-Apr-09, at 10:07 AM, sebb wrote:
> I think the point is that we want our customers/users to be able to
> download the source and that they should have confidence that the
> source archive has the correct contents. This means that the vote must
> be on the signed source archive.
>
Without question the single most popular form of building from source
in Java projects is not from source archives. In Maven all our users
always try and build from tags.
> Users are for the most part not interested in SCM, and should
> certainly not be forced to install a particular SCM merely to use the
> source archive.
>
Sorry, but that's just not the case with our users so I think we have
a fundamentally different kinds of users between our projects types.
So, I echo what people have said in that we need a base set of
requirements and the nature of projects and what our users want may
mean different processes in different projects. If legal requirements
are met, and users in the communities are happy with the way they have
to reproduce a build then everyone can do what's optimal.
> On 30/04/2009, John Casey <ca...@gmail.com> wrote:
>> On Thu, Apr 30, 2009 at 9:50 AM, sebb <se...@gmail.com> wrote:
>>>
>>> Even ignoring SVN deletions, an SVN tag+revision is still not
>>> constant, as different OSes represent EOLs in different ways. These
>>> differences can (and do) have an effect on the build output.
>>>
>>
>>
>> If this is true, then simply checking out the sources on one machine
>> and archiving them may mean that the sources will produce different
>> (flawed?) results when unpacked and built on another machine. So in
>> the case you mention, the signed source archive is no guarantee that
>> the build would be reproducible. With a verified tag in SCM, at least
>> we know that we have the opportunity to research the history on any
>> particular piece of code, in the event we did uncover a flaw in the
>> release after the fact. This isn't just theoretical, either; I use
>> this history, along with the debug information in the binaries we
>> produce, to trace through Maven all the time in search of bugs.
>> Without a definite, direct link between SCM and binaries, this would
>> be a _lot_ less dependable.
>>
>> Just my $0.02.
>>
>>
>> -john
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by sebb <se...@gmail.com>.
I think the point is that we want our customers/users to be able to
download the source and that they should have confidence that the
source archive has the correct contents. This means that the vote must
be on the signed source archive.
Users are for the most part not interested in SCM, and should
certainly not be forced to install a particular SCM merely to use the
source archive.
On 30/04/2009, John Casey <ca...@gmail.com> wrote:
> On Thu, Apr 30, 2009 at 9:50 AM, sebb <se...@gmail.com> wrote:
> >
> > Even ignoring SVN deletions, an SVN tag+revision is still not
> > constant, as different OSes represent EOLs in different ways. These
> > differences can (and do) have an effect on the build output.
> >
>
>
> If this is true, then simply checking out the sources on one machine
> and archiving them may mean that the sources will produce different
> (flawed?) results when unpacked and built on another machine. So in
> the case you mention, the signed source archive is no guarantee that
> the build would be reproducible. With a verified tag in SCM, at least
> we know that we have the opportunity to research the history on any
> particular piece of code, in the event we did uncover a flaw in the
> release after the fact. This isn't just theoretical, either; I use
> this history, along with the debug information in the binaries we
> produce, to trace through Maven all the time in search of bugs.
> Without a definite, direct link between SCM and binaries, this would
> be a _lot_ less dependable.
>
> Just my $0.02.
>
>
> -john
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by John Casey <ca...@gmail.com>.
On Thu, Apr 30, 2009 at 9:50 AM, sebb <se...@gmail.com> wrote:
>
> Even ignoring SVN deletions, an SVN tag+revision is still not
> constant, as different OSes represent EOLs in different ways. These
> differences can (and do) have an effect on the build output.
>
If this is true, then simply checking out the sources on one machine
and archiving them may mean that the sources will produce different
(flawed?) results when unpacked and built on another machine. So in
the case you mention, the signed source archive is no guarantee that
the build would be reproducible. With a verified tag in SCM, at least
we know that we have the opportunity to research the history on any
particular piece of code, in the event we did uncover a flaw in the
release after the fact. This isn't just theoretical, either; I use
this history, along with the debug information in the binaries we
produce, to trace through Maven all the time in search of bugs.
Without a definite, direct link between SCM and binaries, this would
be a _lot_ less dependable.
Just my $0.02.
-john
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Jason van Zyl <jv...@sonatype.com>.
On 30-Apr-09, at 6:50 AM, sebb wrote:
> On 30/04/2009, Brian Fox <br...@infinity.nu> wrote:
>
> The SVN tag alone is not enough; the revision is also required.
>
> In fact even the SVN tag+revision does not quite guarantee an
> unchanging set of files in the repository, as it is possible to delete
> files entirely from the repository.
>
Only GIT would be reliable as it guarantees consistent using the
rolling hierarchical checksum SHA1. So GIT would actually make for a
safer canonical repository. I still argue this should be a choice for
individual PMCs where a certain % of PMCs agreed on one tool but
that's another discussion.
> Even ignoring SVN deletions, an SVN tag+revision is still not
> constant, as different OSes represent EOLs in different ways. These
> differences can (and do) have an effect on the build output.
>
> So I think a buildable source archive should remain the primary
> artefact that is voted on.
>
> However, the SVN history and contents is also important, so IMO
> another check should be made to ensure that the files in SVN agree
> with the files in the source archive. There should be nothing in the
> source archive that is not in SVN (apart perhaps from locally
> generated config files), and there should be nothing in the SVN tag
> that is not in the source archive, apart from a few files such as the
> DOAP or SVN status files.
>
>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
To do two things at once is to do neither.
-—Publilius Syrus, Roman slave, first century B.C.
Re: Clarification on the release requirements
Posted by sebb <se...@gmail.com>.
On 30/04/2009, Brian Fox <br...@infinity.nu> wrote:
>
>
> William A. Rowe, Jr. wrote:
>
> > Niclas Hedhman wrote:
> >
> >
> > > On Thu, Apr 30, 2009 at 11:23 AM, Joe Schaefer <jo...@yahoo.com>
> wrote:
> > >
> > >
> > >
> > > > That's not the way tarballs get generated for C projects. Typically
> > > > at least the bundled configure script is generated from the
> > > > RM's installed auto-tools. That's one of the main reasons we only
> > > > vote on signed tarballs, because the tarball depends on the RM's host.
> > > >
> > > >
> > > Are you sure? I am not very experience with the autotools, but when I
> > > occasionally download sources to compile for Linux, I end up running
> > > "./configure && make && make install". Does ASF project provide
> > > pre-configured distros?
> > >
> > >
> >
> > configure isn't written by a project, it's a generated artifact of running
> > automake/autoconf, and it's resulting script is a side effect of the exact
> > versions of the autotools chain. But perhaps that's just splitting hairs
> :)
> >
> >
> >
> >
> I think we're starting to uncover a difference in how the native code
> builds work and the java builds. You're talking about generating a build
> script at release time and that isn't tagged anywhere so it must exist in a
> signed sourceball. It seems like the actual makefiles should be checked in
> to the tag for future reference and traceability. In other builds that don't
> generate build scripts on the fly and thus subject to the individual's
> machine, the tag is still a valid reference to the complete sources.
>
The SVN tag alone is not enough; the revision is also required.
In fact even the SVN tag+revision does not quite guarantee an
unchanging set of files in the repository, as it is possible to delete
files entirely from the repository.
Even ignoring SVN deletions, an SVN tag+revision is still not
constant, as different OSes represent EOLs in different ways. These
differences can (and do) have an effect on the build output.
So I think a buildable source archive should remain the primary
artefact that is voted on.
However, the SVN history and contents is also important, so IMO
another check should be made to ensure that the files in SVN agree
with the files in the source archive. There should be nothing in the
source archive that is not in SVN (apart perhaps from locally
generated config files), and there should be nothing in the SVN tag
that is not in the source archive, apart from a few files such as the
DOAP or SVN status files.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thu, Apr 30, 2009 at 3:20 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> Niclas Hedhman wrote:
>> On Thu, Apr 30, 2009 at 11:23 AM, Joe Schaefer <jo...@yahoo.com> wrote:
>>
>>> That's not the way tarballs get generated for C projects. Typically
>>> at least the bundled configure script is generated from the
>>> RM's installed auto-tools. That's one of the main reasons we only
>>> vote on signed tarballs, because the tarball depends on the RM's host.
>>
>> Are you sure? I am not very experience with the autotools, but when I
>> occasionally download sources to compile for Linux, I end up running
>> "./configure && make && make install". Does ASF project provide
>> pre-configured distros?
>
> configure isn't written by a project, it's a generated artifact of running
> automake/autoconf, and it's resulting script is a side effect of the exact
> versions of the autotools chain.
Ok. And the "configure" script is part of the source delivery? What
about the "sources" (if any) needed to generate the "configure"
script?
And to re-generate the same "configure" from SVN (let's say 10 years
later), you would need to dig up the same version of the tools and the
rest of the environment that the RM used? I guess it would be same for
Maven/Ant projects to use same version (or at least very similar) of
those tools to build something much later. In fact, it feels like
"system requirements" are a problem in itself :-) no matter what they
are...
> But perhaps that's just splitting hairs :)
Not at all.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Brian Fox <br...@infinity.nu>.
William A. Rowe, Jr. wrote:
> Niclas Hedhman wrote:
>
>> On Thu, Apr 30, 2009 at 11:23 AM, Joe Schaefer <jo...@yahoo.com> wrote:
>>
>>
>>> That's not the way tarballs get generated for C projects. Typically
>>> at least the bundled configure script is generated from the
>>> RM's installed auto-tools. That's one of the main reasons we only
>>> vote on signed tarballs, because the tarball depends on the RM's host.
>>>
>> Are you sure? I am not very experience with the autotools, but when I
>> occasionally download sources to compile for Linux, I end up running
>> "./configure && make && make install". Does ASF project provide
>> pre-configured distros?
>>
>
> configure isn't written by a project, it's a generated artifact of running
> automake/autoconf, and it's resulting script is a side effect of the exact
> versions of the autotools chain. But perhaps that's just splitting hairs :)
>
>
>
I think we're starting to uncover a difference in how the native code
builds work and the java builds. You're talking about generating a build
script at release time and that isn't tagged anywhere so it must exist
in a signed sourceball. It seems like the actual makefiles should be
checked in to the tag for future reference and traceability. In other
builds that don't generate build scripts on the fly and thus subject to
the individual's machine, the tag is still a valid reference to the
complete sources.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Niclas Hedhman wrote:
> On Thu, Apr 30, 2009 at 11:23 AM, Joe Schaefer <jo...@yahoo.com> wrote:
>
>> That's not the way tarballs get generated for C projects. Typically
>> at least the bundled configure script is generated from the
>> RM's installed auto-tools. That's one of the main reasons we only
>> vote on signed tarballs, because the tarball depends on the RM's host.
>
> Are you sure? I am not very experience with the autotools, but when I
> occasionally download sources to compile for Linux, I end up running
> "./configure && make && make install". Does ASF project provide
> pre-configured distros?
configure isn't written by a project, it's a generated artifact of running
automake/autoconf, and it's resulting script is a side effect of the exact
versions of the autotools chain. But perhaps that's just splitting hairs :)
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thu, Apr 30, 2009 at 11:23 AM, Joe Schaefer <jo...@yahoo.com> wrote:
> That's not the way tarballs get generated for C projects. Typically
> at least the bundled configure script is generated from the
> RM's installed auto-tools. That's one of the main reasons we only
> vote on signed tarballs, because the tarball depends on the RM's host.
Are you sure? I am not very experience with the autotools, but when I
occasionally download sources to compile for Linux, I end up running
"./configure && make && make install". Does ASF project provide
pre-configured distros?
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Niclas Hedhman <ni...@hedhman.org>
> To: legal-discuss@apache.org
> Sent: Wednesday, April 29, 2009 11:18:54 PM
> Subject: Re: Clarification on the release requirements
>
> On Thu, Apr 30, 2009 at 11:03 AM, Ralph Goers
> wrote:
>
> > If I can't trace a source archive back to svn and get the same stuff out of
> > SVN then the release is invalid.
>
> Yes, I agree, although I know that this hasn't always been the case,
> historically.
>
> IMHO, the ideal source release is nothing more than tag+tarball what
> is in the project SVN root (-svn dirs). If Maven want to support that
> (tag+export+checksum+sign) it would be great, if NOT it is not a big
> deal either to do manually.
That's not the way tarballs get generated for C projects. Typically
at least the bundled configure script is generated from the
RM's installed auto-tools. That's one of the main reasons we only
vote on signed tarballs, because the tarball depends on the RM's host.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Brian Fox <br...@infinity.nu>.
>> If I can't trace a source archive back to svn and get the same stuff out of
>> SVN then the release is invalid. This is true for my employer and probably
>> at all the places Brian was talking about. I can't imagine why it would be
>> any less true for Apache.
>>
>
> Actually, it may be less true or not true at all for the ASF. I don't
> know why it's invalid for your employer, but for my employer, it's not
> acceptable because the development process requires traceability for
> regulatory reasons. Though traceability is helpful for maintenance
> purposes, I'm not aware of any such requirement on the ASF.
>
>
>
Traceability is not important to prove code provenance? You mean I can
take a tag, modify it locally any way I feel like, tarball it up, sign
it and that's a valid ASF backed release after voting? Even though
there's potentially no way to verify where the code came from? The SCM
system is the only location that can trace the history of the code,
that's why it's the defacto source of reference for every build I've
ever come across. It seems to me that the sourceballs like binaries are
provided for convenience.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Nathan Beyer <nd...@apache.org>.
On Wed, Apr 29, 2009 at 10:03 PM, Ralph Goers
<ra...@dslextreme.com> wrote:
>
> On Apr 29, 2009, at 7:08 PM, Nathan Beyer wrote:
>
>> On Wed, Apr 29, 2009 at 8:04 PM, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>>
>>> On Apr 29, 2009, at 5:06 PM, Nathan Beyer wrote:
>>>
>>>>>>
>>>>>
>>>>> If you want to consider your SCM unreliable then sure.
>>>>
>>>> It's a distributed/networked system, you have to assume it will be
>>>> unreliable.
>>>>>
>>>
>>> Huh?
>>> So if I do a checkout of trunk and someone does a commit while I am doing
>>> that I am going to get a screwed up checkout? I don't think so.
>>
>> Huh?
>> I'm talking about the network - the network's not reliable. Jason
>> referred to a set of network transactions that must happen in "rapid
>> succession". Though it is unlikely for failures or errors to happen in
>> between, it's still possible and must be mitigated.
>
> No. Jason wasn't referring to network transactions that must happen in rapid
> succession. He was saying the source archive and binary archive are built in
> rapid succession. Both are built from the source you have already obtained
> over the network.
>
>>
>>
>>>
>>> If I checkout a tag and someone screws with the tag while I am checking
>>> out
>>> (highly unlikely) no matter what system you use this will be screwed up.
>>> If
>>> I don't get the change then what I "released", even if I tar it up first
>>> and
>>> build from the tar, doesn't match the tag - which is unacceptable. While
>>> the source tar has to be buildable SVN has to be the system of record. If
>>> it
>>> can't be trusted to be then we should just call it a day.
>>
>> I think within your statement here is a hint at the core issue - SVN
>> is not the system or record, source of truth or whatever you want to
>> call it for everyone when it comes to ASF source releases.
>
> If I can't trace a source archive back to svn and get the same stuff out of
> SVN then the release is invalid. This is true for my employer and probably
> at all the places Brian was talking about. I can't imagine why it would be
> any less true for Apache.
Actually, it may be less true or not true at all for the ASF. I don't
know why it's invalid for your employer, but for my employer, it's not
acceptable because the development process requires traceability for
regulatory reasons. Though traceability is helpful for maintenance
purposes, I'm not aware of any such requirement on the ASF.
> Saying you have a voted on release that you can never pull again from
> SVN is unthinkable to me.
It would certainly be no fun, but I'd guess this is why the signed
source archive is important - you can recreate what was lost.
>
>>
>>
>> As I understand it, SVN or any SCM system is the non-normative form of
>> the source release - the normative form is the archived source, which
>> is cryptographically signed and has been voted upon.
>>
>> It seems like this is pretty fundamental concept that would need to be
>> determined to more formally define the policy.
>
> I have no problem with the "shipped artifacts" being signed and voted upon.
> I simply have a problem if they aren't tied to anything specific in the
> source control system.
Okay. I don't disagree, but why is it important and why is it
important to the ASF? Is it really essential to couple SCM resources
to ASF source releases?
-Nathan
>
> Ralph
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thu, Apr 30, 2009 at 11:03 AM, Ralph Goers
<ra...@dslextreme.com> wrote:
> If I can't trace a source archive back to svn and get the same stuff out of
> SVN then the release is invalid.
Yes, I agree, although I know that this hasn't always been the case,
historically.
IMHO, the ideal source release is nothing more than tag+tarball what
is in the project SVN root (-svn dirs). If Maven want to support that
(tag+export+checksum+sign) it would be great, if NOT it is not a big
deal either to do manually.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 29, 2009, at 7:08 PM, Nathan Beyer wrote:
> On Wed, Apr 29, 2009 at 8:04 PM, Ralph Goers <ralph.goers@dslextreme.com
> > wrote:
>>
>> On Apr 29, 2009, at 5:06 PM, Nathan Beyer wrote:
>>
>>>>>
>>>>
>>>> If you want to consider your SCM unreliable then sure.
>>>
>>> It's a distributed/networked system, you have to assume it will be
>>> unreliable.
>>>>
>>
>> Huh?
>> So if I do a checkout of trunk and someone does a commit while I am
>> doing
>> that I am going to get a screwed up checkout? I don't think so.
>
> Huh?
> I'm talking about the network - the network's not reliable. Jason
> referred to a set of network transactions that must happen in "rapid
> succession". Though it is unlikely for failures or errors to happen in
> between, it's still possible and must be mitigated.
No. Jason wasn't referring to network transactions that must happen in
rapid succession. He was saying the source archive and binary archive
are built in rapid succession. Both are built from the source you have
already obtained over the network.
>
>
>>
>> If I checkout a tag and someone screws with the tag while I am
>> checking out
>> (highly unlikely) no matter what system you use this will be
>> screwed up. If
>> I don't get the change then what I "released", even if I tar it up
>> first and
>> build from the tar, doesn't match the tag - which is unacceptable.
>> While
>> the source tar has to be buildable SVN has to be the system of
>> record. If it
>> can't be trusted to be then we should just call it a day.
>
> I think within your statement here is a hint at the core issue - SVN
> is not the system or record, source of truth or whatever you want to
> call it for everyone when it comes to ASF source releases.
If I can't trace a source archive back to svn and get the same stuff
out of SVN then the release is invalid. This is true for my employer
and probably at all the places Brian was talking about. I can't
imagine why it would be any less true for Apache. Saying you have a
voted on release that you can never pull again from SVN is unthinkable
to me.
>
>
> As I understand it, SVN or any SCM system is the non-normative form of
> the source release - the normative form is the archived source, which
> is cryptographically signed and has been voted upon.
>
> It seems like this is pretty fundamental concept that would need to be
> determined to more formally define the policy.
I have no problem with the "shipped artifacts" being signed and voted
upon. I simply have a problem if they aren't tied to anything specific
in the source control system.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Nathan Beyer <nd...@apache.org>.
On Wed, Apr 29, 2009 at 8:04 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> On Apr 29, 2009, at 5:06 PM, Nathan Beyer wrote:
>
>>>>
>>>
>>> If you want to consider your SCM unreliable then sure.
>>
>> It's a distributed/networked system, you have to assume it will be
>> unreliable.
>>>
>
> Huh?
> So if I do a checkout of trunk and someone does a commit while I am doing
> that I am going to get a screwed up checkout? I don't think so.
Huh?
I'm talking about the network - the network's not reliable. Jason
referred to a set of network transactions that must happen in "rapid
succession". Though it is unlikely for failures or errors to happen in
between, it's still possible and must be mitigated.
>
> If I checkout a tag and someone screws with the tag while I am checking out
> (highly unlikely) no matter what system you use this will be screwed up. If
> I don't get the change then what I "released", even if I tar it up first and
> build from the tar, doesn't match the tag - which is unacceptable. While
> the source tar has to be buildable SVN has to be the system of record. If it
> can't be trusted to be then we should just call it a day.
I think within your statement here is a hint at the core issue - SVN
is not the system or record, source of truth or whatever you want to
call it for everyone when it comes to ASF source releases.
As I understand it, SVN or any SCM system is the non-normative form of
the source release - the normative form is the archived source, which
is cryptographically signed and has been voted upon.
It seems like this is pretty fundamental concept that would need to be
determined to more formally define the policy.
-Nathan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 29, 2009, at 5:06 PM, Nathan Beyer wrote:
>>>
>>
>> If you want to consider your SCM unreliable then sure.
>
> It's a distributed/networked system, you have to assume it will be
> unreliable.
>>
Huh?
So if I do a checkout of trunk and someone does a commit while I am
doing that I am going to get a screwed up checkout? I don't think so.
If I checkout a tag and someone screws with the tag while I am
checking out (highly unlikely) no matter what system you use this will
be screwed up. If I don't get the change then what I "released", even
if I tar it up first and build from the tar, doesn't match the tag -
which is unacceptable. While the source tar has to be buildable SVN
has to be the system of record. If it can't be trusted to be then we
should just call it a day.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Nathan Beyer <nb...@gmail.com>.
On Wed, Apr 29, 2009 at 6:57 PM, Jason van Zyl <jv...@sonatype.com> wrote:
>
> On 29-Apr-09, at 4:34 PM, Nathan Beyer wrote:
>
>> On Wed, Apr 29, 2009 at 9:03 AM, Jason van Zyl <jv...@sonatype.com>
>> wrote:
>>>
>>> On 29-Apr-09, at 6:42 AM, Emmanuel Lecharny wrote:
>>>
>>>>>> Anything that (essentially) matches the contents of svn and can be
>>>>>> built to produce the other release artifacts is IMHO fine as a source
>>>>>> release.
>>>>>>
>>>>>
>>>>> I agree and this is generally standard practice by SCM teams. It's
>>>>> predicated on immutable tagging and the SCM being reliable. I can see
>>>>> why
>>>>> Roy wants it done from the source archive here because we've never
>>>>> setup
>>>>> CVS
>>>>> or SVN to follow SCM best practices and it's not uncommon for SVN to be
>>>>> out
>>>>> for unacceptable periods of time. So I can see where Roy's methodology
>>>>> came
>>>>> from. I've seen lots of diddled tags (though this is pretty much
>>>>> impossible
>>>>> with mvn -B release:prepare release:perform) and SVN has been
>>>>> unavailable
>>>>> more often then I would like to admit to the outside world.
>>>>
>>>> It's not only a problem of SVN not being available : there is no way
>>>> you can guarantee that SVN hasn't been compromized if you base your
>>>> build on a tag.
>>>
>>> I don't think this argument carries any weight because where did you get
>>> your source archive from? A tag most likely. So if you wake up in the
>>> morning and pull a tag to create a source archive and then release, or
>>> alternatively do "mvn -B release:prepare release:perform" there's no
>>> difference. The freak chance a second after you prepare the SCM goes down
>>> is
>>> slim. If we wait a length of time between each step then yes it could
>>> happen.
>>>
>>>> OTOS, a source package can be signed, thus can't be
>>>> compromized without being detected.
>>>>
>>>
>>> That's not related to making the source archive and it's integrity if you
>>> do
>>> both operations in rapid succession.
>>
>> I believe this is flawed though - 'rapid succession' is not a
>> guarantee of atomicity.
>
> I never said anything about it being atomic.
I know, but I brought it up because we're talking about distributed
systems and guaranteed consistency. We need to guarantee consistency.
Rapid succession won't guarantee it and we don't have atomicity to
rely on.
>
> A planned release with myself as the release manager has never had someone
> else try to alter a tag while I was releasing it. It's not likely.
>
> It's about as likely as you pulling from your tag to create your source
> archive, and then someone changing your tag which has corrections that
> should be released but you missed it and didn't include it. It's not likely.
>
> What matters is the validation of what was pulled indeed works. Which is why
> the release plugin after pulling the tags does the build again to make sure
> all the tests pass before you attempt to make the actual release. This
> catches almost all mistakes but theoretically someone could make a behavior
> change that still passed tests not good enough which leaks something bad
> given a lengthly enough span between the two phases.
>
> The only way to absolutely guarantee what's tagged and what's used is with a
> system like GIT that employ hierarchical checksums. If I tag and take the
> checksum and store it. I can come back a month later and if the checksum at
> the top of the structure is the same the contents are guaranteed to be
> identical. So we could guarantee content identity, run the build like we
> always do with the release plugin and then you're certain. We actually take
> the algorithm out of JGIT and add it to the release plugin to check the
> checked out structure ... that would actually work well.
That's not the only way to guarantee it, the use of source archives
that are signed archives also works. This is possibly a way to
guarantee it using SCM systems.
>
>> When you can't rely on atomicity, then you
>> need verification in between, which is where the signed artifact comes
>
> If you want to consider your SCM unreliable then sure.
It's a distributed/networked system, you have to assume it will be unreliable.
>
>> in.
>>
>> -Nathan
>>
>>>
>>>>
>>>> --
>>>> Regards,
>>>> Cordialement,
>>>> Emmanuel Lécharny
>>>> www.iktek.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>>
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> http://twitter.com/SonatypeNexus
>>> http://twitter.com/SonatypeM2E
>>> ----------------------------------------------------------
>>>
>>> A party which is not afraid of letting culture,
>>> business, and welfare go to ruin completely can
>>> be omnipotent for a while.
>>>
>>> -- Jakob Burckhardt
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/SonatypeNexus
> http://twitter.com/SonatypeM2E
> ----------------------------------------------------------
>
> happiness is like a butterfly: the more you chase it, the more it will
> elude you, but if you turn your attention to other things, it will come
> and sit softly on your shoulder ...
>
> -- Thoreau
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Emmanuel Lecharny <el...@apache.org>.
>> True, but we are not talking about a glimpse here. It's much more
>> about 72 hours, during which all the PMCs will svn co the tag, build
>> the release, and +1 it. In the mean time, the code base might have
>> been compromized. Not likely, but possible.
>
> We never to that for just that reason. We produce both if something is wrong
> we throw both away and start over.
You are assuming the RM is the only one who create both packages, and
every other PMCs just validate the packages. This is not a very common
use case.
Typically, that leads to serious problems. For instance, last week, we
tried to release a version of Apache Directory. If the RM was the only
one to generate the packages, then we would have missed a serious
build issue on some faster machine. Thus we usually check out the
code, and validate the build, before validating the package once
everyone agree that the release is ready.
You will reply that once this first phase (ie, check that the build is
ok) is done, then the RM can now produce the signed source tarball and
the signed release, but in this case, I think that you rely on the RM
only, not the PMCs, because you have no way to check that the source
tarball is the one used to produce the binaries. I know we trust the
RM, but I see where it can be seen as a breach in the brocess.
More commonly, I think that the build should be done based on the
signed sources, not from SVN.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by David Jencks <da...@yahoo.com>.
On Apr 29, 2009, at 4:34 PM, Nathan Beyer wrote:
> On Wed, Apr 29, 2009 at 9:03 AM, Jason van Zyl
> <jv...@sonatype.com> wrote:
>>
>> On 29-Apr-09, at 6:42 AM, Emmanuel Lecharny wrote:
>>
>>>>> Anything that (essentially) matches the contents of svn and can be
>>>>> built to produce the other release artifacts is IMHO fine as a
>>>>> source
>>>>> release.
>>>>>
>>>>
>>>> I agree and this is generally standard practice by SCM teams. It's
>>>> predicated on immutable tagging and the SCM being reliable. I can
>>>> see why
>>>> Roy wants it done from the source archive here because we've
>>>> never setup
>>>> CVS
>>>> or SVN to follow SCM best practices and it's not uncommon for SVN
>>>> to be
>>>> out
>>>> for unacceptable periods of time. So I can see where Roy's
>>>> methodology
>>>> came
>>>> from. I've seen lots of diddled tags (though this is pretty much
>>>> impossible
>>>> with mvn -B release:prepare release:perform) and SVN has been
>>>> unavailable
>>>> more often then I would like to admit to the outside world.
>>>
>>> It's not only a problem of SVN not being available : there is no way
>>> you can guarantee that SVN hasn't been compromized if you base your
>>> build on a tag.
>>
>> I don't think this argument carries any weight because where did
>> you get
>> your source archive from? A tag most likely. So if you wake up in the
>> morning and pull a tag to create a source archive and then
>> release, or
>> alternatively do "mvn -B release:prepare release:perform" there's no
>> difference. The freak chance a second after you prepare the SCM
>> goes down is
>> slim. If we wait a length of time between each step then yes it could
>> happen.
>>
>>> OTOS, a source package can be signed, thus can't be
>>> compromized without being detected.
>>>
>>
>> That's not related to making the source archive and it's integrity
>> if you do
>> both operations in rapid succession.
>
> I believe this is flawed though - 'rapid succession' is not a
> guarantee of atomicity. When you can't rely on atomicity, then you
> need verification in between, which is where the signed artifact comes
> in.
>
Everyone's saying "source artifact" but I don't get it. I think we
want a known set of "source" with known provenance. The only source
of known provenance I'm aware of is svn. IIUC with svn the contents
of a path into the repo + a revision number is immutable. Seems to me
like if we're serious about knowing what we're releasing and where it
came from we have to use the svn location as the base of the vote.
I'd hope that artifacts such as some kind of source distro and
optionally binary artifacts that are produced by a documented process
from the svn location would be included in the vote but leaving out
the only thing that has traceability seems nuts to me.
I see Jason VanZyl says git provides a similar or perhaps better
capabiity using checksums. So git would also provide something known
to base a vote on.
To beat a dead horse over its head using a mixed metaphor, there's no
way to know what's in a "source archive" some RM comes up with unless
you know where it came from and how it got into the "source archive".
david jencks
> -Nathan
>
>>
>>>
>>> --
>>> Regards,
>>> Cordialement,
>>> Emmanuel Lécharny
>>> www.iktek.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/SonatypeNexus
>> http://twitter.com/SonatypeM2E
>> ----------------------------------------------------------
>>
>> A party which is not afraid of letting culture,
>> business, and welfare go to ruin completely can
>> be omnipotent for a while.
>>
>> -- Jakob Burckhardt
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thu, Apr 30, 2009 at 7:57 AM, Jason van Zyl <jv...@sonatype.com> wrote:
> It's about as likely as you pulling from your tag to create your source
> archive, and then someone changing your tag which has corrections that
> should be released but you missed it and didn't include it. It's not likely.
I am sure it is possible to use the SCM as an authoritative source,
but before contemplating that, please check with Infrastructure of
what they would say if "users" are to download from tags to build our
systems. Additionally, for users, do they want to do a SVN checkout to
build our sources. I don't think so.
So, end of the day, you are back to tarballs on /dist. Perhaps the
argument is that the tarball offering contains the info of
path+revision for that build, and I think that is a generally good
idea, but AFAIK not common practice at the moment. So, not sure what
the discussion is about at the moment.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Jason van Zyl <jv...@sonatype.com>.
On 29-Apr-09, at 4:34 PM, Nathan Beyer wrote:
> On Wed, Apr 29, 2009 at 9:03 AM, Jason van Zyl
> <jv...@sonatype.com> wrote:
>>
>> On 29-Apr-09, at 6:42 AM, Emmanuel Lecharny wrote:
>>
>>>>> Anything that (essentially) matches the contents of svn and can be
>>>>> built to produce the other release artifacts is IMHO fine as a
>>>>> source
>>>>> release.
>>>>>
>>>>
>>>> I agree and this is generally standard practice by SCM teams. It's
>>>> predicated on immutable tagging and the SCM being reliable. I can
>>>> see why
>>>> Roy wants it done from the source archive here because we've
>>>> never setup
>>>> CVS
>>>> or SVN to follow SCM best practices and it's not uncommon for SVN
>>>> to be
>>>> out
>>>> for unacceptable periods of time. So I can see where Roy's
>>>> methodology
>>>> came
>>>> from. I've seen lots of diddled tags (though this is pretty much
>>>> impossible
>>>> with mvn -B release:prepare release:perform) and SVN has been
>>>> unavailable
>>>> more often then I would like to admit to the outside world.
>>>
>>> It's not only a problem of SVN not being available : there is no way
>>> you can guarantee that SVN hasn't been compromized if you base your
>>> build on a tag.
>>
>> I don't think this argument carries any weight because where did
>> you get
>> your source archive from? A tag most likely. So if you wake up in the
>> morning and pull a tag to create a source archive and then
>> release, or
>> alternatively do "mvn -B release:prepare release:perform" there's no
>> difference. The freak chance a second after you prepare the SCM
>> goes down is
>> slim. If we wait a length of time between each step then yes it could
>> happen.
>>
>>> OTOS, a source package can be signed, thus can't be
>>> compromized without being detected.
>>>
>>
>> That's not related to making the source archive and it's integrity
>> if you do
>> both operations in rapid succession.
>
> I believe this is flawed though - 'rapid succession' is not a
> guarantee of atomicity.
I never said anything about it being atomic.
A planned release with myself as the release manager has never had
someone else try to alter a tag while I was releasing it. It's not
likely.
It's about as likely as you pulling from your tag to create your
source archive, and then someone changing your tag which has
corrections that should be released but you missed it and didn't
include it. It's not likely.
What matters is the validation of what was pulled indeed works. Which
is why the release plugin after pulling the tags does the build again
to make sure all the tests pass before you attempt to make the actual
release. This catches almost all mistakes but theoretically someone
could make a behavior change that still passed tests not good enough
which leaks something bad given a lengthly enough span between the two
phases.
The only way to absolutely guarantee what's tagged and what's used is
with a system like GIT that employ hierarchical checksums. If I tag
and take the checksum and store it. I can come back a month later and
if the checksum at the top of the structure is the same the contents
are guaranteed to be identical. So we could guarantee content
identity, run the build like we always do with the release plugin and
then you're certain. We actually take the algorithm out of JGIT and
add it to the release plugin to check the checked out structure ...
that would actually work well.
> When you can't rely on atomicity, then you
> need verification in between, which is where the signed artifact comes
If you want to consider your SCM unreliable then sure.
> in.
>
> -Nathan
>
>>
>>>
>>> --
>>> Regards,
>>> Cordialement,
>>> Emmanuel Lécharny
>>> www.iktek.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/SonatypeNexus
>> http://twitter.com/SonatypeM2E
>> ----------------------------------------------------------
>>
>> A party which is not afraid of letting culture,
>> business, and welfare go to ruin completely can
>> be omnipotent for a while.
>>
>> -- Jakob Burckhardt
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Nathan Beyer <nd...@apache.org>.
On Wed, Apr 29, 2009 at 9:03 AM, Jason van Zyl <jv...@sonatype.com> wrote:
>
> On 29-Apr-09, at 6:42 AM, Emmanuel Lecharny wrote:
>
>>>> Anything that (essentially) matches the contents of svn and can be
>>>> built to produce the other release artifacts is IMHO fine as a source
>>>> release.
>>>>
>>>
>>> I agree and this is generally standard practice by SCM teams. It's
>>> predicated on immutable tagging and the SCM being reliable. I can see why
>>> Roy wants it done from the source archive here because we've never setup
>>> CVS
>>> or SVN to follow SCM best practices and it's not uncommon for SVN to be
>>> out
>>> for unacceptable periods of time. So I can see where Roy's methodology
>>> came
>>> from. I've seen lots of diddled tags (though this is pretty much
>>> impossible
>>> with mvn -B release:prepare release:perform) and SVN has been unavailable
>>> more often then I would like to admit to the outside world.
>>
>> It's not only a problem of SVN not being available : there is no way
>> you can guarantee that SVN hasn't been compromized if you base your
>> build on a tag.
>
> I don't think this argument carries any weight because where did you get
> your source archive from? A tag most likely. So if you wake up in the
> morning and pull a tag to create a source archive and then release, or
> alternatively do "mvn -B release:prepare release:perform" there's no
> difference. The freak chance a second after you prepare the SCM goes down is
> slim. If we wait a length of time between each step then yes it could
> happen.
>
>> OTOS, a source package can be signed, thus can't be
>> compromized without being detected.
>>
>
> That's not related to making the source archive and it's integrity if you do
> both operations in rapid succession.
I believe this is flawed though - 'rapid succession' is not a
guarantee of atomicity. When you can't rely on atomicity, then you
need verification in between, which is where the signed artifact comes
in.
-Nathan
>
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/SonatypeNexus
> http://twitter.com/SonatypeM2E
> ----------------------------------------------------------
>
> A party which is not afraid of letting culture,
> business, and welfare go to ruin completely can
> be omnipotent for a while.
>
> -- Jakob Burckhardt
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 29, 2009, at 7:13 AM, sebb wrote:
> On 29/04/2009, Jason van Zyl <jv...@sonatype.com> wrote:
>>>
>>>
>>
>> I don't think this argument carries any weight because where did
>> you get
>> your source archive from? A tag most likely. So if you wake up in the
>> morning and pull a tag to create a source archive and then
>> release, or
>> alternatively do "mvn -B release:prepare release:perform" there's no
>> difference. The freak chance a second after you prepare the SCM
>> goes down is
>> slim. If we wait a length of time between each step then yes it could
>> happen.
>
> However tags are not immutable.
>>
I would argue that the tags are more important than the source
archive. While the source archive guarantees the "customer" has the
source that matches the binary build, it contains no history
information. If a tag does not match the released source there is a
serious problem in that project. I'm not trying to imply that the
project should be built from the source archive or svn - just that
using the argument that svn might be hacked, corrupted or changed is
an extremely serious problem and should be addressed as you are
basically saying you can't trust your source control system.
Ralph
Re: Clarification on the release requirements
Posted by sebb <se...@gmail.com>.
On 29/04/2009, Jason van Zyl <jv...@sonatype.com> wrote:
>
> On 29-Apr-09, at 6:42 AM, Emmanuel Lecharny wrote:
>
>
> >
> > >
> > > > Anything that (essentially) matches the contents of svn and can be
> > > > built to produce the other release artifacts is IMHO fine as a source
> > > > release.
> > > >
> > > >
> > >
> > > I agree and this is generally standard practice by SCM teams. It's
> > > predicated on immutable tagging and the SCM being reliable. I can see
> why
> > > Roy wants it done from the source archive here because we've never setup
> CVS
> > > or SVN to follow SCM best practices and it's not uncommon for SVN to be
> out
> > > for unacceptable periods of time. So I can see where Roy's methodology
> came
> > > from. I've seen lots of diddled tags (though this is pretty much
> impossible
> > > with mvn -B release:prepare release:perform) and SVN has been
> unavailable
> > > more often then I would like to admit to the outside world.
> > >
> >
> > It's not only a problem of SVN not being available : there is no way
> > you can guarantee that SVN hasn't been compromized if you base your
> > build on a tag.
> >
>
> I don't think this argument carries any weight because where did you get
> your source archive from? A tag most likely. So if you wake up in the
> morning and pull a tag to create a source archive and then release, or
> alternatively do "mvn -B release:prepare release:perform" there's no
> difference. The freak chance a second after you prepare the SCM goes down is
> slim. If we wait a length of time between each step then yes it could
> happen.
However tags are not immutable.
>
> > OTOS, a source package can be signed, thus can't be
> > compromized without being detected.
> >
> >
>
> That's not related to making the source archive and it's integrity if you
> do both operations in rapid succession.
>
>
> >
> > --
> > Regards,
> > Cordialement,
> > Emmanuel Lécharny
> > www.iktek.com
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/SonatypeNexus
> http://twitter.com/SonatypeM2E
> ----------------------------------------------------------
>
> A party which is not afraid of letting culture,
> business, and welfare go to ruin completely can
> be omnipotent for a while.
>
> -- Jakob Burckhardt
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Jason van Zyl <jv...@sonatype.com>.
On 29-Apr-09, at 7:16 AM, Emmanuel Lecharny wrote:
>>> It's not only a problem of SVN not being available : there is no way
>>> you can guarantee that SVN hasn't been compromized if you base your
>>> build on a tag.
>>
>> I don't think this argument carries any weight because where did
>> you get
>> your source archive from? A tag most likely. So if you wake up in the
>> morning and pull a tag to create a source archive and then
>> release, or
>> alternatively do "mvn -B release:prepare release:perform" there's no
>> difference. The freak chance a second after you prepare the SCM
>> goes down is
>> slim. If we wait a length of time between each step then yes it could
>> happen.
>
> True, but we are not talking about a glimpse here. It's much more
> about 72 hours, during which all the PMCs will svn co the tag, build
> the release, and +1 it. In the mean time, the code base might have
> been compromized. Not likely, but possible.
We never to that for just that reason. We produce both if something is
wrong we throw both away and start over.
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Emmanuel Lecharny <el...@apache.org>.
>> It's not only a problem of SVN not being available : there is no way
>> you can guarantee that SVN hasn't been compromized if you base your
>> build on a tag.
>
> I don't think this argument carries any weight because where did you get
> your source archive from? A tag most likely. So if you wake up in the
> morning and pull a tag to create a source archive and then release, or
> alternatively do "mvn -B release:prepare release:perform" there's no
> difference. The freak chance a second after you prepare the SCM goes down is
> slim. If we wait a length of time between each step then yes it could
> happen.
True, but we are not talking about a glimpse here. It's much more
about 72 hours, during which all the PMCs will svn co the tag, build
the release, and +1 it. In the mean time, the code base might have
been compromized. Not likely, but possible.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Jason van Zyl <jv...@sonatype.com>.
On 29-Apr-09, at 6:42 AM, Emmanuel Lecharny wrote:
>>> Anything that (essentially) matches the contents of svn and can be
>>> built to produce the other release artifacts is IMHO fine as a
>>> source
>>> release.
>>>
>>
>> I agree and this is generally standard practice by SCM teams. It's
>> predicated on immutable tagging and the SCM being reliable. I can
>> see why
>> Roy wants it done from the source archive here because we've never
>> setup CVS
>> or SVN to follow SCM best practices and it's not uncommon for SVN
>> to be out
>> for unacceptable periods of time. So I can see where Roy's
>> methodology came
>> from. I've seen lots of diddled tags (though this is pretty much
>> impossible
>> with mvn -B release:prepare release:perform) and SVN has been
>> unavailable
>> more often then I would like to admit to the outside world.
>
> It's not only a problem of SVN not being available : there is no way
> you can guarantee that SVN hasn't been compromized if you base your
> build on a tag.
I don't think this argument carries any weight because where did you
get your source archive from? A tag most likely. So if you wake up in
the morning and pull a tag to create a source archive and then
release, or alternatively do "mvn -B release:prepare release:perform"
there's no difference. The freak chance a second after you prepare the
SCM goes down is slim. If we wait a length of time between each step
then yes it could happen.
> OTOS, a source package can be signed, thus can't be
> compromized without being detected.
>
That's not related to making the source archive and it's integrity if
you do both operations in rapid succession.
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.
-- Jakob Burckhardt
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Mark Thomas <ma...@apache.org>.
Brian Fox wrote:
>
>
> Emmanuel Lecharny wrote:
>>>> Anything that (essentially) matches the contents of svn and can be
>>>> built to produce the other release artifacts is IMHO fine as a source
>>>> release.
>>>>
>>>>
>>> I agree and this is generally standard practice by SCM teams. It's
>>> predicated on immutable tagging and the SCM being reliable. I can see
>>> why
>>> Roy wants it done from the source archive here because we've never
>>> setup CVS
>>> or SVN to follow SCM best practices and it's not uncommon for SVN to
>>> be out
>>> for unacceptable periods of time. So I can see where Roy's
>>> methodology came
>>> from. I've seen lots of diddled tags (though this is pretty much
>>> impossible
>>> with mvn -B release:prepare release:perform) and SVN has been
>>> unavailable
>>> more often then I would like to admit to the outside world.
>>>
>>
>> It's not only a problem of SVN not being available : there is no way
>> you can guarantee that SVN hasn't been compromized if you base your
>> build on a tag. OTOS, a source package can be signed, thus can't be
>> compromized without being detected.
>>
>>
>>
> But if you produce and sign the source in the same action as producing
> the binaries, you are still signing the source that produced the binary.
If you produce src and binaries from svn you have no guarantee that the src is
sufficient to produce the binary.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Brian Fox <br...@infinity.nu>.
Emmanuel Lecharny wrote:
>>> Anything that (essentially) matches the contents of svn and can be
>>> built to produce the other release artifacts is IMHO fine as a source
>>> release.
>>>
>>>
>> I agree and this is generally standard practice by SCM teams. It's
>> predicated on immutable tagging and the SCM being reliable. I can see why
>> Roy wants it done from the source archive here because we've never setup CVS
>> or SVN to follow SCM best practices and it's not uncommon for SVN to be out
>> for unacceptable periods of time. So I can see where Roy's methodology came
>> from. I've seen lots of diddled tags (though this is pretty much impossible
>> with mvn -B release:prepare release:perform) and SVN has been unavailable
>> more often then I would like to admit to the outside world.
>>
>
> It's not only a problem of SVN not being available : there is no way
> you can guarantee that SVN hasn't been compromized if you base your
> build on a tag. OTOS, a source package can be signed, thus can't be
> compromized without being detected.
>
>
>
But if you produce and sign the source in the same action as producing
the binaries, you are still signing the source that produced the binary.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by sebb <se...@gmail.com>.
On 29/04/2009, Emmanuel Lecharny <el...@apache.org> wrote:
> >> Anything that (essentially) matches the contents of svn and can be
> >> built to produce the other release artifacts is IMHO fine as a source
> >> release.
> >>
> >
> > I agree and this is generally standard practice by SCM teams. It's
> > predicated on immutable tagging and the SCM being reliable. I can see why
> > Roy wants it done from the source archive here because we've never setup CVS
> > or SVN to follow SCM best practices and it's not uncommon for SVN to be out
> > for unacceptable periods of time. So I can see where Roy's methodology came
> > from. I've seen lots of diddled tags (though this is pretty much impossible
> > with mvn -B release:prepare release:perform) and SVN has been unavailable
> > more often then I would like to admit to the outside world.
>
>
> It's not only a problem of SVN not being available : there is no way
> you can guarantee that SVN hasn't been compromized if you base your
> build on a tag. OTOS, a source package can be signed, thus can't be
> compromized without being detected.
I agree signed packages are safer.
However, a new package can easily be created and signed, and that does
happen when problems are found during voting. I've yet to see a vote
where the instance of the package is declared as part of the vote.
Where archives get recreated it's not always clear which version is
being voted on.
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Emmanuel Lecharny <el...@apache.org>.
>> Anything that (essentially) matches the contents of svn and can be
>> built to produce the other release artifacts is IMHO fine as a source
>> release.
>>
>
> I agree and this is generally standard practice by SCM teams. It's
> predicated on immutable tagging and the SCM being reliable. I can see why
> Roy wants it done from the source archive here because we've never setup CVS
> or SVN to follow SCM best practices and it's not uncommon for SVN to be out
> for unacceptable periods of time. So I can see where Roy's methodology came
> from. I've seen lots of diddled tags (though this is pretty much impossible
> with mvn -B release:prepare release:perform) and SVN has been unavailable
> more often then I would like to admit to the outside world.
It's not only a problem of SVN not being available : there is no way
you can guarantee that SVN hasn't been compromized if you base your
build on a tag. OTOS, a source package can be signed, thus can't be
compromized without being detected.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Apr 29, 2009 at 3:30 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Not sure whether same applies to Maven plugin releases.
Oooohhh... you are not opening a new can of worms, are you? ;-)
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Jason van Zyl <jv...@sonatype.com>.
On 29-Apr-09, at 12:30 AM, Jukka Zitting wrote:
> Hi,
>
> On Wed, Apr 29, 2009 at 8:43 AM, Jason van Zyl
> <jv...@sonatype.com> wrote:
>> So you do exactly what Maven does. Roy's argument is those
>> convenience JARs
>> are not self-buildable and are not created properly because the Maven
>> tooling doesn't create the binary from the archive first.
>
> In Jackrabbit we actually start with the source package and mvn deploy
> (via a staged repository, manual for now, repository.a.o soon) from
> there (i.e. we don't use the release plugin). But the end result is
> pretty much equivalent to having a source assembly.
>
> Anything that (essentially) matches the contents of svn and can be
> built to produce the other release artifacts is IMHO fine as a source
> release.
>
I agree and this is generally standard practice by SCM teams. It's
predicated on immutable tagging and the SCM being reliable. I can see
why Roy wants it done from the source archive here because we've never
setup CVS or SVN to follow SCM best practices and it's not uncommon
for SVN to be out for unacceptable periods of time. So I can see where
Roy's methodology came from. I've seen lots of diddled tags (though
this is pretty much impossible with mvn -B release:prepare
release:perform) and SVN has been unavailable more often then I would
like to admit to the outside world.
>> You do what every Maven project does that uses the Maven release
>> plugin in
>> conjunction with a source assembly for the official release.
>
> Having a source assembly for the release is IMHO perfectly fine.
>
I agree, and it's also probably not too hard to change things in a
standard way on the Maven side to roll the source assembly and build
the binary distributable from that given our best effort setup here.
> I think the controversy started with the Shindig release that didn't
> have such a package, only the -sources jars targeted for IDEs. Not
> sure whether same applies to Maven plugin releases.
>
Yup.
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
Selfish deeds are the shortest path to self destruction.
-- The Seven Samuari, Akira Kurosawa
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Apr 29, 2009 at 8:43 AM, Jason van Zyl <jv...@sonatype.com> wrote:
> So you do exactly what Maven does. Roy's argument is those convenience JARs
> are not self-buildable and are not created properly because the Maven
> tooling doesn't create the binary from the archive first.
In Jackrabbit we actually start with the source package and mvn deploy
(via a staged repository, manual for now, repository.a.o soon) from
there (i.e. we don't use the release plugin). But the end result is
pretty much equivalent to having a source assembly.
Anything that (essentially) matches the contents of svn and can be
built to produce the other release artifacts is IMHO fine as a source
release.
> You do what every Maven project does that uses the Maven release plugin in
> conjunction with a source assembly for the official release.
Having a source assembly for the release is IMHO perfectly fine.
I think the controversy started with the Shindig release that didn't
have such a package, only the -sources jars targeted for IDEs. Not
sure whether same applies to Maven plugin releases.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Jason van Zyl <jv...@sonatype.com>.
On 28-Apr-09, at 11:30 PM, Jukka Zitting wrote:
> Hi,
>
> On Wed, Apr 29, 2009 at 8:21 AM, Jason van Zyl
> <jv...@sonatype.com> wrote:
>> On 28-Apr-09, at 11:17 PM, Jukka Zitting wrote:
>>> All the Java projects where I've voted for releases do that. That
>>> includes Jackrabbit, Lucene, James, Commons, POI and a wide range of
>>> incubating projects. The recent Shindig vote was actually the first
>>> time at Apache that I saw a release vote *without* a proper source
>>> package.
>>
>> Jackrabbit doesn't.
>
> Sure we do, see http://www.apache.org/dist/jackrabbit/source/ and the
> release vote in http://markmail.org/message/pzg3w4uacvoq75mb.
>
>> They do what Maven does and those individual source JARs
>> are not compliant with Roy's views.
>>
>> http://repo2.maven.org/maven2/org/apache/jackrabbit/jackrabbit-jcr-server/1.5.2/
>
> We post these as a convenience to users. The official release packages
> are in www.apache.org/dist.
>
Right :-)
So you do exactly what Maven does. Roy's argument is those convenience
JARs are not self-buildable and are not created properly because the
Maven tooling doesn't create the binary from the archive first.
You do what every Maven project does that uses the Maven release
plugin in conjunction with a source assembly for the official release.
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
We know what we are, but know not what we may be.
-- Shakespeare
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Apr 29, 2009 at 8:21 AM, Jason van Zyl <jv...@sonatype.com> wrote:
> On 28-Apr-09, at 11:17 PM, Jukka Zitting wrote:
>> All the Java projects where I've voted for releases do that. That
>> includes Jackrabbit, Lucene, James, Commons, POI and a wide range of
>> incubating projects. The recent Shindig vote was actually the first
>> time at Apache that I saw a release vote *without* a proper source
>> package.
>
> Jackrabbit doesn't.
Sure we do, see http://www.apache.org/dist/jackrabbit/source/ and the
release vote in http://markmail.org/message/pzg3w4uacvoq75mb.
> They do what Maven does and those individual source JARs
> are not compliant with Roy's views.
>
> http://repo2.maven.org/maven2/org/apache/jackrabbit/jackrabbit-jcr-server/1.5.2/
We post these as a convenience to users. The official release packages
are in www.apache.org/dist.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Jason van Zyl <jv...@sonatype.com>.
On 28-Apr-09, at 11:17 PM, Jukka Zitting wrote:
> Hi,
>
> On Wed, Apr 29, 2009 at 2:26 AM, David Jencks
> <da...@yahoo.com> wrote:
>> Could be. I am not aware of any projects anywhere, at apache or
>> elsewhere,
>> that follow this to release anything. (I only know about java
>> projects).
>> Without exception every project I know about builds the "source"
>> release
>> artifact at the same time as the binary artifacts. Are there any
>> java
>> projects here at apache that follow the procedure Roy describes?
>
> All the Java projects where I've voted for releases do that. That
> includes Jackrabbit, Lucene, James, Commons, POI and a wide range of
> incubating projects. The recent Shindig vote was actually the first
> time at Apache that I saw a release vote *without* a proper source
> package.
>
Jackrabbit doesn't. They do what Maven does and those individual
source JARs are not compliant with Roy's views.
http://repo2.maven.org/maven2/org/apache/jackrabbit/jackrabbit-jcr-server/1.5.2/
You probably make source assemblies like we do I'm imagining.
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more
examples
you look at, the more general your framework will be.
-- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Apr 29, 2009 at 2:26 AM, David Jencks <da...@yahoo.com> wrote:
> Could be. I am not aware of any projects anywhere, at apache or elsewhere,
> that follow this to release anything. (I only know about java projects).
> Without exception every project I know about builds the "source" release
> artifact at the same time as the binary artifacts. Are there any java
> projects here at apache that follow the procedure Roy describes?
All the Java projects where I've voted for releases do that. That
includes Jackrabbit, Lucene, James, Commons, POI and a wide range of
incubating projects. The recent Shindig vote was actually the first
time at Apache that I saw a release vote *without* a proper source
package.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by David Jencks <da...@yahoo.com>.
On Apr 28, 2009, at 4:43 PM, Roy T. Fielding wrote:
> On Apr 28, 2009, at 4:21 PM, Brian Fox wrote:
>> Roy T. Fielding wrote:
>>> On Apr 28, 2009, at 1:45 PM, Brian Fox wrote:
>>>> I'm attempting to get answer to existing legal question marks.
>>>> Like David Jenks said:
>>>> "
>>>> In my opinion this is unnecessary and the source jars produced by
>>>> maven for instance by the release profile in the proposed apache
>>>> pom v 6 are adequate. I'd like this principle to be clearly
>>>> established and stated or clearly refuted."
>>>>
>>>> Can we start there?
>>>
>>> <snip>
>>> If you can do that with Maven, great. If you can't, then you can't
>>> call a Maven build a release -- it is just another form of binary
>>> packaging that cannot be distributed until after the release is
>>> cut and approved in source form. Binary packages MUST be built from
>>> the SIGNED and RELEASED source package, NOT FROM SUBVERSION TAGS.
>>>
>> This level of detail is definately not on the site that I've been
>> able to find.
>
> It has been described many times, documented many times, and
> periodically watered down by folks who don't know what they
> are doing.
Could be. I am not aware of any projects anywhere, at apache or
elsewhere, that follow this to release anything. (I only know about
java projects). Without exception every project I know about builds
the "source" release artifact at the same time as the binary
artifacts. Are there any java projects here at apache that follow the
procedure Roy describes?
>
>
>> The current example release process validates certain conditions
>> and then makes a tag. That tag is then checked out and in the same
>> motion, the binaries are produced and the source tar'd up and
>> everything signed. All of these things, the source archives and
>> binaries are then validated and voted upon.
>>
>> The end result is the same, the source archives contain the same
>> code that produced the binaries, which is in agreement with the
>> documented policy on the site:
>>
>> "In all such cases, the binary/bytecode package must have the same
>> version number as the source release and may only add binary/
>> bytecode files that are the result of compiling that version of the
>> source code release."
>>
>> It seems like semantics that source must be tared, signed, untared
>> and then rebuilt if it's all being done in the same action. Do we
>> agree or disagree?
>
> No, it is not semantics. You assume that everything was tar'd
> correctly
> and completely, which is not a valid assumption. Also, voting on
> binary
> artifacts is inherently stupid because their quality cannot be
> verified.
> That's why we specifically tell people not to vote on binaries,
> because
> it just weakens the meaning of voting.
Well, I could argue that you can't tell the quality of source code
without compiling it and seeing if it works by testing. Quality can
mean many things.
Anyway... lets assume the process you describe is both apache policy
and desirable. Clearly all the ant scripts and maven release
profiles I've seen don't follow the policy. Let's try to think of
some maven proecesses that would. I'm going to assume that any
release process for java software needs to produce both source and
binary artifacts that can be voted on at once, since I'm pretty sure
not voting on binary artifacts would be rejected as impractical by
most or all java projects.
1. release process creates a scm tag, svn exports out the entire
project at once (including possibly hundreds of maven projects),
archives the whole thing, unpacks the archive, and performs the
existing (e.g. maven) build.
2. release process creates an scm tag, checks it out, and builds
source jars for each maven module that include all the java source,
other main resources, and a (possibly modified to avoid trying to run
tests) pom that will build the jar from the included source. These
source jars are unpacked one by one to build the binary artifacts. No
overall archive of the entire tag is needed. In particular no test
code is included.
Irrespective of how practical or advisable these processes are, is
there any doubt they follow the policy Roy enunciated?
thanks
david jencks
>
>
> ....Roy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Apr 28, 2009, at 4:21 PM, Brian Fox wrote:
> Roy T. Fielding wrote:
>> On Apr 28, 2009, at 1:45 PM, Brian Fox wrote:
>>> I'm attempting to get answer to existing legal question marks.
>>> Like David Jenks said:
>>> "
>>> In my opinion this is unnecessary and the source jars produced by
>>> maven for instance by the release profile in the proposed apache
>>> pom v 6 are adequate. I'd like this principle to be clearly
>>> established and stated or clearly refuted."
>>>
>>> Can we start there?
>>
>> <snip>
>> If you can do that with Maven, great. If you can't, then you can't
>> call a Maven build a release -- it is just another form of binary
>> packaging that cannot be distributed until after the release is
>> cut and approved in source form. Binary packages MUST be built from
>> the SIGNED and RELEASED source package, NOT FROM SUBVERSION TAGS.
>>
> This level of detail is definately not on the site that I've been
> able to find.
It has been described many times, documented many times, and
periodically watered down by folks who don't know what they
are doing.
> The current example release process validates certain conditions
> and then makes a tag. That tag is then checked out and in the same
> motion, the binaries are produced and the source tar'd up and
> everything signed. All of these things, the source archives and
> binaries are then validated and voted upon.
>
> The end result is the same, the source archives contain the same
> code that produced the binaries, which is in agreement with the
> documented policy on the site:
>
> "In all such cases, the binary/bytecode package must have the same
> version number as the source release and may only add binary/
> bytecode files that are the result of compiling that version of the
> source code release."
>
> It seems like semantics that source must be tared, signed, untared
> and then rebuilt if it's all being done in the same action. Do we
> agree or disagree?
No, it is not semantics. You assume that everything was tar'd correctly
and completely, which is not a valid assumption. Also, voting on binary
artifacts is inherently stupid because their quality cannot be verified.
That's why we specifically tell people not to vote on binaries, because
it just weakens the meaning of voting.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Brian Fox <br...@infinity.nu>.
Roy T. Fielding wrote:
> On Apr 28, 2009, at 1:45 PM, Brian Fox wrote:
>> I'm attempting to get answer to existing legal question marks. Like
>> David Jenks said:
>> "
>> In my opinion this is unnecessary and the source jars produced by
>> maven for instance by the release profile in the proposed apache pom
>> v 6 are adequate. I'd like this principle to be clearly established
>> and stated or clearly refuted."
>>
>> Can we start there?
>
> <snip>
> If you can do that with Maven, great. If you can't, then you can't
> call a Maven build a release -- it is just another form of binary
> packaging that cannot be distributed until after the release is
> cut and approved in source form. Binary packages MUST be built from
> the SIGNED and RELEASED source package, NOT FROM SUBVERSION TAGS.
>
This level of detail is definately not on the site that I've been able
to find. The current example release process validates certain
conditions and then makes a tag. That tag is then checked out and in the
same motion, the binaries are produced and the source tar'd up and
everything signed. All of these things, the source archives and binaries
are then validated and voted upon.
The end result is the same, the source archives contain the same code
that produced the binaries, which is in agreement with the documented
policy on the site:
"In all such cases, the binary/bytecode package must have the same
version number as the source release and may only add binary/bytecode
files that are the result of compiling that version of the source code
release."
It seems like semantics that source must be tared, signed, untared and
then rebuilt if it's all being done in the same action. Do we agree or
disagree?
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Apr 28, 2009, at 1:45 PM, Brian Fox wrote:
> I'm attempting to get answer to existing legal question marks. Like
> David Jenks said:
> "
> In my opinion this is unnecessary and the source jars produced by
> maven for instance by the release profile in the proposed apache
> pom v 6 are adequate. I'd like this principle to be clearly
> established and stated or clearly refuted."
>
> Can we start there?
It isn't a legal question; as in, it doesn't refer to laws or
regulations
that compel the ASF to do one thing over another.
It is a policy we have as a Foundation. Our purpose is to develop and
maintain open source software for the public's benefit. In order to
differentiate our open development (which involves public distribution
of source code in the form of subversion, snapshots, test builds, and
other non-released packages) from our approved releases to the public
(which involves public distribution of source code in the form of
packages that have been signed by a release manager), we require that
the release include all of the source code for the product (every
component of that product in a format that can be edited for later
maintenance of that product as open source) in a packaging format
that has been cryptographically signed by a member of the PMC and
formally approved by vote of that PMC with a minimum of three +1
votes indicating that at least three people, each of whom the board has
previously designated as members of the project management committee
responsible for the product, have independently downloaded and
tested the signed release package and verified that it contains
all of the source code necessary to make changes to the ASF product,
build it into executable form (if different from source), and
execute it on that PMC member's platform to the extent that the
voter believes it is worth distributing to the public as a release.
If you can do that with Maven, great. If you can't, then you can't
call a Maven build a release -- it is just another form of binary
packaging that cannot be distributed until after the release is
cut and approved in source form. Binary packages MUST be built from
the SIGNED and RELEASED source package, NOT FROM SUBVERSION TAGS.
The scope of what is in the "product", versus what is expected by
the team to be either present on the user's platform or downloaded
separately by that user, is entirely defined by the project in
creating their own documentation and website detailing the product
that the ASF is supposedly releasing.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Brian Fox <br...@infinity.nu>.
Jochen Wiedmann wrote:
> Hi, Brian,
>
> On Tue, Apr 28, 2009 at 5:12 PM, Brian Fox <br...@infinity.nu> wrote:
>
>
>> Specifically if a tool was available to convert maven sources jars into a
>> buildable source tree, is that acceptable?
>>
>
> regardless of the legal aspects, I think this goes in the wrong
> direction, for practical reasons.
>
> Most projects, which are using Maven as the build system, would want
> to create "classical" distributions anyways. (The exception being
> basically Maven plugins.) In other words, enhancing Maven's abilities
> to build and deploy such a distribution, would both solve the problem
> which is currently discussed in this thread and make life easier for
> other projects. (And without the need to introduce additional legal
> question marks.)
>
> Jochen
>
>
I'm attempting to get answer to existing legal question marks. Like
David Jenks said:
"
In my opinion this is unnecessary and the source jars produced by maven
for instance by the release profile in the proposed apache pom v 6 are
adequate. I'd like this principle to be clearly established and stated
or clearly refuted."
Can we start there?
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Clarification on the release requirements
Posted by Jochen Wiedmann <jo...@gmail.com>.
Hi, Brian,
On Tue, Apr 28, 2009 at 5:12 PM, Brian Fox <br...@infinity.nu> wrote:
> Specifically if a tool was available to convert maven sources jars into a
> buildable source tree, is that acceptable?
regardless of the legal aspects, I think this goes in the wrong
direction, for practical reasons.
Most projects, which are using Maven as the build system, would want
to create "classical" distributions anyways. (The exception being
basically Maven plugins.) In other words, enhancing Maven's abilities
to build and deploy such a distribution, would both solve the problem
which is currently discussed in this thread and make life easier for
other projects. (And without the need to introduce additional legal
question marks.)
Jochen
--
Don't trust a government that doesn't trust you.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org