On Wed, Jun 7, 2017 at 5:28 PM sebb <seb...@gmail.com> wrote:

> On 7 June 2017 at 01:59, Christopher <ctubb...@apache.org> wrote:
> > On Tue, Jun 6, 2017 at 6:47 PM sebb <seb...@gmail.com> wrote:
> >
> >> On 6 June 2017 at 23:38, Christopher <ctubb...@apache.org> wrote:
> >> > On Tue, Jun 6, 2017 at 6:29 PM sebb <seb...@gmail.com> wrote:
> >> >
> >> >> On 6 June 2017 at 23:25, Christopher <ctubb...@apache.org> wrote:
> >> >> > On Tue, Jun 6, 2017 at 6:03 PM sebb <seb...@gmail.com> wrote:
> >> >> >
> >> >> >> On 6 June 2017 at 21:15, Keith Turner <ke...@deenlo.com> wrote:
> >> >> >> > Dear IPMC,
> >> >> >> >
> >> >> >> > Please vote for the following release candidate of Apache Fluo
> >> >> >> > 1.1.0-incubating.
> >> >> >> >
> >> >> >> > PPMC vote thread:
> >> >> >> >
> >> >> >>
> >> >>
> >>
> https://lists.apache.org/thread.html/c815b7a22fab10281ab2d4e88418a47a5903ba85327058bb727c7ccd@%3Cdev.fluo.apache.org%3E
> >> >> >> >
> >> >> >>
> >> >>
> >>
> https://lists.apache.org/thread.html/99508ef4a2b782b82494e4250713c1d0917b75cf7149bec64455bea2@%3Cdev.fluo.apache.org%3E
> >> >> >> >
> >> >> >> > Staged dist artifacts:
> >> >> >> >
> >> >> >>
> >> >>
> >>
> https://dist.apache.org/repos/dist/dev/incubator/fluo/fluo/1.1.0-incubating-rc1/
> >> >> >>
> >> >> >> The hashes need to be in individual files, like the signature
> (.asc)
> >> >> >> [You can probably copy the corresponding ones from the Maven
> repo.]
> >> >> >>
> >> >> >> AFAIK the MD5SUM and SHA1SUM files should not be present.
> >> >> >>
> >> >> >> I'm not sure the .gitignore files should be there.
> >> >> >>
> >> >> >>
> >> >> >
> >> >> > I believe the *SUM files have been discussed before. I do not
> believe
> >> it
> >> >> to
> >> >> > be an issue, as INFRA excludes these from mirroring in the same
> way as
> >> >> > other files, and they are convenient.
> >> >>
> >> >> But the individual has files are still required.
> >> >>
> >> >>
> >> > Required by what policy?
> >> >
> >>
> >> http://www.apache.org/dev/release-distribution.html#sigs-and-sums
> >>
> >>
> >
> > Thanks.
> >
> > That's interesting. The current wording seems like a technical
> requirement
> > for the mirror distribution process. It seems like the intent (though,
> hard
> > to know for sure) was to follow a pattern that would ensure hashes aren't
> > mirrored.
>
> AIUI that is partly the case.
> AFAIK there's also the expectation that consumers will be able to use
> a standard name for the hashes and sigs.
>
>

I wouldn't have thought INFRA would be in the business of managing consumer
expectations. Seems like a PMC responsibility, at the individual community
level, to me.



> > However, it is currently inconsistent with the actual behavior of
> > the mirror distribution process and also seems to apply to all other
> > infra-supported channels like Nexus. It also seems to be regularly
> > violated, since there are a *LOT* of projects which use variants, such as
> > ".sha1" or ".sha256" or ".sha512" or ".mds" in dist/release.
>
> Does not make it right; AFAIK many such variants are excluded from synch.
>
>

In anticipation of this response, I've already conceded this point. ;)
As I said, it's merely a strong indication that the page isn't accurately
documenting the policy being enforced.


> > Also, every
> > Maven artifact deployed to Nexus is also in violation.
>
> Nexus (i.e. staging for the Maven repo) has separate rules.
>
>
The policy you cite specifically says "Every artifact distributed to the
public through Apache channels". The wording doesn't allow for differences
between system-specific channels.

If we're going by system-specific guidance, then I don't understand your
original objection, because SHA1SUM and MD5SUM files are explicitly
mentioned in the system-specific guidance for "normal distribution" through
the mirrors
http://www.apache.org/dev/release-publishing.html#distribution_dist , just
as .sha1 is explicitly mentioned in the Maven publication guidance (linked
in the section which immediately follows the "normal distribution" section).

I'm assuming the basis of the objection was that the global INFRA policy
supersedes system-specific guidance. If that's not the case, then I'm very
confused about the basis for the original objection.


> > That's not an excuse
> > to violate it again, of course... but it's a strong indication that the
> > page isn't accurately documenting the actual policy that INFRA enforces
> for
> > distribution through ASF infra channels.
> >
> > Perhaps VP Infra would be willing to consider a change to the wording so
> it
> > more closely aligns with the actual requirements of the mirroring
> process.
> > I don't recall who that is at the moment. David Nalley, according to
> > https://home.apache.org/phonebook.html?pmc=infrastructure ? Is that
> right?
> > Or is it Greg Stein
> > (/foundation/officers/personnel-duties/infra-admin.txt)? Or should I just
> > start a conversation on an infra list somewhere? Or file a JIRA? I don't
> > know the best method to contact VP Infra to request update/clarification
> on
> > this policy issue.
> >
> >
> >
> >> >> > I'm not sure what .gitignore files you're referring to. There are
> >> some in
> >> >> > the directories above the RC directory, to support using SVN with
> >> git-svn
> >> >> > (git ignores empty directories; the .gitignore file preserves
> them).
> >> >> There
> >> >> > aren't any inside the 1.1.0-incubating-rc1 directory, though.
> >> >>
> >> >> I'm referring to the ones in the parent directories.
> >> >>
> >> >> Since the dist tree is SVN only (and will remain that way) there is
> no
> >> >> need for them.
> >> >>
> >> >>
> >> >
> >> > They are needed by git-svn in order to preserve the empty directory in
> >> the
> >> > clone. They can be ignored for the purposes of this vote, since they
> >> aren't
> >> > even in the same directory as the release candidate files, and will
> not
> >> be
> >> > included in the `svn mv` upon a successful vote.
> >>
> >> OK, so long as they are not added to the dist/release directory area.
> >>
> >> >
> >> >
> >> >> >
> >> >> >
> >> >> >> > Staged Maven repository:
> >> >> >> >
> >> >>
> https://repository.apache.org/content/repositories/orgapachefluo-1017/
> >> >> >> >
> >> >> >> > Signing KEYS:
> >> >> >> > https://www.apache.org/dist/incubator/fluo/KEYS
> >> >> >> > (fingerprint for this release:
> >> >> CF72CA07C8BC86A1C862765F9AACFB56352ACF76)
> >> >> >> >
> >> >> >> > Git repo:
> >> >> >> > https://gitbox.apache.org/repos/asf/incubator-fluo
> >> >> >> > (branch: 1.1.0-incubating-rc1,
> >> >> >> > commit: ad8ee492e2f435405f98d825781098c55186f4fb)
> >> >> >> >
> >> >> >> > This vote will end on Fri Jun  9 20:30:00 UTC 2017
> >> >> >> > (Fri Jun  9 16:30:00 EDT 2017 / Fri Jun  9 13:30:00 PDT 2017)
> >> >> >> >
> >> >> >> >
> >> ---------------------------------------------------------------------
> >> >> >> > To unsubscribe, e-mail:
> general-unsubscr...@incubator.apache.org
> >> >> >> > For additional commands, e-mail:
> general-h...@incubator.apache.org
> >> >> >> >
> >> >> >>
> >> >> >>
> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> >> >> For additional commands, e-mail:
> general-h...@incubator.apache.org
> >> >> >>
> >> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >> >>
> >> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Reply via email to