On Mon, Dec 11, 2023 at 08:28:31AM -0500, Stephen Gallagher wrote:
>
> While I generally agree that a merge request is a more polite and
> elegant solution, if a package is listed as FTBFS (having had a bug
> automatically opened) and some reasonable amount of time (two, three
> weeks?) has
On Sun, Dec 10, 2023 at 9:49 PM Gary Buhrmaster
wrote:
...
>
> FTBFS issues are, admittedly, complicated, but
> such updates SHOULD be via a PR. If a PP wants
> to claim they cannot follow that process, they need
> to demonstrate that a particular packager is not
> responsive (there is a process
On Sun, Dec 10, 2023 at 5:39 PM Sérgio Basto wrote:
> Maybe we should have a flag in the src.fp.o package for the maintainer
> to request a PR before committing to have a window for review, or like
> me, the maintainer would like to not be bothered with things that
> proven package can do by
On Thu, 2023-12-07 at 11:41 +0100, Michal Schorm wrote:
> On Thu, Dec 7, 2023 at 11:21 AM Florian Weimer
> wrote:
> > Asking individual maintainers for trivial changes does not scale.
> > The
> > alternative would be not to address FTBFS and other build issues,
> > maybe
> > file bugs, and rely
On Thu, Dec 7, 2023 at 3:26 AM Michal Schorm wrote:
> I'd advise to create PR - wait week or 2,
> if left without response - create BZ for the specific PR as not
> everyone watches PRs and PR notifications, and wait week or two,
> if left without response - send a direct mail to the package
Am 02.12.23 um 09:46 schrieb Michal Schorm:
In my experience through the years, I've found very little proven
packagers that would work in what *I would see* as the right way.
I fully agree with you but I wanted to mention Miro + the Python team. From my
experience in the Python packaging
On Thu, Dec 7, 2023 at 11:21 AM Florian Weimer wrote:
> Asking individual maintainers for trivial changes does not scale. The
> alternative would be not to address FTBFS and other build issues, maybe
> file bugs, and rely on active maintainers instead.
The alternative we want to achieve is:
(1)
On Tue, Dec 5, 2023 at 11:36 AM Daniel P. Berrangé wrote:
> IMHO all changes should be opened as merge requests in pagure. This gives
> the regular package maintainers a window of opportunity to review the
> change before it is merged. If there's no response from the package
> maintainer after a
* Kevin Kofler via devel:
> Michael J Gruber wrote:
>> I am sick of this. Really. I am so sick of this way of stomping on each
>> others' feet.
>
> My pet peeve is provenpackagers or comaintainers who add unwanted
> automagic (autorelease, autosetup, autochangelog) to my packages. I do
> not want
Richard W.M. Jones venit, vidit, dixit 2023-12-05 12:03:36:
> On Tue, Dec 05, 2023 at 10:35:35AM +, Daniel P. Berrangé wrote:
> > On Tue, Dec 05, 2023 at 11:18:57AM +0100, Vít Ondruch wrote:
> >
> > [snip]
> >
> > > Granted, these are dissimilar to initial Michaels's issue. But how can I
>
On Tue, Dec 05, 2023 at 10:35:35AM +, Daniel P. Berrangé wrote:
> On Tue, Dec 05, 2023 at 11:18:57AM +0100, Vít Ondruch wrote:
>
> [snip]
>
> > Granted, these are dissimilar to initial Michaels's issue. But how can I be
> > sure that if I touch some of the packages, I won't be told that they
On Tue, Dec 05, 2023 at 11:18:57AM +0100, Vít Ondruch wrote:
[snip]
> Granted, these are dissimilar to initial Michaels's issue. But how can I be
> sure that if I touch some of the packages, I won't be told that they were in
> such state for purpose?
IMHO all changes should be opened as merge
Dne 05. 12. 23 v 5:56 Jason Tibbitts napsal(a):
Kevin Kofler via devel writes:
My pet peeve is provenpackagers or comaintainers who add unwanted
automagic (autorelease, autosetup, autochangelog) to my packages.
That really shouldn't be happening for anything which wasn't officially
made
> Kevin Kofler via devel writes:
> My pet peeve is provenpackagers or comaintainers who add unwanted
> automagic (autorelease, autosetup, autochangelog) to my packages.
That really shouldn't be happening for anything which wasn't officially
made mandatory or forbidden or whatnot. Sure, I
On Tue, Dec 5, 2023 at 3:48 AM Kevin Kofler via devel
wrote:
> My pet peeve is provenpackagers or comaintainers who add unwanted automagic
> (autorelease, autosetup, autochangelog) to my packages. I do not want any of
> that in my packages, it just makes my work harder (or in practice, just
>
Michael J Gruber wrote:
> I am sick of this. Really. I am so sick of this way of stomping on each
> others' feet.
My pet peeve is provenpackagers or comaintainers who add unwanted automagic
(autorelease, autosetup, autochangelog) to my packages. I do not want any of
that in my packages, it just
On Fri Dec 1, 2023 at 16:26 +0100, Michael J Gruber wrote:
> So, due to me following my package (notmuch) upstream and testing early
> against upstream's git, reporting and working with upstream, I noticed a
> FTBFS and helped fixing it. Nothing urgent since it was basically just a
> test failing
On Fri, Dec 01, 2023 at 03:41:54PM -0600, Jason L Tibbitts III wrote:
[snip]
> If there isn't anything wrong with the work of the other maintainer,
> then I guess I don't understand. They did something in an honest
> attempt to save you the trouble and because of unfortunate timing they
> didn't
In my experience through the years, I've found very little proven
packagers that would work in what *I would see* as the right way.
I too despise random interventions from the higher power to my packages.
I rejoiced when the new process of removing inactive proven packagers
took place.
And I'd
Sérgio Basto wrote on 2023/12/02 0:49:
On Fri, 2023-12-01 at 16:26 +0100, Michael J Gruber wrote:
So, due to me following my package (notmuch) upstream and testing
early against upstream's git, reporting and working with upstream, I
noticed a FTBFS and helped fixing it. Nothing urgent since it
Jason L Tibbitts III venit, vidit, dixit 2023-12-01 22:41:54:
> So I've been in this situation, both on the receiving end of nasty flames
> because I dared touch someone else's package and having duplicated work
> because I didn't check before trying to update something.
>
> > Michael J
So I've been in this situation, both on the receiving end of nasty flames
because I dared touch someone else's package and having duplicated work
because I didn't check before trying to update something.
> Michael J Gruber writes:
> So, due to me following my package (notmuch)
The idea is
On Fri, 2023-12-01 at 16:26 +0100, Michael J Gruber wrote:
> So, due to me following my package (notmuch) upstream and testing
> early against upstream's git, reporting and working with upstream, I
> noticed a FTBFS and helped fixing it. Nothing urgent since it was
> basically just a test failing
So, due to me following my package (notmuch) upstream and testing early
against upstream's git, reporting and working with upstream, I noticed a
FTBFS and helped fixing it. Nothing urgent since it was basically just a
test failing for the wrong reasons.
Within a few days, upstream releases a
24 matches
Mail list logo
