Re: Releasing with lazy consensus

[Richard Zowalla]

The commons project often releases their parent pom with lazy
consensus, for example:
https://lists.apache.org/thread/34onls4fw189smx5gjznkk8z80t3j6lc

Am Freitag, dem 01.09.2023 um 08:52 +0200 schrieb Volkan Yazıcı:
> Is such a thing possible? It is pretty common that many Java projects
> have
> multiple modules having their own release cycles. Some of these
> modules are
> miscellaneous "utilities" to support the rest of the code base.
> Common
> examples I can think of are
> 
>    - BOM project covering a dozen other projects (e.g., `log4j-bom`
> for
>    `log4j-core`, `log4j-layout-template-json`, etc.)
>    - Utilities (e.g., `log4j-changelog` used to maintain a changelog
> and
>    release notes for Java-based Logging Services projects)
> 
> `log4j-core` release takes 72 hours due to voting. Once that is done,
> waiting another 72 hours for `log4j-bom` feels like a waste of time.
> Similarly, `log4j-changelog` is an internally used tool, yet we need
> to
> publish it to Maven Central and such. Wouldn't it be possible to
> release
> such projects (e.g., `log4j-bom`, `log4j-changelog`) with lazy
> voting? That
> is, *"unless there are objections within 24 hours, I'll assume a lazy
> consensus, and release it".* Can the Release Policy
>  and/or the Voting
> Process
>  accommodate such a
> practice?



signature.asc
Description: This is a digitally signed message part

Releasing with lazy consensus

[Volkan Yazıcı]

Is such a thing possible? It is pretty common that many Java projects have
multiple modules having their own release cycles. Some of these modules are
miscellaneous "utilities" to support the rest of the code base. Common
examples I can think of are

   - BOM project covering a dozen other projects (e.g., `log4j-bom` for
   `log4j-core`, `log4j-layout-template-json`, etc.)
   - Utilities (e.g., `log4j-changelog` used to maintain a changelog and
   release notes for Java-based Logging Services projects)

`log4j-core` release takes 72 hours due to voting. Once that is done,
waiting another 72 hours for `log4j-bom` feels like a waste of time.
Similarly, `log4j-changelog` is an internally used tool, yet we need to
publish it to Maven Central and such. Wouldn't it be possible to release
such projects (e.g., `log4j-bom`, `log4j-changelog`) with lazy voting? That
is, *"unless there are objections within 24 hours, I'll assume a lazy
consensus, and release it".* Can the Release Policy
 and/or the Voting Process
 accommodate such a practice?

[jira] [Created] (COMDEV-534) 3rd party downloads not allowed by privacy policy

[Sebb (Jira)]

Sebb created COMDEV-534:
---

 Summary: 3rd party downloads not allowed by privacy policy
 Key: COMDEV-534
 URL: https://issues.apache.org/jira/browse/COMDEV-534
 Project: Community Development
  Issue Type: Bug
  Components: Projects Tool
Reporter: Sebb


The projects.a.o website relies on Google charts.

AFAIK, we don't have a privacy agreement for these, and according to the terms 
of use, they cannot be used downloaded and used locally:
https://developers.google.com/chart/interactive/faq#offline

Some possible solutions:
- use an alternative charting library that is not in conflict with the Privacy 
Policy
- ask the user's permission before making requests to such 3rd party sites; if 
the user refuses, charts and graphs cannot be displayed, but the site should 
otherwise continue to function
- find some way of proxying the requests via an ASF host that strips out all 
client-specific headers.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org