On 01. 03. 21 21:29, Michael J Gruber wrote:
But (if this hasn't changed lately) I cannot fork my own dist-git repo and file
a PR, so I cannot use that to communicate my intentions to a provenpackager nor
to my co-maintainers.
You can. Not just lately, you always could, since Pull Requests
So, you list 3 typical reasons why packages in rawhide FTBFS and 2 existing
policies which are meant to prevent 2 of these 3 reasons if packagers followed
these policies. And you want these policies to be enforced technically
What I am missing is:
- A viable suggestion on how to prevent the
Jonathan Wakely wrote:
> How do you get that directly from koji in a script?
>
> Is it as easy as a single git command to check if rawhide and
> rawhide-build are the same ref?
>
> It looks to me like I need to parse the build ID from the output of
> "koji latest-build " and then use "koji
On 08/02/21 10:14 -0800, Kevin Fenzi wrote:
Is there really a need for a rawhide-build branch?
What if we just pushed a tag for the commit that built after the build
finishes in koji?
In an earlier reply I did say a tag would also work.
To me, a branch ref seems more natural than a tag that
On 08/02/21 16:28 +0100, Kevin Kofler via devel wrote:
Jonathan Wakely wrote:
You've completely misunderstood the suggestion.
No, sorry, I understood it completely. I think that you are the one who
completely misunderstood my objection, and also missed the point of the
original post. Let me
Is there really a need for a rawhide-build branch?
What if we just pushed a tag for the commit that built after the build
finishes in koji?
We already have this information in pagure...
for example, look at
https://src.fedoraproject.org/rpms/ansible/c/e89035e0fbd49cd2569dc923325e373bee43fbad
Jonathan Wakely wrote:
> You've completely misunderstood the suggestion.
No, sorry, I understood it completely. I think that you are the one who
completely misunderstood my objection, and also missed the point of the
original post. Let me explain:
> I'm suggesting that everybody pushes to
On 04/02/21 05:03 +0100, Kevin Kofler via devel wrote:
Dominik 'Rathann' Mierzejewski wrote:
On Wednesday, 03 February 2021 at 14:29, Kevin Kofler via devel wrote:
But it means that provenpackagers who want to bump and rebuild have to
actually manually look at another branch (rawhide-build).
On 03/02/21 14:29 +0100, Kevin Kofler via devel wrote:
Jonathan Wakely wrote:
Instead of force pushing or reverting anything in the rawhide branch,
why not just have two branches?
Maintainers commit to one branch, and if the build is successful that
branch is automatically merged (as a
Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 03 February 2021 at 14:29, Kevin Kofler via devel wrote:
>> But it means that provenpackagers who want to bump and rebuild have to
>> actually manually look at another branch (rawhide-build).
>
> No, why would they need to do that?
Because
On 03. 02. 21 14:35, Dominik 'Rathann' Mierzejewski wrote:
On Wednesday, 03 February 2021 at 14:24, Miro Hrončok wrote:
On 03. 02. 21 14:08, Dominik 'Rathann' Mierzejewski wrote:
On Wednesday, 03 February 2021 at 12:47, Jonathan Wakely wrote:
On 30/01/21 19:19 +0100, Kevin Kofler via devel
On Wednesday, 03 February 2021 at 14:29, Kevin Kofler via devel wrote:
> Jonathan Wakely wrote:
> > Instead of force pushing or reverting anything in the rawhide branch,
> > why not just have two branches?
> >
> > Maintainers commit to one branch, and if the build is successful that
> > branch is
On Wednesday, 03 February 2021 at 14:24, Miro Hrončok wrote:
> On 03. 02. 21 14:08, Dominik 'Rathann' Mierzejewski wrote:
> > On Wednesday, 03 February 2021 at 12:47, Jonathan Wakely wrote:
> > > On 30/01/21 19:19 +0100, Kevin Kofler via devel wrote:
> > > > clime wrote:
> > > > > So if some other
Jonathan Wakely wrote:
> Instead of force pushing or reverting anything in the rawhide branch,
> why not just have two branches?
>
> Maintainers commit to one branch, and if the build is successful that
> branch is automatically merged (as a fast-forward merge) to a
> "rawhide-build" branch.
>
>
On 03. 02. 21 14:08, Dominik 'Rathann' Mierzejewski wrote:
On Wednesday, 03 February 2021 at 12:47, Jonathan Wakely wrote:
On 30/01/21 19:19 +0100, Kevin Kofler via devel wrote:
clime wrote:
So if some other maintainer pushes his work to the server meanwhile,
this will just delete his work?
On Wednesday, 03 February 2021 at 12:47, Jonathan Wakely wrote:
> On 30/01/21 19:19 +0100, Kevin Kofler via devel wrote:
> > clime wrote:
> > > So if some other maintainer pushes his work to the server meanwhile,
> > > this will just delete his work? Or what's the idea here?
> >
> > I guess the
On 30/01/21 19:19 +0100, Kevin Kofler via devel wrote:
clime wrote:
So if some other maintainer pushes his work to the server meanwhile,
this will just delete his work? Or what's the idea here?
I guess the safe thing to do would be to wait and see whether that commit
also fails to build
- Original Message -
> From: "Fabio Valentini"
> To: "Development discussions related to Fedora"
>
> Sent: Monday, January 25, 2021 4:43:21 PM
> Subject: Policy proposal (draft): Don't push knowingly broken or
> work-in-progress work to dist git
>
> On Mon, Jan 25, 2021 at 4:37 PM
Petr Pisar wrote:
> Technically you can make multiple builds from the very same branch and
> commit. And some of the builds can pass and some fail.
But only one of those will be the CI build used to make the decision.
So all that is needed is to ensure that we cannot have a non-CI build that
V Fri, Jan 29, 2021 at 06:52:29PM +0100, Kevin Kofler via devel napsal(a):
> I still think that the best way to do CI would be what I already suggested
> at least once:
> 1. maintainer pushes the commit to the branch "rawhide" or "fn"
> 2. a quick synchronous commit hook validates obvious things
clime wrote:
> So if some other maintainer pushes his work to the server meanwhile,
> this will just delete his work? Or what's the idea here?
I guess the safe thing to do would be to wait and see whether that commit
also fails to build (i.e., if the CI build fails, check whether the built
On Sat, 30 Jan 2021 at 01:28, Kevin Kofler via devel
wrote:
>
> Michael Catanzaro wrote:
> > Alternative: use automated reverts instead of force pushes, and don't
> > worry about maintaining a clean history.
>
> Sure, it is possible to make an implementation with lower quality of
> implementation
Kevin Kofler via devel writes:
> Matthew Miller wrote:
>> Yeah, honestly, this is also a pretty serious hardship for the long tail
>> of people maintaining a handful of infrequently updated packages. I'm
>> hugely in favor of not checking in work in progress on the main or release
>> branches,
Michael Catanzaro wrote:
> Alternative: use automated reverts instead of force pushes, and don't
> worry about maintaining a clean history.
Sure, it is possible to make an implementation with lower quality of
implementation with possibly less work, by omitting the force pushes and the
smart
On Fri, Jan 29, 2021 at 6:52 pm, Kevin Kofler via devel
wrote:
6. if the CI build fails, the branch "rawhide" or "fn" is
automatically
force-pushed back to the last commit that successfully built, and
an
e-mail notification is sent. Force-pushing is safe in that case
because
there
Matthew Miller wrote:
> Yeah, honestly, this is also a pretty serious hardship for the long tail
> of people maintaining a handful of infrequently updated packages. I'm
> hugely in favor of not checking in work in progress on the main or release
> branches, but let's not make more steps.
I still
On Wed, 2021-01-27 at 10:25 -0800, Kevin Fenzi wrote:
> On Tue, Jan 26, 2021 at 06:42:58PM -0800, Michel Alexandre Salim
> wrote:
> > On Mon, 2021-01-25 at 11:40 -0500, Matthew Miller wrote:
> > > On Mon, Jan 25, 2021 at 04:43:21PM +0100, Fabio Valentini wrote:
> > > > But that would involve at
On Tue, Jan 26, 2021 at 06:42:58PM -0800, Michel Alexandre Salim wrote:
> On Mon, 2021-01-25 at 11:40 -0500, Matthew Miller wrote:
> > On Mon, Jan 25, 2021 at 04:43:21PM +0100, Fabio Valentini wrote:
> > > But that would involve at least six new steps that would've to be
> > > automated: 1)
On Wed, Jan 27, 2021 at 01:26:17PM +0100, Petr Menšík wrote:
> What about ability to opt-in into %prep checking on push?
> Could we add some new rules to gating.yaml for example, allowing few
> checks on push?
If it's something that runs locally before accepting the commit, I think
that would be
On 1/27/21 2:22 PM, Miro Hrončok wrote:
> On 27. 01. 21 13:45, Petr Menšík wrote:
>> I think one reason against maintainer's pull requests is poor tooling to
>> work with them. Filled fedpkg proposal to include ability to fork and
>> add personal fork to current repository or add when cloning
On 27. 01. 21 13:45, Petr Menšík wrote:
I think one reason against maintainer's pull requests is poor tooling to
work with them. Filled fedpkg proposal to include ability to fork and
add personal fork to current repository or add when cloning [1].
I think current way discourages its use, because
I think one reason against maintainer's pull requests is poor tooling to
work with them. Filled fedpkg proposal to include ability to fork and
add personal fork to current repository or add when cloning [1].
I think current way discourages its use, because too many manual steps
have to be done
What about ability to opt-in into %prep checking on push?
Could we add some new rules to gating.yaml for example, allowing few
checks on push?
Most of package I manage are tiny or small, prep check should not take
longer than 10s on most of them. I made mistake of omitting patch our
source file
On Tue, Jan 26, 2021 at 09:52:59AM -0500, Alexander Scheel wrote:
> > Well, I understand your sentiment against mass spec changes, but there are
> > cases, where it currently cannot be avoided (e.-g. when a targeted mass
> > rebuild
> > is needed for a soname bump). W.g. when we update Python
On Mon, 2021-01-25 at 11:40 -0500, Matthew Miller wrote:
> On Mon, Jan 25, 2021 at 04:43:21PM +0100, Fabio Valentini wrote:
> > But that would involve at least six new steps that would've to be
> > automated: 1) Creating a fork on src.fp.o (plus error handling
> > around
> > already existing
Dne 26. 01. 21 v 18:32 Zbigniew Jędrzejewski-Szmek napsal(a):
On Tue, Jan 26, 2021 at 03:59:18PM +, Jonathan Wakely wrote:
On 25/01/21 19:58 +0100, Miro Hrončok wrote:
On 25. 01. 21 19:32, Robbie Harwood wrote:
It seems to me that this problem would be better solved by making
rebuilds
On Tue, Jan 26, 2021 at 03:59:18PM +, Jonathan Wakely wrote:
> On 25/01/21 19:58 +0100, Miro Hrončok wrote:
> >On 25. 01. 21 19:32, Robbie Harwood wrote:
> >>It seems to me that this problem would be better solved by making
> >>rebuilds smarter. Instead of building tip of dist-git (which
On 26/01/21 03:12 +0100, Kevin Kofler via devel wrote:
Miro Hrončok wrote:
1. Untested changes
Packager pushes a "simple update" to dist git without checking if it even
builds. It doesn't. Packager has no time to fix this, so they move on for
now. Or they submit a build but never check if it
On 25/01/21 11:40 -0500, Matthew Miller wrote:
On Mon, Jan 25, 2021 at 04:43:21PM +0100, Fabio Valentini wrote:
But that would involve at least six new steps that would've to be
automated: 1) Creating a fork on src.fp.o (plus error handling around
already existing forks), 2) Cloning the fork
On 25/01/21 19:58 +0100, Miro Hrončok wrote:
On 25. 01. 21 19:32, Robbie Harwood wrote:
It seems to me that this problem would be better solved by making
rebuilds smarter. Instead of building tip of dist-git (which might
never have been build), rebuild the last thing that *was* successfully
On 25/01/21 13:42 -0500, Stephen John Smoogen wrote:
On Mon, 25 Jan 2021 at 13:30, Zbigniew Jędrzejewski-Szmek
wrote:
On Mon, Jan 25, 2021 at 07:19:45PM +0100, Miro Hrončok wrote:
> On 25. 01. 21 19:03, Zbigniew Jędrzejewski-Szmek wrote:
> >On Mon, Jan 25, 2021 at 03:59:43PM +0100, Miro
On 26. 01. 21 15:52, Alexander Scheel wrote:
Well, I understand your sentiment against mass spec changes, but there are
cases, where it currently cannot be avoided (e.-g. when a targeted mass rebuild
is needed for a soname bump). W.g. when we update Python from 3.9 to 3.10 we
will need to
On Tue, Jan 26, 2021 at 4:45 AM Miro Hrončok wrote:
>
> On 26. 01. 21 3:12, Kevin Kofler via devel wrote:
> > Miro Hrončok wrote:
> >> 1. Untested changes
> >>
> >> Packager pushes a "simple update" to dist git without checking if it even
> >> builds. It doesn't. Packager has no time to fix this,
On Tue, Jan 26, 2021 at 01:53:53PM +, Richard W.M. Jones wrote:
> On Tue, Jan 26, 2021 at 06:58:28AM -0500, Colin Walters wrote:
> > I've linked my
> > https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md
> > plan a few times.
>
> It's an
On Tue, Jan 26, 2021 at 06:58:28AM -0500, Colin Walters wrote:
> I've linked my
> https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md
> plan a few times.
It's an interesting proposal. I do have a couple of questions
or points of view though:
How
On Tue, 26 Jan 2021 at 07:00, Colin Walters wrote:
>
>
> On Tue, Jan 26, 2021, at 6:27 AM, Richard W.M. Jones wrote:
> > On Tue, Jan 26, 2021 at 03:12:50AM +0100, Kevin Kofler via devel wrote:
> > > IMHO, the real issue is the one Robbie Harwood pointed out: It should
> NOT be
> > > a common
On Tue, Jan 26, 2021, at 6:27 AM, Richard W.M. Jones wrote:
> On Tue, Jan 26, 2021 at 03:12:50AM +0100, Kevin Kofler via devel wrote:
> > IMHO, the real issue is the one Robbie Harwood pointed out: It should NOT
> > be
> > a common occurrence for a provenpackager to have to rebuild a package,
On Tue, Jan 26, 2021 at 03:12:50AM +0100, Kevin Kofler via devel wrote:
> IMHO, the real issue is the one Robbie Harwood pointed out: It should NOT be
> a common occurrence for a provenpackager to have to rebuild a package, and
> in particular, provenpackagers should NOT do scripted mass changes.
On Mon, Jan 25, 2021 at 10:35:44AM -0500, Stephen Gallagher wrote:
> On Mon, Jan 25, 2021 at 10:31 AM Miro Hrončok wrote:
> >
> > On 25. 01. 21 16:19, Stephen Gallagher wrote:
> > > I'm fully in favor of this and I'd really like to see us add some
> > > degree of CI gating to support it.
> >
> >
On 26. 01. 21 3:12, Kevin Kofler via devel wrote:
Miro Hrončok wrote:
1. Untested changes
Packager pushes a "simple update" to dist git without checking if it even
builds. It doesn't. Packager has no time to fix this, so they move on for
now. Or they submit a build but never check if it
Miro Hrončok wrote:
> 1. Untested changes
>
> Packager pushes a "simple update" to dist git without checking if it even
> builds. It doesn't. Packager has no time to fix this, so they move on for
> now. Or they submit a build but never check if it actually built.
> Provenpackagers who need to
On Mon, Jan 25, 2021 at 03:59:43PM +0100, Miro Hrončok wrote:
> Hello,
>
...snip...
>
>
> Before I try to word it more carefully I'd like to hear some feedback on
> this. What do you think?
In general I think it's a good policy, but we should make sure it's
worded in a nice way. ie, please
Miro Hrončok writes:
> On 25. 01. 21 19:32, Robbie Harwood wrote:
>> Miro Hrončok writes:
>>
>>> Before I try to word it more carefully I'd like to hear some feedback
>>> on this. What do you think?
>>
>> It seems to me that this problem would be better solved by making
>> rebuilds smarter.
On Mon, 25 Jan 2021 at 13:58, Zbigniew Jędrzejewski-Szmek
wrote:
> On Mon, Jan 25, 2021 at 01:42:17PM -0500, Stephen John Smoogen wrote:
> > On Mon, 25 Jan 2021 at 13:30, Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl>
> > wrote:
>
> > >
> > If this was some other code which was tied into
On 25. 01. 21 19:32, Robbie Harwood wrote:
Miro Hrončok writes:
Before I try to word it more carefully I'd like to hear some feedback
on this. What do you think?
I'm struggling to understand what you think this will accomplish.
I want packagers to have a documented "dos and don'ts" of
On Mon, Jan 25, 2021 at 01:42:17PM -0500, Stephen John Smoogen wrote:
> On Mon, 25 Jan 2021 at 13:30, Zbigniew Jędrzejewski-Szmek
> wrote:
>
> > On Mon, Jan 25, 2021 at 07:19:45PM +0100, Miro Hrončok wrote:
> > > On 25. 01. 21 19:03, Zbigniew Jędrzejewski-Szmek wrote:
> > > >On Mon, Jan 25, 2021
On Mon, 25 Jan 2021 at 13:30, Zbigniew Jędrzejewski-Szmek
wrote:
> On Mon, Jan 25, 2021 at 07:19:45PM +0100, Miro Hrončok wrote:
> > On 25. 01. 21 19:03, Zbigniew Jędrzejewski-Szmek wrote:
> > >On Mon, Jan 25, 2021 at 03:59:43PM +0100, Miro Hrončok wrote:
> > >>1. Packagers MUST NOT push changes
On 25. 01. 21 19:29, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jan 25, 2021 at 07:19:45PM +0100, Miro Hrončok wrote:
On 25. 01. 21 19:03, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jan 25, 2021 at 03:59:43PM +0100, Miro Hrončok wrote:
1. Packagers MUST NOT push changes that are not
Miro Hrončok writes:
> Before I try to word it more carefully I'd like to hear some feedback
> on this. What do you think?
I'm struggling to understand what you think this will accomplish.
Leaving aside ideological disagreement about the nature of rawhide (I
don't think rawhide should be
On Mon, Jan 25, 2021 at 07:19:45PM +0100, Miro Hrončok wrote:
> On 25. 01. 21 19:03, Zbigniew Jędrzejewski-Szmek wrote:
> >On Mon, Jan 25, 2021 at 03:59:43PM +0100, Miro Hrončok wrote:
> >>1. Packagers MUST NOT push changes that are not considered ready to
> >>be built and shipped at the time of
On 25. 01. 21 19:03, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jan 25, 2021 at 03:59:43PM +0100, Miro Hrončok wrote:
1. Packagers MUST NOT push changes that are not considered ready to
be built and shipped at the time of the push. Using Pull Requests
(clearly marked as not ready to be merged)
On Mon, Jan 25, 2021 at 03:59:43PM +0100, Miro Hrončok wrote:
> 1. Packagers MUST NOT push changes that are not considered ready to
> be built and shipped at the time of the push. Using Pull Requests
> (clearly marked as not ready to be merged) is a better place to
> present/save changes that are
On Mon, Jan 25, 2021 at 04:43:21PM +0100, Fabio Valentini wrote:
> But that would involve at least six new steps that would've to be
> automated: 1) Creating a fork on src.fp.o (plus error handling around
> already existing forks), 2) Cloning the fork instead of the main repo,
> 3) Automatically
On Mon, Jan 25, 2021 at 4:37 PM Stephen Gallagher wrote:
>
> On Mon, Jan 25, 2021 at 10:31 AM Miro Hrončok wrote:
> >
> > On 25. 01. 21 16:19, Stephen Gallagher wrote:
> > > I'm fully in favor of this and I'd really like to see us add some
> > > degree of CI gating to support it.
> >
> > Note
On Mon, Jan 25, 2021 at 10:31 AM Miro Hrončok wrote:
>
> On 25. 01. 21 16:19, Stephen Gallagher wrote:
> > I'm fully in favor of this and I'd really like to see us add some
> > degree of CI gating to support it.
>
> Note that unfortunately CI gating happens too late. It has no capability to
>
On 25. 01. 21 16:19, Stephen Gallagher wrote:
I'm fully in favor of this and I'd really like to see us add some
degree of CI gating to support it.
Note that unfortunately CI gating happens too late. It has no capability to
block commits that fail to build, because it only tests successful
On Mon, Jan 25, 2021 at 10:00 AM Miro Hrončok wrote:
>
> Hello,
>
> When we work on rebuilding Python packages with new Python version and when
> other provenpackagers rebuild multiple packages at once, I've seen several
> problems with packages failing to build from source and/or creating
Hello,
When we work on rebuilding Python packages with new Python version and when
other provenpackagers rebuild multiple packages at once, I've seen several
problems with packages failing to build from source and/or creating unexpected
breakage in rawhide when built. Usually, some of the
68 matches
Mail list logo
