Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Greg Stein]

On Thu, May 10, 2018 at 3:25 PM, Roman Shaposhnik 
wrote:

> On Thu, May 10, 2018 at 9:50 AM, Julian Hyde  wrote:
> > In other words, there are several ways to prove that a binary release is
> WRONG but (to Greg’s point) there is no way to prove it RIGHT.
>
> That's actually a great way to put it.
>

Yeah, it really is. Props to Julian!

Cheers,
-g

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Greg Stein]

On Thu, May 10, 2018 at 3:31 AM, Huxing Zhang  wrote:

> Hi,
>
> On Thu, May 10, 2018 at 3:59 PM, Willem Jiang 
> wrote:
> > Is there any plan for going through the vote process of Binary file?
>
> Yes, binaries will also go through the vote process.


No. It makes no sense.

There is NO WAY to verify a binary. Even compiling from source to binary on
your machine, and trying to compare against a target binary will generally
fail since timestamps are embedded. Or maybe there are different compilers
being used.

The Foundation *never* votes on binaries, because the Foundation DOES NOT
RELEASE BINARIES. The Foundation only votes/authorizes/releases source
code. REPEAT: only source code.

Only source. Which is verifiable. Which has provenance.

Regards,
-g
(Member, skipping my Infra hat)

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Greg Stein]

Please note: my initial message was not to question the release process.
Merely that Infra was asked to enable provision of artifacts within Maven
Central under a groupId that is not "org.apache". At the moment, we cannot
/ will-not work on making that possible. Infra doesn't involve itself in
community (release) processes, so please go about your business :-)


On Wed, May 9, 2018 at 3:34 AM, Huxing Zhang  wrote:

> On Wed, May 9, 2018 at 3:35 PM, Bertrand Delacretaz
>  wrote:
> > On Wed, May 9, 2018 at 3:44 AM, Huxing Zhang  wrote:
> >> ...The maven artifact is the most significant for most of the Dubbo
> >> users, so we want to include a maven artifact in the release
> >
> > Binaries are NOT part of Apache Releases, as mentioned earlier in this
> thread.
>
> Yes, we fully understood that.
>
> Here what I mean "release" does not mean an Apache release, it is
> actually a "hybrid" release, which includes:
>
> * source (following Apache release policy)
> * binary (it is optional but still following Apache release policy)
> * Maven artifacts under third-party coordinates (Non Apache release)
>
> >
> > Dubbo mentors, I think we need a clear description of how these
> > "hybrid" releases are done, to avoid any misunderstandings.
> >
> > Justin mentioned in this thread that that's been discussed on your dev
> > list, so you probably just need to summarize that and include the URL
> > in your next Incubator report.
> >
> > -Bertrand
>
> --
> Best Regards！
> Huxing
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Greg Stein]

Hi all,

I wanted to send a note that Infra has seen a couple requests from podlings
to publish under third-party Maven groupId coordinates (com.alibaba and
org.netbeans). Unless/until the Foundation owns these domains, we cannot
allow publishing under those coordinates.

Needless to say, we'll never own alibaba.com :p ... Maybe one day, we'll
get netbeans.org (what is the status on that?) ... But we cannot publish
convenience binaries to Maven Central before such time.

And please note that I said "convenience binaries". This is an important
point for the two podlings: the Foundation makes source code releases.
Period. Full stop. Both podlings can do that today -- there is nothing
inhibiting making such releases. ... What *cannot* be done is publishing
convenience binaries to those third-party coordinates.

The podlings will be able to publish under org.apache, of course. The
restriction merely applies to any compatibility/historical shims that are
retained, to map the old-named packages over to new org.apache naming.

Regards,
Greg Stein
Infrastructure Administrator, ASF

On Tue, May 8, 2018 at 12:15 PM, Brian Fox <bri...@infinity.nu> wrote:

> Was there discussion somewhere that decided to allow an Apache project
> to publish coordinates using com.alibaba? From my perspective this is
> highly unusual for an ASF project. From a central point of view, the
> fact that com.alibaba is registered to publish from a completely
> different repo (oss.sonatype.org) this creates potential for confusion
> over the provenance of the artifacts.
>
> On Wed, May 2, 2018 at 9:30 PM, Chris Lambertus <c...@apache.org> wrote:
> >
> >
> > On May 2, 2018, at 5:51 PM, Jun Liu <liu...@apache.org> wrote:
> >
> > Hi,
> >
> > We are preparing for the first apache incubating release for dubbo, turns
> > out we lack of some nexus permissions, this blocks our process.
> >
> > Could someone help us please? Here is the ticket asking permissions :
> > https://issues.apache.org/jira/browse/INFRA-16451
> >
> > Best regards,
> > Jun
> >
> >
> >
> > I don’t know how to approach this when the groupID doesn’t match
> org.apache.
> > I’ve requested help from the Sonatype folks.
> >
> > -Chris
> >
>

Re: List volume and issue tracking

[Greg Stein]

Many projects choose this pattern:

dev@ -- the development community's discussions
commits@ -- commit emails
issues@ -- all emails related to issues (GitHub/Jira)
notifications@ -- PR notifications, etc

All GitHub activity is required to be delivered to an ASF mailing list. It
is up to the (P)PMC to choose which/how. But they cannot be sent to
/dev/null. The above pattern generally provides the right breakdown for
what information people what to monitor.

Cheers,
Greg Stein
Infrastructure Administrator, ASF


On Sat, Apr 7, 2018 at 10:22 PM, Ian Luo <ian@gmail.com> wrote:

> I think this can be solved by distinguishing github notifications from
> regular dev@dubbo.apache.org traffic.  For github notifications,
> including issue and pull request, the update message should only go to the
> interested parties who are involved in this particular topic, but @dev
> should never be the audience.
>
> I guess @dev mail list is configured in 'Settings -> Integrations &
> Services -> Email' for github.com/apache/inclubator-dubbo* projects. I am
> not sure who I should contact therefore I am here cc-ing
> us...@infra.apache.org.
>
> I suggest to remove @dev mail list from github subscription list.
>
> Thanks,
> -Ian.
>
>
>
> On Tue, Apr 3, 2018 at 5:55 PM, Huxing Zhang <hux...@apache.org> wrote:
>
>> Hi,
>>
>> I am +1 on split the traffic of @dev list.
>>
>> The issue appears after migrating repo to ASF. I use
>> "label:asf-dubbo-dev -[github]" to filter out them. :(
>>
>> On Tue, Apr 3, 2018 at 5:06 PM, Yong Zhu <diecui1...@gmail.com> wrote:
>> > I have the same feeling.
>> >
>> > IMO, all the issue emails should be sent to iss...@dubbo.apache.org,
>> all
>>
>> +1. All issues and the comments should go there.
>>
>> > the PR emails should be sent to comm...@dubbo.apache.org. How do you
>> think?
>>
>> -1. commit@ are used when code are committed to repo, I don't think
>> PRs should go there.
>> Once a PR is accepted, a message will be sent to commit@
>>
>> My suggestion is PRs and the comments should go to issues@, or we can
>> create a new list prs@.
>>
>> > and who can help to fix this?
>> >
>> > And I think we should use github issues, and move all the Jira issues to
>> > github.
>> >
>> > 2018-04-03 16:43 GMT+08:00 Mark Thomas <ma...@apache.org>:
>> >
>> >> All,
>> >>
>> >> I've been away for just over a week and come back to find over 300
>> >> unread emails on the dev list.
>> >>
>> >> A large proportion of these messages are comments on pull requests? Is
>> >> dev@ the right list for those?
>> >>
>> >> Another large proportion appear to be comments on issues? Is dev@ the
>> >> right list for those?
>> >>
>> >> Generally, the recommendation is to split into multiple lists based on
>> >> audience rather than topic. For some projects it therefore makes sense
>> >> to have all dev related traffic going to a single list. For others,
>> >> particularly large projects, it makes sense to split the dev traffic.
>> >>
>> >> The project appears to be using GitHub issues and Jira. That is
>> >> confusing. I'd recommend that you select one issue tracker and stick
>> to it.
>>
>> There was discussion[1] on the mailing list and the community has
>> decided to use github issues.
>> My understanding is that currently JIRA is only used for GSOC ideas
>> and track existing issues prior to that decision.
>> I am +0 on migrating the existing JIRA issues to github issues.
>>
>> >>
>> >> Finally, the github issues seem to be a mix of bugs and support
>> >> questions. Is that the way the podling wants to use github issues?
>>
>> People get used to ask questions by creating an issue before joining ASF.
>> The PPMC are trying to tell users to use mailing list to ask questions
>> by leaving message on the issues, so does the website.
>> But I think it will take some time.
>>
>> >>
>> >> I have no view on what the 'right' answers to the above questions are.
>> >> I'm asking them to get the podling thinking about the issues. What, if
>> >> anything, to do about any of the above is for the podling to decide.
>> >>
>> >>
>> >> Mark
>> >>
>>
>>
>> [1] https://lists.apache.org/thread.html/c8ca0bf3bff8f0ee236567b
>> ba2a3876c4d8b91a28a94948be4cb74b8@%3Cdev.dubbo.apache.org%3E
>> --
>> Best Regards！
>> Huxing
>>
>
>