On Sun, Apr 23, 2017 at 11:43 AM, Roman Shaposhnik
wrote:
> I don't
> think releasing something out of ASF that hasn't had at least 3 binding
votes
> would be advisable.
AFAIK, projects "publish" to
https://repository.apache.org/content/groups/snapshots/org/apache as part
of CI build without vett
On Sat, Apr 22, 2017 at 7:24 PM, Niclas Hedhman wrote:
> On Sun, Apr 23, 2017 at 8:46 AM, Roman Shaposhnik
> wrote:
>
>>
>> I'm starting to wonder whether the real solution here should be along the
>> lines
>> of what a board would do to a TLP if its active PMC shrinks to less
>> than 3 people.
>
On Sun, Apr 23, 2017 at 8:46 AM, Roman Shaposhnik
wrote:
>
> I'm starting to wonder whether the real solution here should be along the
> lines
> of what a board would do to a TLP if its active PMC shrinks to less
> than 3 people.
That will inevitable lead to definition of "what is active" and t
John,
thanks for pointing me to the issue. I argue against Marvin on it, based on
"this is a tool" that is made conveniently available for those who are not
paranoid.
NOTICE; Ok, let's rename the file.
NOTICES-POSSIBLY-NEEDED-FOR-BINARY-DISTRIBUTION
Ok?
On Sun, Apr 23, 2017 at 8:01 AM, John D.
I was just trying to get something moving. Glad to see it.
+1 (binding)
> On Apr 22, 2017, at 6:24 PM, Luciano Resende wrote:
>
> Sure, I am ok having this become blocker if its still an issue on the next
> release.
>
> Here is my +1 the .
>
>> On Sat, Apr 22, 2017 at 4:49 PM John D. Ament
Sure, I am ok having this become blocker if its still an issue on the next
release.
Here is my +1 the .
On Sat, Apr 22, 2017 at 4:49 PM John D. Ament wrote:
> In general, the preference is to report the non-blocking issue, and confirm
> the podling has it entered into their bug tracker. Then t
On Sat, Apr 22, 2017 at 5:14 PM, John D. Ament wrote:
> On Sat, Apr 22, 2017 at 8:10 PM Ted Dunning wrote:
>
>> Another solution is to do back door politicking where you contact IPMC
>> members individually and ask them to take a look. Start with members who
>> have voted on Mahout releases in th
On Sat, Apr 22, 2017 at 10:02 AM, Julian Hyde wrote:
> I agree that lack of IPMC votes is a problem. I don’t think that lowering the
> bar to making a release is the solution.
+1 to that.
> I wish that each IPMC member would personally commit to voting on two release
> candidates per year. Ther
On Sat, Apr 22, 2017 at 8:10 PM Ted Dunning wrote:
> Another solution is to do back door politicking where you contact IPMC
> members individually and ask them to take a look. Start with members who
> have voted on Mahout releases in the past and be specific about what you
> would like them do an
On Sat, Apr 22, 2017 at 11:27 AM, Joe Schaefer wrote:
> Your proposal violates foundation policy on releases and is therefore a
> nonstarter. The ipmc isn't empowered to restructure release policy.
>
Specifically, the problem Joe is pointing out is that three actual PMC
members are required to
Another solution is to do back door politicking where you contact IPMC
members individually and ask them to take a look. Start with members who
have voted on Mahout releases in the past and be specific about what you
would like them do and provide links to artifacts and discussions to make
the job
On Sat, Apr 22, 2017 at 7:57 AM Niclas Hedhman wrote:
> On Sat, Apr 22, 2017 at 7:25 PM, John D. Ament
> wrote:
> >
> > On Sat, Apr 22, 2017 at 6:41 AM Niclas Hedhman
> wrote:
> >
> > > Note on gradle-wrapper.jar,
>
> > Agreed, and this is mostly my argument as well. However, in *nix the JAR
>
In general, the preference is to report the non-blocking issue, and confirm
the podling has it entered into their bug tracker. Then they accept
the +1. We don't generally wait for a code change to be made, but would
block the next release if these issues are not addressed. I personally
want to u
I will too, and then you will have two binding votes in the affirmative.
> On Apr 22, 2017, at 12:34 PM, Luciano Resende wrote:
>
>> On Sat, Apr 22, 2017 at 12:14 PM, Pat Ferrel wrote:
>>
>> But is it worth doing yet another podling RC and release vote?
>>
>
>> If it is, please vote -1, at
On Sat, Apr 22, 2017 at 12:14 PM, Pat Ferrel wrote:
> But is it worth doing yet another podling RC and release vote?
>
> If it is, please vote -1, at least we won’t be left waiting and we thank
> you for being the one who took a look either way.
>
> We are just trying to move, out if possible or
But is it worth doing yet another podling RC and release vote?
If it is, please vote -1, at least we won’t be left waiting and we thank you
for being the one who took a look either way.
We are just trying to move, out if possible or iterate if not. These issues
have not changed from the curren
I would feel ok voting positively once these are fixed in master.
On Tue, Apr 18, 2017 at 1:00 PM, Donald Szeto wrote:
> Hi Luciano,
>
> Thanks for your review. I will file JIRAs regarding these files. They are
> project build files and documentation.
>
> Regards,
> Donald
>
> On Mon, Apr 17, 20
There have been no binding votes, thanks.
On Apr 22, 2017, at 11:31 AM, Joe Schaefer wrote:
How many binding votes do you need at this point?
On Wed, Apr 19, 2017 at 12:34 PM Pat Ferrel wrote:
> +1 non-binding
>
> Next release we could exclude the doc site. Do build files like .sbt
> requir
How many binding votes do you need at this point?
On Wed, Apr 19, 2017 at 12:34 PM Pat Ferrel wrote:
> +1 non-binding
>
> Next release we could exclude the doc site. Do build files like .sbt
> require licenses? I suppose it can be done in comments. But again can we
> push to next release?
>
> Can
Your proposal violates foundation policy on releases and is therefore a
nonstarter. The ipmc isn't empowered to restructure release policy.
That said, talk to your project mentors about nominating competent release
managers and others participating constructively in the vetting process at
the pod
How many binding votes do you lack?
On Sat, Apr 22, 2017 at 3:40 AM Niclas Hedhman wrote:
> The third RC is placed before the Incubator and hoping to get through the
> door.
>
> Any takers?
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>
While I agree, asking is not enforcing. This would add enforcement that would
allow the IPMC to function but have an enforceable clause that also does not
allow it to roadblock by neglect.
Plus about 1/2 the reason I bring this up is trying to get more votes on
PredictionIO :-)
On Apr 22, 201
Incorrect. These people I'm talking about are already voting on (their
own) releases, we just fail to count their votes as binding because we are
anally retentitive about our own status.
On Sat, Apr 22, 2017 at 1:41 PM Julian Hyde wrote:
> Growing the IPMC is of no use if the members don’t show
Growing the IPMC is of no use if the members don’t show up and vote.
The IPMC performs an important gatekeeper role, ensuring that podling releases
are of sufficient quality to bear the “Apache (Incubating)” stamp. In my view,
all IPMC members have a duty to help with that gatekeeping role. If
That works if human nature is not involved and would still produce the same
affect so I’d second your request in any case.
However human nature is involved and my proposal would at least guarantee that
human nature could not hold innocent projects hostage. BTW notice the include
vote request,
The traditional response to this issue is to grow the ipmc to incorporate
more podling committers.
On Sat, Apr 22, 2017 at 1:02 PM Julian Hyde wrote:
> I agree that lack of IPMC votes is a problem. I don’t think that lowering
> the bar to making a release is the solution.
>
> I wish that each IP
I agree that lack of IPMC votes is a problem. I don’t think that lowering the
bar to making a release is the solution.
I wish that each IPMC member would personally commit to voting on two release
candidates per year. There are so many members of the IPMC that this would
easily cover all of the
Probably the wrong place for this but…
What do people think about a governance change for approving releases through
the IPMC to wit:
A week of no vote activity over the release proposal of a podling should be
considered a passing vote. In other words the IPMC is to become a vetoing group.
I p
On Sat, Apr 22, 2017 at 7:25 PM, John D. Ament
wrote:
>
> On Sat, Apr 22, 2017 at 6:41 AM Niclas Hedhman wrote:
>
> > Note on gradle-wrapper.jar,
> Agreed, and this is mostly my argument as well. However, in *nix the JAR
> will get downloaded automatically if not present. On windows, you need
On Sat, Apr 22, 2017 at 6:41 AM Niclas Hedhman wrote:
> Note on gradle-wrapper.jar,
> For source releases, we expect the project to be buildable by the user. The
> Gradle wrapper is the easiest way to make that happen. It (together with
> the gradlew and gradlew.bat scripts) ensures that that the
Saturday, April 22, 2017, 12:41:23 PM, Niclas Hedhman wrote:
> Note on gradle-wrapper.jar,
> For source releases, we expect the project to be buildable by the user. The
> Gradle wrapper is the easiest way to make that happen. It (together with
> the gradlew and gradlew.bat scripts) ensures that th
Note on gradle-wrapper.jar,
For source releases, we expect the project to be buildable by the user. The
Gradle wrapper is the easiest way to make that happen. It (together with
the gradlew and gradlew.bat scripts) ensures that that the build will be
the same, and not suffer from different Gradle ve
Sorry but -1 due to misnamed package and binary content.
- No "incubating" / "incubator" in package name
- JAR files are present in the source release (gradle-wrapper.jar)
- Ideally the expanded package would include "apache" in the folder, not a
big deal.
- DISCLAIMER present
Your NOTICE seems w
The third RC is placed before the Incubator and hoping to get through the
door.
Any takers?
Cheers
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
34 matches
Mail list logo