What is `[VOTE][LAZY]` and its application

[Volkan Yazıcı]

Vladimir earlier questioned the practice of `[LAZY][VOTE]`. After
encountering several other ASF projects reaching out to the same practice
and yet knowing that it is not clearly defined in the ASF release policy, I
have raised the issue first on `d...@community.apache.org`
 and
later on `bo...@apache.org`
. There I
was asked to create LEGAL-654
 and Roman Shaposhnik
(V.P., Legal Affairs) stated that *the `**[LAZY]**[VOTE]` practice is
legitimate given it is not advertised as a release for public consumption*.

>From this point of view, both `logging-parent` and `log4j-tools` qualify
for `[LAZY][VOTE]`, since we clearly indicate that the tooling is intended
for internal usage only.

Vladimir, if you have further questions and/or objections, I kindly ask you
to share them in LEGAL-654.

On Mon, Jul 3, 2023 at 1:13 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> -1, don't release, because...
>
>
> Volkan,
>
> I have downloaded the release artifact apache-log4j-tools-0.4.0.zip, and I
> fail to find the source package there.
> Would you please advise?
>
> See
>
> https://www.apache.org/legal/release-policy.html#what-must-every-release-contain
>
> >Every ASF release must contain a source package, which must be sufficient
> for a user to build and
> >test the release provided they have access to the appropriate platform and
> tools
>
> I performed unzip apache-log4j-tools-0.4.0.zip, and I find two jar files,
> LICENSE, NOTICE, and RELEASE-NOTES there.
>
> The jar files contain binary/bytecode files, and the release contains no
> signs of a source package.
>
> Please, correct me if I am wrong, but it sounds that "0.4.0 release of
> Apache Log4j Tools" violates
> "WHAT MUST EVERY ASF RELEASE CONTAIN?" policy.
>
> ---
>
> > I simplified the VOTE email to *only* include details necessary for an
> > ASF-compliant release.
>
> It is unfair to omit the link to the published binary/bytecode packages.
> For instance, if the version in maven publication was different from 0.4.0,
> then it would
> violate the ASF policy.
>
> The ASF policy does impose several MUST requirements on the released
> binary/bytecode packages, see
> https://www.apache.org/legal/release-policy.html#compiled-packages
>
> >the binary/bytecode package MUST have the same version number as the
> source release
> >and MUST only add binary/bytecode files that are the result of compiling
> that version of
> >the source code release and its dependencies.
>
> ---
>
> >Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0
>
> Could you please clarify who owns and controls the key?
> Correct me if I am wrong, however, the ASF release policy requires that
> the releases MUST be signed by Release Manager:
> https://www.apache.org/legal/release-policy.html#release-signing
>
> At the same time they say:
> https://www.apache.org/legal/release-policy.html#owned-controlled-hardware
>
> >hardware owned and controlled by the committer. That means hardware the
> committer has physical possession
> >and control of and exclusively full administrative/superuser access to.
> That's because only such hardware
> >is qualified to hold a PGP private key, and the release should be verified
> on the machine the private key lives on or on a machine as trusted as that
>
> It sounds to me that external systems, including GitHub Actions should not
> be trusted to store signing private keys.
> In other words, if the only PGP signature comes from a bot running in
> GitHub Actions,
> then it looks to me the release deviates from the ASF Release Policy.
>
> ---
>
> >This is a lazy vote to release
>
> Could you please clarify what do you mean by "This is a lazy vote to
> release"?
> The only thing coming to my mind is "lazy consensus", however I do not
> think lazy consensus
> can be used for release voting.
> The ASF policy requires that every time a member of PMC votes, they are
> REQUIRED to download all signed code
> onto their hardware and verify it:
> https://www.apache.org/legal/release-policy.html#release-approval
>
> Could you please clarify the meaning of "lazy" in both mail text and the
> subject?
>
>
> Vladimir
>

[VOTE] Move Chainsaw to dormant status

[Volkan Yazıcı]

As earlier discussions[1] indicate, Chainsaw has been lacking on
maintenance and no PMC member stepped up to perform necessary chores.
This is a vote to retire the Chainsaw by means of

- Move it to the list of dormant projects[2]
- Making it clear in its README and website that the project is not
maintained anymore
- Archive its repository[3]

Please cast your votes on this mailing list.

[ ] +1, retire the project
[ ] -1, don't retire, because...

This vote is open for 72 hours and will pass unless getting a net
negative vote count. All votes are welcome and we encourage everyone,
but only the Logging Services PMC votes are officially counted. At
least 3 +1 votes and more positive than negative votes are required.

[1] https://lists.apache.org/thread/fsykp5hxr9z0c2h85snnhnj2pq553t6q
[2] https://logging.apache.org/dormant.html
[3] https://github.com/apache/chainsaw

Re: [Discuss][VOTE] Move Chainsaw to dormant status

[Ralph Goers]

At this point in time I will abstain from voting. As far as I am concerned only 
1 vote counts - Scott’s. He has steadfastly asked that the project not be 
retired and until he positively says he will no longer maintain it I am not 
willing to override that.

I should also note that AFAIK we have never “archived” a dormant project. We 
simply change its status on the web site. That said, a read-only repo does make 
some sense for a dormant project I guess.

Ralph

> On Sep 21, 2023, at 10:00 AM, Volkan Yazıcı  wrote:
> 
> As earlier discussions[1] indicate, Chainsaw has been lacking on
> maintenance and no PMC member stepped up to perform necessary chores.
> This is a vote to retire the Chainsaw by means of
> 
> - Move it to the list of dormant projects[2]
> - Making it clear in its README and website that the project is not
> maintained anymore
> - Archive its repository[3]
> 
> Please cast your votes on this mailing list.
> 
> [ ] +1, retire the project
> [ ] -1, don't retire, because...
> 
> This vote is open for 72 hours and will pass unless getting a net
> negative vote count. All votes are welcome and we encourage everyone,
> but only the Logging Services PMC votes are officially counted. At
> least 3 +1 votes and more positive than negative votes are required.
> 
> [1] https://lists.apache.org/thread/fsykp5hxr9z0c2h85snnhnj2pq553t6q
> [2] https://logging.apache.org/dormant.html
> [3] https://github.com/apache/chainsaw

`chainsaw` vs `logging-chainsaw`

[Volkan Yazıcı]

Does anybody know the difference between these two repositories[1][2]
and why the mirroring does not work? [1] hasn't been updated since
2014.

[1] https://github.com/apache/chainsaw
[2] https://github.com/apache/logging-chainsaw

Re: `chainsaw` vs `logging-chainsaw`

[Robert Middleton]

I think #1 is a mirror of SVN(
https://svn.apache.org/repos/asf/logging/chainsaw/trunk/), while #2 is a
mirror of the gitbox repository.

-Robert

On Thu, Sep 21, 2023 at 1:59 PM Volkan Yazıcı  wrote:

> Does anybody know the difference between these two repositories[1][2]
> and why the mirroring does not work? [1] hasn't been updated since
> 2014.
>
> [1] https://github.com/apache/chainsaw
> [2] https://github.com/apache/logging-chainsaw
>