www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: GitHib releases
Date Thu, 01 Dec 2016 11:57:30 GMT

Am 30.11.2016 um 19:08 schrieb sebb <sebbaz@gmail.com<mailto:sebbaz@gmail.com>>:

On 30 November 2016 at 11:44, John D. Ament <johndament@apache.org<mailto:johndament@apache.org>>

On Wed, Nov 30, 2016 at 5:38 AM Felix Meschberger <fmeschbe@adobe.com<mailto:fmeschbe@adobe.com>>

If people hit GitHub they usually first hit the repository’s main page and
thus get shown the README.md file.

How about adding a sentence or two to this file indicating that official
releases are only available from dist.apache.org<http://dist.apache.org/> while the
artifacts from
…/releases are not official/endorsed/supported ?

No, please don't.

dist.apache.org<http://dist.apache.org/> is NOT to be used for public URLs of releases.
It does
not have the bandwidth.
It is only intended as the source (as in origin) for the releases on
www.apache.org/dist<http://www.apache.org/dist>, which in turn is the source for the
3rd party

Nor indeed is www.apache.org/dist<http://www.apache.org/dist> to be used for release
except as a backup if none of the 3rd party mirrors are available.

Sounds like a reasonable approach.

Only if the appropriate URL is used …

Thanks for fixing the URL ;-)

Of course, each project should indicate their own canonical download URL ---



Am 30.11.2016 um 10:53 schrieb Stian Soiland-Reyes <stain@apache.org<mailto:stain@apache.org>>:

I agree this is not a big legal issue and probably should be better
discussed on dev@community or general@incubator.

It is GitHub that claims it is a "release" for any tag.  Projects
should still keep this in mind (they might not be aware of it).

Pushing a release-looking tag without "-RC1" suffix is confusing in
any case - it assumes the vote will pass and git users will think it
is the release. Best practice is to never change a published tag -
some projects like Commons don't even remove RC tags that have been
under vote - and so the release tag should be pushed after the vote
has passed. (Preferably signed with git tag --sign)

Some have argued that release candidate tags should NOT be pushed to
the repository and instead place RC tag on a personal github fork
instead until the vote has passed -- personally I don't like this
solution as the RC commit under vote then is not on ASF

(Several git workarounds exists, including using branches or using
commit pointers that are not under refs/tags or refs/branches, e.g.
refs/rc/0.3.0-RC1 )

GitHub releases can be used to our advantage, if you use a tag commit
(as in "git tag --sign" th ecommit message becomes the release message
on GitHub, for instance I did this (arguably minimal msg):


On 30 November 2016 at 08:16, Jochen Wiedmann
<jochen.wiedmann@gmail.com> wrote:
On Tue, Nov 29, 2016 at 9:06 PM, Justin Mclean
<justin@classsoftware.com> wrote:

In reviews of a couple of incubator releases I've noticed that GitHub
has created releases and made them publicly available before the dev or
incubator vote was finished.

Technicality: I don't think, that "GitHub" has created releases, but
someone from the project. See [1]. Apart from the legal aspects (which
clearly matter on this list), I also see
technical issues (For example: Releases should be distributed via
www.apache.org/dist, and not via the scm.)



The next time you hear: "Don't reinvent the wheel!"


To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

Stian Soiland-Reyes

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<mailto:legal-discuss-unsubscribe@apache.org>
For additional commands, e-mail: legal-discuss-help@apache.org<mailto:legal-discuss-help@apache.org>

View raw message