You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@allura.apache.org by Cory Johns <jo...@gmail.com> on 2013/09/18 23:34:02 UTC
RFC: LICENSE and NOTICE cleanups (ASF release)
I made some LICENSE and NOTICE cleanup changes [1], and created an ASF
Release Guidelines document [2] based on feedback on the [VOTE] [3] and
[DISCUSS] [4] threads.
Please review the changes and the guideline doc, and respond with any
comments, concerns, or suggestions. I'm going to cancel the current vote
so that we can create a new, hopefully perfect release. :-)
Thanks
[1] First 5 commits on:
https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=shortlog;h=refs/heads/cj/6422
[2]
https://forge-allura.apache.org/p/allura/wiki/ASF%20Release%20Guidelines/
[3]
http://mail-archives.apache.org/mod_mbox/incubator-general/201309.mbox/%3CCAOGo0VYhsbeKSV%3DzxKA%3DTOcf76X0M%2B-KeC3tNnRzmPc7hJLG2w%40mail.gmail.com%3E
[4] This, and the following 4 messages:
http://mail-archives.apache.org/mod_mbox/incubator-general/201309.mbox/%3CCAOGo0VYCKEyvV0icOtVJxZuW1%3DUUHFxrHHnDPU5kzzWM%2B8ggpg%40mail.gmail.com%3E
Re: RFC: LICENSE and NOTICE cleanups (ASF release)
Posted by Dave Brondsema <da...@brondsema.net>.
Cory asked about PyPI releases on the incubator list and we got this reponse:
http://mail-archives.apache.org/mod_mbox/incubator-general/201309.mbox/%3CCAAS6%3D7i4Nq4Pg6de205nn-swW4VrN%2BfZ5bUu7tDRqHEKomqwBQ%40mail.gmail.com%3E
Does that help us enough to decide what way we want to go with this?
On 9/24/13 5:40 PM, Dave Brondsema wrote:
> I think sebb's comments could be interpreted either way :) But it sounds like
> we agree that it's better not to have extra LICENSE & NOTICE files that may
> confuse people.
>
> I like Peter's suggestion of keeping them in the source so that they're ready if
> we need them later for PyPI releases, and then have a little release script to
> remove them from the tarball. A little release script could be nice anyway to
> make sure we don't fat finger any details (git archive params, proper filename,
> add git tag, create hash files). We would have to keep them both maintained
> when we add new bundled dependencies.
>
> I also see Cory's point that we might not even need the per-package LICENSE &
> NOTICE files if we release via pypi. But if we do end up needing them, then
> splitting them back out of the combined top-level file to reconstruct
> individually could be difficult and error-prone.
>
> -Dave
>
> On 9/24/13 3:32 PM, Cory Johns wrote:
>> I'm not arguing that he didn't suggest that we *should* have only a single
>> LICENSE and NOTICE file, but that is different than *must*. I was also
>> reading that in context of the previous statement that the top-level
>> LICENSE and NOTICE files were incorrect and, subsequently, that the extra
>> files were confusing. I took that to mean that if the top-level files were
>> correct, the additional files would be less of an issue. Particularly when
>> taken together with Marvin's message in the [DICSUSS] thread [1] explicitly
>> discussing the sub-package LICENSE and NOTICE files; his advice was they
>> needed to be reduced to be minimally complete for their respective
>> sub-package, just like the top-level LICENSE and NOTICE file must be
>> minimally complete for the whole release.
>>
>> That said, I do think that it might be better to remove the extra LICENSE
>> and NOTICE files, particularly since we won't be distributing the
>> individual PyPI packages through ASF channels so it is quite possible that
>> the legal requirements do not apply (and the file headers should be
>> sufficient for PyPI).
>>
>>
>> [1]
>> http://mail-archives.apache.org/mod_mbox/incubator-general/201309.mbox/%3CCAAS6=7hTA13GHbBwwy3-X+Bz5i38X4UoM+cYsv7Q13x+azp7mw@mail.gmail.com%3E
>>
>>
>> On Tue, Sep 24, 2013 at 2:36 PM, Peter Hartmann <ma...@gmail.com>wrote:
>>
>>> W dniu 24.09.2013 o 20:27 Cory Johns <jo...@gmail.com> pisze:
>>>
>>>
>>> Sebb didn't say that we *must* have *only* top-level LICENSE and NOTICE
>>>> files, just that: 1) the top-level LICENSE file was incomplete and the
>>>> top-level NOTICE file contained items it shouldn't; 2) that (possibly
>>>> because of point 1) the LICENSE and NOTICE files in the sub-directories
>>>> would be confusing to the reviewers and end-users.
>>>>
>>>
>>> With respect, I think he said exactly that:
>>>
>>> "There should be a single NOTICE and LICENSE file in the parent
>>> directory (allura/) which covers all the contents (and nothing else)."
>>>
>>> At least that's the way I read it, "single NOTICE and LICENSE (...) and
>>> nothing else" looks and sounds quite definitive to me.
>>>
>>>
>>> Trying to come up with some process or program to add or remove licenses
>>>> when building a release might be nice, but I'm not sure that it should
>>>> block our initial release.
>>>>
>>>
>>> I'm pretty shure it shouldn't :)
>>>
>>> On a NOTICE point, if that's how it is determined - perfectly fine.
>>> Perhaps I'll propose some better wording to these legal docs, If I'll be
>>> able to someday :(
>>>
>>
>
>
>
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
Re: RFC: LICENSE and NOTICE cleanups (ASF release)
Posted by Dave Brondsema <da...@brondsema.net>.
I think sebb's comments could be interpreted either way :) But it sounds like
we agree that it's better not to have extra LICENSE & NOTICE files that may
confuse people.
I like Peter's suggestion of keeping them in the source so that they're ready if
we need them later for PyPI releases, and then have a little release script to
remove them from the tarball. A little release script could be nice anyway to
make sure we don't fat finger any details (git archive params, proper filename,
add git tag, create hash files). We would have to keep them both maintained
when we add new bundled dependencies.
I also see Cory's point that we might not even need the per-package LICENSE &
NOTICE files if we release via pypi. But if we do end up needing them, then
splitting them back out of the combined top-level file to reconstruct
individually could be difficult and error-prone.
-Dave
On 9/24/13 3:32 PM, Cory Johns wrote:
> I'm not arguing that he didn't suggest that we *should* have only a single
> LICENSE and NOTICE file, but that is different than *must*. I was also
> reading that in context of the previous statement that the top-level
> LICENSE and NOTICE files were incorrect and, subsequently, that the extra
> files were confusing. I took that to mean that if the top-level files were
> correct, the additional files would be less of an issue. Particularly when
> taken together with Marvin's message in the [DICSUSS] thread [1] explicitly
> discussing the sub-package LICENSE and NOTICE files; his advice was they
> needed to be reduced to be minimally complete for their respective
> sub-package, just like the top-level LICENSE and NOTICE file must be
> minimally complete for the whole release.
>
> That said, I do think that it might be better to remove the extra LICENSE
> and NOTICE files, particularly since we won't be distributing the
> individual PyPI packages through ASF channels so it is quite possible that
> the legal requirements do not apply (and the file headers should be
> sufficient for PyPI).
>
>
> [1]
> http://mail-archives.apache.org/mod_mbox/incubator-general/201309.mbox/%3CCAAS6=7hTA13GHbBwwy3-X+Bz5i38X4UoM+cYsv7Q13x+azp7mw@mail.gmail.com%3E
>
>
> On Tue, Sep 24, 2013 at 2:36 PM, Peter Hartmann <ma...@gmail.com>wrote:
>
>> W dniu 24.09.2013 o 20:27 Cory Johns <jo...@gmail.com> pisze:
>>
>>
>> Sebb didn't say that we *must* have *only* top-level LICENSE and NOTICE
>>> files, just that: 1) the top-level LICENSE file was incomplete and the
>>> top-level NOTICE file contained items it shouldn't; 2) that (possibly
>>> because of point 1) the LICENSE and NOTICE files in the sub-directories
>>> would be confusing to the reviewers and end-users.
>>>
>>
>> With respect, I think he said exactly that:
>>
>> "There should be a single NOTICE and LICENSE file in the parent
>> directory (allura/) which covers all the contents (and nothing else)."
>>
>> At least that's the way I read it, "single NOTICE and LICENSE (...) and
>> nothing else" looks and sounds quite definitive to me.
>>
>>
>> Trying to come up with some process or program to add or remove licenses
>>> when building a release might be nice, but I'm not sure that it should
>>> block our initial release.
>>>
>>
>> I'm pretty shure it shouldn't :)
>>
>> On a NOTICE point, if that's how it is determined - perfectly fine.
>> Perhaps I'll propose some better wording to these legal docs, If I'll be
>> able to someday :(
>>
>
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><
Re: RFC: LICENSE and NOTICE cleanups (ASF release)
Posted by Cory Johns <jo...@gmail.com>.
I'm not arguing that he didn't suggest that we *should* have only a single
LICENSE and NOTICE file, but that is different than *must*. I was also
reading that in context of the previous statement that the top-level
LICENSE and NOTICE files were incorrect and, subsequently, that the extra
files were confusing. I took that to mean that if the top-level files were
correct, the additional files would be less of an issue. Particularly when
taken together with Marvin's message in the [DICSUSS] thread [1] explicitly
discussing the sub-package LICENSE and NOTICE files; his advice was they
needed to be reduced to be minimally complete for their respective
sub-package, just like the top-level LICENSE and NOTICE file must be
minimally complete for the whole release.
That said, I do think that it might be better to remove the extra LICENSE
and NOTICE files, particularly since we won't be distributing the
individual PyPI packages through ASF channels so it is quite possible that
the legal requirements do not apply (and the file headers should be
sufficient for PyPI).
[1]
http://mail-archives.apache.org/mod_mbox/incubator-general/201309.mbox/%3CCAAS6=7hTA13GHbBwwy3-X+Bz5i38X4UoM+cYsv7Q13x+azp7mw@mail.gmail.com%3E
On Tue, Sep 24, 2013 at 2:36 PM, Peter Hartmann <ma...@gmail.com>wrote:
> W dniu 24.09.2013 o 20:27 Cory Johns <jo...@gmail.com> pisze:
>
>
> Sebb didn't say that we *must* have *only* top-level LICENSE and NOTICE
>> files, just that: 1) the top-level LICENSE file was incomplete and the
>> top-level NOTICE file contained items it shouldn't; 2) that (possibly
>> because of point 1) the LICENSE and NOTICE files in the sub-directories
>> would be confusing to the reviewers and end-users.
>>
>
> With respect, I think he said exactly that:
>
> "There should be a single NOTICE and LICENSE file in the parent
> directory (allura/) which covers all the contents (and nothing else)."
>
> At least that's the way I read it, "single NOTICE and LICENSE (...) and
> nothing else" looks and sounds quite definitive to me.
>
>
> Trying to come up with some process or program to add or remove licenses
>> when building a release might be nice, but I'm not sure that it should
>> block our initial release.
>>
>
> I'm pretty shure it shouldn't :)
>
> On a NOTICE point, if that's how it is determined - perfectly fine.
> Perhaps I'll propose some better wording to these legal docs, If I'll be
> able to someday :(
>
Re: RFC: LICENSE and NOTICE cleanups (ASF release)
Posted by Peter Hartmann <ma...@gmail.com>.
W dniu 24.09.2013 o 20:27 Cory Johns <jo...@gmail.com> pisze:
> Sebb didn't say that we *must* have *only* top-level LICENSE and NOTICE
> files, just that: 1) the top-level LICENSE file was incomplete and the
> top-level NOTICE file contained items it shouldn't; 2) that (possibly
> because of point 1) the LICENSE and NOTICE files in the sub-directories
> would be confusing to the reviewers and end-users.
With respect, I think he said exactly that:
"There should be a single NOTICE and LICENSE file in the parent
directory (allura/) which covers all the contents (and nothing else)."
At least that's the way I read it, "single NOTICE and LICENSE (...) and
nothing else" looks and sounds quite definitive to me.
> Trying to come up with some process or program to add or remove licenses
> when building a release might be nice, but I'm not sure that it should
> block our initial release.
I'm pretty shure it shouldn't :)
On a NOTICE point, if that's how it is determined - perfectly fine.
Perhaps I'll propose some better wording to these legal docs, If I'll be
able to someday :(
Re: RFC: LICENSE and NOTICE cleanups (ASF release)
Posted by Cory Johns <jo...@gmail.com>.
Sebb didn't say that we *must* have *only* top-level LICENSE and NOTICE
files, just that: 1) the top-level LICENSE file was incomplete and the
top-level NOTICE file contained items it shouldn't; 2) that (possibly
because of point 1) the LICENSE and NOTICE files in the sub-directories
would be confusing to the reviewers and end-users. I think that, from a
legal standpoint, as long as the top-level LICENSE and NOTICE file are
correct, we're ok. The additional files LICENSE files might be confusing,
but we can (and do) bundle third-party libraries that contain a LICENSE
file, so I don't think we're going to be able to remove them entirely.
Trying to come up with some process or program to add or remove licenses
when building a release might be nice, but I'm not sure that it should
block our initial release.
Regarding the public domain code, "permissive licenses" refers to all of
the licenses that are allowed to be distributed along with an ASF project
release, and "attribution is required" refers to the reference in the
LICENSE file. My understanding now is that it's very unlikely that we need
anything in the NOTICE file, as the only time something should be added to
that is if a bundled library's license *specifically* requires it, most
likely by having its own NOTICE file or by explicitly mentioning it in the
license. Dave found a specific example of this, the Creative Commons
Attribution License: http://creativecommons.org/licenses/by/2.5/
After we come to a consensus on these items, it would probably be worth
asking again on the existing [DISCUSS] thread to verify our understanding,
prior to moving forward with the next release.
On Tue, Sep 24, 2013 at 1:56 PM, Peter Hartmann <ma...@gmail.com>wrote:
> My free time has shortened again, for a while. I only occasionally come
> home and check email. I hope my comments are not coming too late and will
> be helpful anyways.
>
> About multiple LICENSE: I did set it up this way having future PyPI
> releases in mind and took care to ensure that the content is not in
> conflict. I don't remember there be statement like "one LICENSE and nothing
> else", but I assume sebb is right on that.
>
> Dave suggested, that for PyPI we'll need to prepare some (presumably
> automated) way to put individual LICENSE and NOTICE files. I think it would
> be very difficult from engineering standpoint to split licenses like that.
> Instead, I propose to treat Apache releases in a special way. That is,
> remove per-package files from archive before releasing and not reflect this
> in source tree. Source code repository, even with open access, is not
> considered a distribution channel and is not required to follow release
> guidelines. And building top-level LICENSE from per-package files can be
> automated fairly easy.
>
> About NOTICE: legal docs clearly state that for public domain code,
> "Attribution is required (in a similar fashion to permissive licenses)"[1].
>
> For what I know, public domain code isn't licensed - in fact, that's a
> very important distinction. Thus, I read this as "in a similar fashion to
> required attributions in permissive licenses". And these fall in category
> of "required third-party notice"[2] - consider the last sentence/paragraph
> - which belong in NOTICE.
>
> Either sebb is wrong about NOTICE or legal guidelines are misleading, I
> don't see third option.
>
> [1] http://apache.org/legal/**resolved.html#can-works-**
> placed-in-the-public-domain-**be-included-in-apache-products<http://apache.org/legal/resolved.html#can-works-placed-in-the-public-domain-be-included-in-apache-products>
> [2] http://apache.org/legal/**resolved.html#required-third-**party-notices<http://apache.org/legal/resolved.html#required-third-party-notices>
>
Re: RFC: LICENSE and NOTICE cleanups (ASF release)
Posted by Peter Hartmann <ma...@gmail.com>.
My free time has shortened again, for a while. I only occasionally come
home and check email. I hope my comments are not coming too late and will
be helpful anyways.
About multiple LICENSE: I did set it up this way having future PyPI
releases in mind and took care to ensure that the content is not in
conflict. I don't remember there be statement like "one LICENSE and
nothing else", but I assume sebb is right on that.
Dave suggested, that for PyPI we'll need to prepare some (presumably
automated) way to put individual LICENSE and NOTICE files. I think it
would be very difficult from engineering standpoint to split licenses like
that. Instead, I propose to treat Apache releases in a special way. That
is, remove per-package files from archive before releasing and not reflect
this in source tree. Source code repository, even with open access, is not
considered a distribution channel and is not required to follow release
guidelines. And building top-level LICENSE from per-package files can be
automated fairly easy.
About NOTICE: legal docs clearly state that for public domain code,
"Attribution is required (in a similar fashion to permissive licenses)"[1].
For what I know, public domain code isn't licensed - in fact, that's a
very important distinction. Thus, I read this as "in a similar fashion to
required attributions in permissive licenses". And these fall in category
of "required third-party notice"[2] - consider the last sentence/paragraph
- which belong in NOTICE.
Either sebb is wrong about NOTICE or legal guidelines are misleading, I
don't see third option.
[1]
http://apache.org/legal/resolved.html#can-works-placed-in-the-public-domain-be-included-in-apache-products
[2] http://apache.org/legal/resolved.html#required-third-party-notices
Re: RFC: LICENSE and NOTICE cleanups (ASF release)
Posted by Cory Johns <jo...@gmail.com>.
And I think you're right about HTML5 Canvas, so I removed it (branch in
first message updated).
On Tue, Sep 24, 2013 at 1:04 PM, Cory Johns <jo...@gmail.com> wrote:
> My reading of Marvin's reply[1] is that the important thing is the
> top-level LICENSE and NOTICE file be complete and minimal, which my changes
> should address, and that derived-source releases should have their own,
> complete and minimal for their smaller scope, LICENSE and NOTICE files.
> (Although, that last part may only apply if the derived-source release is
> distributed via Apache channels, so it may not even be necessary for a PyPI
> package, but regardless my interpretation is that subdirectory LICENSE and
> NOTICE files are not really a problem as long as the top-level versions are
> complete & minimal for the entire distribution.)
>
>
> [1]
> http://mail-archives.apache.org/mod_mbox/incubator-general/201309.mbox/%3CCAAS6=7hTA13GHbBwwy3-X+Bz5i38X4UoM+cYsv7Q13x+azp7mw@mail.gmail.com%3E
>
>
> On Thu, Sep 19, 2013 at 12:18 PM, Dave Brondsema <da...@brondsema.net>wrote:
>
>> Per http://www.apache.org/dev/licensing-howto.html#alv2-dep I don't
>> think we
>> need the "HTML5 Canvas" section in our LICENSE file.
>>
>> From [3] we still need to address:
>>
>> > There should be a single NOTICE and LICENSE file in the parent
>> > directory (allura/) which covers all the contents (and nothing else).
>> >
>> > I think that is a release blocker.
>>
>> I think when we get to the point where we're making releases in PyPI
>> we'll need
>> build steps that put the appropriate NOTICE and LICENSE files within the
>> individual packages for that distribution channel. But for our source
>> repo and
>> this whole-Allura release needs the top-level files only.
>>
>> -Dave
>>
>> On 9/18/13 5:34 PM, Cory Johns wrote:
>> > I made some LICENSE and NOTICE cleanup changes [1], and created an ASF
>> > Release Guidelines document [2] based on feedback on the [VOTE] [3] and
>> > [DISCUSS] [4] threads.
>> >
>> > Please review the changes and the guideline doc, and respond with any
>> > comments, concerns, or suggestions. I'm going to cancel the current
>> vote
>> > so that we can create a new, hopefully perfect release. :-)
>> >
>> >
>> > Thanks
>> >
>> >
>> > [1] First 5 commits on:
>> >
>> https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=shortlog;h=refs/heads/cj/6422
>> >
>> > [2]
>> >
>> https://forge-allura.apache.org/p/allura/wiki/ASF%20Release%20Guidelines/
>> >
>> > [3]
>> >
>> http://mail-archives.apache.org/mod_mbox/incubator-general/201309.mbox/%3CCAOGo0VYhsbeKSV%3DzxKA%3DTOcf76X0M%2B-KeC3tNnRzmPc7hJLG2w%40mail.gmail.com%3E
>> >
>> > [4] This, and the following 4 messages:
>> >
>> http://mail-archives.apache.org/mod_mbox/incubator-general/201309.mbox/%3CCAOGo0VYCKEyvV0icOtVJxZuW1%3DUUHFxrHHnDPU5kzzWM%2B8ggpg%40mail.gmail.com%3E
>> >
>>
>>
>>
>> --
>> Dave Brondsema : dave@brondsema.net
>> http://www.brondsema.net : personal
>> http://www.splike.com : programming
>> <><
>>
>
>
Re: RFC: LICENSE and NOTICE cleanups (ASF release)
Posted by Cory Johns <jo...@gmail.com>.
My reading of Marvin's reply[1] is that the important thing is the
top-level LICENSE and NOTICE file be complete and minimal, which my changes
should address, and that derived-source releases should have their own,
complete and minimal for their smaller scope, LICENSE and NOTICE files.
(Although, that last part may only apply if the derived-source release is
distributed via Apache channels, so it may not even be necessary for a PyPI
package, but regardless my interpretation is that subdirectory LICENSE and
NOTICE files are not really a problem as long as the top-level versions are
complete & minimal for the entire distribution.)
[1]
http://mail-archives.apache.org/mod_mbox/incubator-general/201309.mbox/%3CCAAS6=7hTA13GHbBwwy3-X+Bz5i38X4UoM+cYsv7Q13x+azp7mw@mail.gmail.com%3E
On Thu, Sep 19, 2013 at 12:18 PM, Dave Brondsema <da...@brondsema.net> wrote:
> Per http://www.apache.org/dev/licensing-howto.html#alv2-dep I don't think
> we
> need the "HTML5 Canvas" section in our LICENSE file.
>
> From [3] we still need to address:
>
> > There should be a single NOTICE and LICENSE file in the parent
> > directory (allura/) which covers all the contents (and nothing else).
> >
> > I think that is a release blocker.
>
> I think when we get to the point where we're making releases in PyPI we'll
> need
> build steps that put the appropriate NOTICE and LICENSE files within the
> individual packages for that distribution channel. But for our source
> repo and
> this whole-Allura release needs the top-level files only.
>
> -Dave
>
> On 9/18/13 5:34 PM, Cory Johns wrote:
> > I made some LICENSE and NOTICE cleanup changes [1], and created an ASF
> > Release Guidelines document [2] based on feedback on the [VOTE] [3] and
> > [DISCUSS] [4] threads.
> >
> > Please review the changes and the guideline doc, and respond with any
> > comments, concerns, or suggestions. I'm going to cancel the current vote
> > so that we can create a new, hopefully perfect release. :-)
> >
> >
> > Thanks
> >
> >
> > [1] First 5 commits on:
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=shortlog;h=refs/heads/cj/6422
> >
> > [2]
> >
> https://forge-allura.apache.org/p/allura/wiki/ASF%20Release%20Guidelines/
> >
> > [3]
> >
> http://mail-archives.apache.org/mod_mbox/incubator-general/201309.mbox/%3CCAOGo0VYhsbeKSV%3DzxKA%3DTOcf76X0M%2B-KeC3tNnRzmPc7hJLG2w%40mail.gmail.com%3E
> >
> > [4] This, and the following 4 messages:
> >
> http://mail-archives.apache.org/mod_mbox/incubator-general/201309.mbox/%3CCAOGo0VYCKEyvV0icOtVJxZuW1%3DUUHFxrHHnDPU5kzzWM%2B8ggpg%40mail.gmail.com%3E
> >
>
>
>
> --
> Dave Brondsema : dave@brondsema.net
> http://www.brondsema.net : personal
> http://www.splike.com : programming
> <><
>
Re: RFC: LICENSE and NOTICE cleanups (ASF release)
Posted by Dave Brondsema <da...@brondsema.net>.
Per http://www.apache.org/dev/licensing-howto.html#alv2-dep I don't think we
need the "HTML5 Canvas" section in our LICENSE file.
>From [3] we still need to address:
> There should be a single NOTICE and LICENSE file in the parent
> directory (allura/) which covers all the contents (and nothing else).
>
> I think that is a release blocker.
I think when we get to the point where we're making releases in PyPI we'll need
build steps that put the appropriate NOTICE and LICENSE files within the
individual packages for that distribution channel. But for our source repo and
this whole-Allura release needs the top-level files only.
-Dave
On 9/18/13 5:34 PM, Cory Johns wrote:
> I made some LICENSE and NOTICE cleanup changes [1], and created an ASF
> Release Guidelines document [2] based on feedback on the [VOTE] [3] and
> [DISCUSS] [4] threads.
>
> Please review the changes and the guideline doc, and respond with any
> comments, concerns, or suggestions. I'm going to cancel the current vote
> so that we can create a new, hopefully perfect release. :-)
>
>
> Thanks
>
>
> [1] First 5 commits on:
> https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=shortlog;h=refs/heads/cj/6422
>
> [2]
> https://forge-allura.apache.org/p/allura/wiki/ASF%20Release%20Guidelines/
>
> [3]
> http://mail-archives.apache.org/mod_mbox/incubator-general/201309.mbox/%3CCAOGo0VYhsbeKSV%3DzxKA%3DTOcf76X0M%2B-KeC3tNnRzmPc7hJLG2w%40mail.gmail.com%3E
>
> [4] This, and the following 4 messages:
> http://mail-archives.apache.org/mod_mbox/incubator-general/201309.mbox/%3CCAOGo0VYCKEyvV0icOtVJxZuW1%3DUUHFxrHHnDPU5kzzWM%2B8ggpg%40mail.gmail.com%3E
>
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><