Hi,
I have another idea that might simplify the mess of dealing with
PKG_RELEASE handling.
1. we use AUTORELEASE for all packages in master
2. when creating a release branch, all PKG_RELEASE lines are changed to
something like 22.03-1
3. we write a script that can automatically edit a series
I know that autorelease has introduced some problems but it would be
good to keep a way to automatically bump releases. Every second we
could save from devs/maintainers is more time to do really useful
things.
Can't we have a central way to publish the "official list of package
releases''? It coul
Hi,
> I agree that this increases maintenance burden but I believe that a
> CI side solution for those
> conflicting-because-of-deviating-PKG_RELEASE situations would be the
> better course of action.
I would also like to drop the AUTORELEASE feature. I would like to have
a specific version in th
On Mon, Nov 7, 2022 at 10:29 AM Jo-Philipp Wich wrote:
>
> Hi,
>
> > The AUTORELEASE has been a nice feature from the package PR maintenance
> > perspective.
> >
> > Earlier there was constant trouble with concurrent PRs for the same package
> > having the same PKG_RELEASE bump, or the maintainer
Hi,
> The AUTORELEASE has been a nice feature from the package PR maintenance
> perspective.
>
> Earlier there was constant trouble with concurrent PRs for the same package
> having the same PKG_RELEASE bump, or the maintainer doing a small change with
> a bump while there was an open PR with the
Hi,
yes, please kill it. The $(AUTORELEASE) option does not work for sources
without Git history, it produces different results depending on the history,
it causes package bumps for even trivial cosmetic fixes.
It can also lead to situations where packages on different branches end up
with the ex
Hannu Nyman writes:
> The AUTORELEASE has been a nice feature from the package PR
> maintenance perspective.
>
> Earlier there was constant trouble with concurrent PRs for the same
> package having the same PKG_RELEASE bump, or the maintainer doing a
> small change with a bump while there was an
On Mon, Nov 7, 2022 at 9:41 AM Josef Schlehofer
wrote:
>
>
> On 06. 11. 22 21:22, Hannu Nyman wrote:
> > Paul Spooren kirjoitti 6.11.2022 klo 18.15:
> >> While I initially thought that $(AUTORELEASE) would be a nice feature
> >> to avoid the standard review comment “Please bump the PKG_RELEASE”,
>
On 06. 11. 22 17:15, Paul Spooren wrote:
Hi,
While I initially thought that $(AUTORELEASE) would be a nice feature to avoid
the standard review comment “Please bump the PKG_RELEASE”, it turned into a
massive increase of bandwidth usage: Every checkout of openwrt.git and package
feeds needs t
On 06. 11. 22 21:22, Hannu Nyman wrote:
Paul Spooren kirjoitti 6.11.2022 klo 18.15:
While I initially thought that $(AUTORELEASE) would be a nice feature
to avoid the standard review comment “Please bump the PKG_RELEASE”,
it turned into a massive increase of bandwidth usage: Every checkout
of
Paul Spooren kirjoitti 6.11.2022 klo 18.15:
While I initially thought that $(AUTORELEASE) would be a nice feature to avoid
the standard review comment “Please bump the PKG_RELEASE”, it turned into a
massive increase of bandwidth usage: Every checkout of openwrt.git and package
feeds needs to b
> Le 6 nov. 2022 à 17:15, Paul Spooren a écrit :
>
> Hi,
>
> While I initially thought that $(AUTORELEASE) would be a nice feature to
> avoid the standard review comment “Please bump the PKG_RELEASE”, it turned
> into a massive increase of bandwidth usage: Every checkout of openwrt.git and
Hi,
While I initially thought that $(AUTORELEASE) would be a nice feature to avoid
the standard review comment “Please bump the PKG_RELEASE”, it turned into a
massive increase of bandwidth usage: Every checkout of openwrt.git and package
feeds needs to be a full clone instead of a shallow one t
13 matches
Mail list logo
