www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Mattmann <mattm...@apache.org>
Subject Re: GitHib releases
Date Wed, 30 Nov 2016 15:02:20 GMT




From: "John D. Ament" <johndament@apache.org>
Reply-To: "legal-discuss@apache.org" <legal-discuss@apache.org>
Date: Wednesday, November 30, 2016 at 3:44 AM
To: "legal-discuss@apache.org" <legal-discuss@apache.org>
Subject: Re: GitHib releases



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

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 while the artifacts from …/releases are not official/endorsed/supported


Sounds like a reasonable approach.



> Am 30.11.2016 um 10:53 schrieb Stian Soiland-Reyes <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
> infrastructure.
> (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):
> https://github.com/apache/incubator-taverna-language/releases/tag/0.15.1-incubating
> 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.)
>> Jochen
>> 1: https://git1-us-west.apache.org/repos/asf?p=incubator-joshua.git;a=summary
>> --
>> The next time you hear: "Don't reinvent the wheel!"
>> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
> --
> Stian Soiland-Reyes
> http://orcid.org/0000-0001-9842-9718
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org

View raw message