You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Justin Mclean <ju...@classsoftware.com> on 2016/11/29 20:06:38 UTC
GitHib releases
Hi,
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.
The most recent example can be found here [1]. Note that the apache-joshua-6.1 release has been available for 7 days to download as a zip/tar.gz but the vote hasn’t finished yet.
This seems to me to be against release policy as it’s making release candidates publicly available before the vote on them has finished [2][3].
Anyone else see this as a concern or does this not matter at all?
Thanks,
Justin
1. https://github.com/apache/incubator-joshua/releases
2. https://www.apache.org/dev/release-distribution.html#unreleased
3. http://www.apache.org/dev/release.html#what
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GitHib releases
Posted by Felix Meschberger <fm...@adobe.com>.
Am 30.11.2016 um 19:08 schrieb sebb <se...@gmail.com>>:
On 30 November 2016 at 11:44, John D. Ament <jo...@apache.org>> wrote:
On Wed, Nov 30, 2016 at 5:38 AM Felix Meschberger <fm...@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<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
mirrors.
Nor indeed is www.apache.org/dist<http://www.apache.org/dist> to be used for release downloads,
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 ---
Regards
Felix
Regards
Felix
Am 30.11.2016 um 10:53 schrieb Stian Soiland-Reyes <st...@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
<jo...@gmail.com> wrote:
On Tue, Nov 29, 2016 at 9:06 PM, Justin Mclean
<ju...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org<ma...@apache.org>
For additional commands, e-mail: legal-discuss-help@apache.org<ma...@apache.org>
Re: GitHib releases
Posted by sebb <se...@gmail.com>.
On 30 November 2016 at 11:44, John D. Ament <jo...@apache.org> wrote:
>
>
> On Wed, Nov 30, 2016 at 5:38 AM Felix Meschberger <fm...@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 ?
No, please don't.
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, which in turn is the source for the 3rd party
mirrors.
Nor indeed is www.apache.org/dist to be used for release downloads,
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 ...
>>
>>
>> Regards
>> Felix
>>
>> > Am 30.11.2016 um 10:53 schrieb Stian Soiland-Reyes <st...@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
>> > <jo...@gmail.com> wrote:
>> >> On Tue, Nov 29, 2016 at 9:06 PM, Justin Mclean
>> >> <ju...@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
>> >
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GitHib releases
Posted by Chris Mattmann <ma...@apache.org>.
+1
From: "John D. Ament" <jo...@apache.org>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Wednesday, November 30, 2016 at 3:44 AM
To: "legal-discuss@apache.org" <le...@apache.org>
Subject: Re: GitHib releases
On Wed, Nov 30, 2016 at 5:38 AM Felix Meschberger <fm...@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.
Regards
Felix
> Am 30.11.2016 um 10:53 schrieb Stian Soiland-Reyes <st...@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 <jo...@gmail.com> wrote:
>> On Tue, Nov 29, 2016 at 9:06 PM, Justin Mclean <ju...@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
>
Re: GitHib releases
Posted by "John D. Ament" <jo...@apache.org>.
On Wed, Nov 30, 2016 at 5:38 AM Felix Meschberger <fm...@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.
>
> Regards
> Felix
>
> > Am 30.11.2016 um 10:53 schrieb Stian Soiland-Reyes <st...@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 <jo...@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
> >
>
>
Re: GitHib releases
Posted by Felix Meschberger <fm...@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 while the artifacts from …/releases are not official/endorsed/supported ?
Regards
Felix
> Am 30.11.2016 um 10:53 schrieb Stian Soiland-Reyes <st...@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 <jo...@gmail.com> wrote:
>> On Tue, Nov 29, 2016 at 9:06 PM, Justin Mclean <ju...@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
>
Re: GitHib releases
Posted by Stian Soiland-Reyes <st...@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 <jo...@gmail.com> wrote:
> On Tue, Nov 29, 2016 at 9:06 PM, Justin Mclean <ju...@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
Re: GitHib releases
Posted by Jim Apple <jb...@cloudera.com>.
On Wed, Nov 30, 2016 at 12:16 AM, Jochen Wiedmann
<jo...@gmail.com> wrote:
> On Tue, Nov 29, 2016 at 9:06 PM, Justin Mclean <ju...@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.
That's not always the case. Github appears to think any git tag is
appropriate to call a "release" and offer as a zip file to the general
public.
This happened to Impala when I was the release manager.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GitHib releases
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Tue, Nov 29, 2016 at 9:06 PM, Justin Mclean <ju...@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
Re: GitHib releases
Posted by Chris Mattmann <ma...@apache.org>.
To me as a member of the Legal Committee, not a huge issue.* Apache Joshua Incubating
has shown good faith and is working through the release process.
Cheers,
Chris
* - also a member of Apache Joshua Incubating PPMC
From: "John D. Ament" <jo...@apache.org>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Tuesday, November 29, 2016 at 3:38 PM
To: "legal-discuss@apache.org" <le...@apache.org>
Subject: Re: GitHib releases
On Tue, Nov 29, 2016 at 3:07 PM Justin Mclean <ju...@classsoftware.com> wrote:
Hi,
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.
I personally don't believe these download links are an issue. They aren't the official release. They are a download of the git tag, equivalent to what the download link looks like (for instance https://github.com/apache/activemq-artemis/archive/master.zip ). We do need to make sure that the project's branding isn't pointing to github as a formal release (this will impact the OpenWhisk podling)
The most recent example can be found here [1]. Note that the apache-joshua-6.1 release has been available for 7 days to download as a zip/tar.gz but the vote hasn’t finished yet.
This came up with the metron podling as well, where they were pointing to that page for their downloads. That isn't good.
This seems to me to be against release policy as it’s making release candidates publicly available before the vote on them has finished [2][3].
Anyone else see this as a concern or does this not matter at all?
Thanks,
Justin
1. https://github.com/apache/incubator-joshua/releases
2. https://www.apache.org/dev/release-distribution.html#unreleased
3. http://www.apache.org/dev/release.html#what
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GitHib releases
Posted by Jim Apple <jb...@cloudera.com>.
FWIW, In my experience, tags are labeled by Github as releases even if
they are not on the master/default branch.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GitHib releases
Posted by Ignasi Barrera <na...@apache.org>.
If it is a matter of properly qualifying ASF official releases to avoid confusion or misunderstandings, would it be sufficient to create "release candidate" tags for the vote, and then the release tag once the vote has passed?
Something like creating a "apache-foo-1.0.0-rc1" tag, and once the vote has passed, just create the "apache-foo-1.0.0" tag pointing to the voted RC. IMO that properly identifies the tag as "not yet an official release" in a way most people will understand.
On 2016-11-29 21:38 (+0100), "John D. Ament" <jo...@apache.org> wrote:
> On Tue, Nov 29, 2016 at 3:07 PM Justin Mclean <ju...@classsoftware.com>
> wrote:
>
> > Hi,
> >
> > 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.
> >
>
> I personally don't believe these download links are an issue. They aren't
> the official release. They are a download of the git tag, equivalent to
> what the download link looks like (for instance
> https://github.com/apache/activemq-artemis/archive/master.zip ). We do
> need to make sure that the project's branding isn't pointing to github as a
> formal release (this will impact the OpenWhisk podling)
>
>
> >
> > The most recent example can be found here [1]. Note that the
> > apache-joshua-6.1 release has been available for 7 days to download as a
> > zip/tar.gz but the vote hasn\u2019t finished yet.
> >
> >
> This came up with the metron podling as well, where they were pointing to
> that page for their downloads. That isn't good.
>
>
> > This seems to me to be against release policy as it\u2019s making release
> > candidates publicly available before the vote on them has finished [2][3].
> >
> > Anyone else see this as a concern or does this not matter at all?
> >
> > Thanks,
> > Justin
> >
> > 1. https://github.com/apache/incubator-joshua/releases
> > 2. https://www.apache.org/dev/release-distribution.html#unreleased
> > 3. http://www.apache.org/dev/release.html#what
> > ---------------------------------------------------------------------
> > 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: GitHib releases
Posted by "John D. Ament" <jo...@apache.org>.
On Tue, Nov 29, 2016 at 3:07 PM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> 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.
>
I personally don't believe these download links are an issue. They aren't
the official release. They are a download of the git tag, equivalent to
what the download link looks like (for instance
https://github.com/apache/activemq-artemis/archive/master.zip ). We do
need to make sure that the project's branding isn't pointing to github as a
formal release (this will impact the OpenWhisk podling)
>
> The most recent example can be found here [1]. Note that the
> apache-joshua-6.1 release has been available for 7 days to download as a
> zip/tar.gz but the vote hasn’t finished yet.
>
>
This came up with the metron podling as well, where they were pointing to
that page for their downloads. That isn't good.
> This seems to me to be against release policy as it’s making release
> candidates publicly available before the vote on them has finished [2][3].
>
> Anyone else see this as a concern or does this not matter at all?
>
> Thanks,
> Justin
>
> 1. https://github.com/apache/incubator-joshua/releases
> 2. https://www.apache.org/dev/release-distribution.html#unreleased
> 3. http://www.apache.org/dev/release.html#what
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: GitHib releases
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> My understanding is that a GitHub “release” is created anytime you create a tag,
Only in the master/default branch I believe, you don’t see releases it you create a release branch and tag release candidates in that.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: GitHib releases
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
This has always annoyed me, especially when I see people on user@ lists saying they using version x.y.z when that version is still in the voting process. This applies to TLPs as well as podlings.
My understanding is that a GitHub “release” is created anytime you create a tag, so for ASF projects that means as soon as an ASF release candidate is tagged — before voting even starts.
In an ideal world, GitHub would provide a way to turn that feature off, and we could just disable it across all ASF GitHub mirrors.
-Taylor
> On Nov 29, 2016, at 3:06 PM, Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
> 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.
>
> The most recent example can be found here [1]. Note that the apache-joshua-6.1 release has been available for 7 days to download as a zip/tar.gz but the vote hasn’t finished yet.
>
> This seems to me to be against release policy as it’s making release candidates publicly available before the vote on them has finished [2][3].
>
> Anyone else see this as a concern or does this not matter at all?
>
> Thanks,
> Justin
>
> 1. https://github.com/apache/incubator-joshua/releases
> 2. https://www.apache.org/dev/release-distribution.html#unreleased
> 3. http://www.apache.org/dev/release.html#what
> ---------------------------------------------------------------------
> 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