Hello,
On Fri 02 Sep 2022 at 12:31PM +01, Ian Jackson wrote:
> Sean Whitton writes ("Re: Comments on proposing NEW queue improvement (Re:
> Current NEW review process saps developer motivation"):
>> On Sat 27 Aug 2022 at 04:22PM +02, Vincent Bernat wrote:
>> > I
Sean Whitton writes ("Re: Comments on proposing NEW queue improvement (Re:
Current NEW review process saps developer motivation"):
> On Sat 27 Aug 2022 at 04:22PM +02, Vincent Bernat wrote:
> > It does not seem to work. Either people don't want to do that, either the
On Mon, 29 Aug 2022 00:15:27 -0400, Scott Kitterman
wrote:
>If I look at a package and determine it's only in New due to a new binary
>package name and that means the project has prohibited me from looking for
>other issues in the package until some time later when it's not in New, then I
>feel
On Tue, 30 Aug 2022 at 09:27:44 +0800, Paul Wise wrote:
> It occurred to me that if the compiler/linker could be made to generate
> the GI data and then something else split it out of the binary (similar
> to how debug symbols work) then this issue could potentially be solved,
> does that sound fea
On Mon, 2022-08-29 at 11:58 +0100, Wookey wrote:
> Something of an aside from the current debate, but GObject
> introspection introduced significant problems with cross-compiling
> because the introspection process produces different results when done
> on different architectures so you couldn't j
On Mon, 2022-08-29 at 12:33 +0530, Pirate Praveen wrote:
> May be we should be able to tag packages with in NEW into categories
> like this (similar to how a DD can give back a failed build via web
> interface). This may need to go through a GR. If we prioritize packages
> in NEW required for u
Sean Whitton wrote on 27/08/2022 at 20:24:55+0200:
> [[PGP Signed Part:No public key for 695B7AE4BF066240 created at
> 2022-08-27T20:24:55+0200 using RSA]]
> Hello,
>
> On Sat 27 Aug 2022 at 04:22PM +02, Vincent Bernat wrote:
>
>>
>> On 2022-08-27 15:53, M. Zhou wrote:
>>
>>> That's why I still
On 2022-08-28 12:14 +0100, Simon McVittie wrote:
> However, GObject-Introspection has worked approximately the way it
> currently works since at least 2008, and was apparently fine.
Something of an aside from the current debate, but GObject
introspection introduced significant problems with cross-
On Mon, Aug 29 2022 at 12:33:44 PM +05:30:00 +05:30:00, Pirate Praveen
wrote:
On Sun, Aug 28 2022 at 07:39:12 AM +02:00:00 +02:00:00, Andreas Tille
wrote:
BTW, the vast amount of new packages I'm packaging are new
dependencies
for existing packages to get their new versions.
May be
On Sun, Aug 28 2022 at 07:39:12 AM +02:00:00 +02:00:00, Andreas Tille
wrote:
BTW, the vast amount of new packages I'm packaging are new
dependencies
for existing packages to get their new versions.
May be we should be able to tag packages with in NEW into categories
like this (similar to
Scott Kitterman writes:
> If I look at a package and determine it's only in New due to a new
> binary package name and that means the project has prohibited me from
> looking for other issues in the package until some time later when it's
> not in New, then I feel pretty precisely like I'm prohib
On Sunday, August 28, 2022 11:53:50 PM EDT Russ Allbery wrote:
> Scott Kitterman writes:
> > Sean Whitton wrote:
> >> I think we still want the binary package namespace checking?
> >>
> >> I.e., a GR just saying "ftpteam should not do a full
> >> licensing/copyright check for packages in binNEW"
Scott Kitterman writes:
> Sean Whitton wrote:
>> I think we still want the binary package namespace checking?
>> I.e., a GR just saying "ftpteam should not do a full
>> licensing/copyright check for packages in binNEW".
>> Then no software changes are required.
> I think that a GR to prohibit
On August 28, 2022 8:58:24 PM UTC, Sean Whitton
wrote:
>Hello,
>
>On Sun 28 Aug 2022 at 07:45AM +02, Andreas Tille wrote:
>
>>
>> Am Sat, Aug 27, 2022 at 09:53:40AM -0400 schrieb M. Zhou:
>>> In my fuzzy memory, the last discussion on NEW queue improvement
>>> involves the disadvantages by all
Hello,
On Sun 28 Aug 2022 at 07:45AM +02, Andreas Tille wrote:
>
> Am Sat, Aug 27, 2022 at 09:53:40AM -0400 schrieb M. Zhou:
>> In my fuzzy memory, the last discussion on NEW queue improvement
>> involves the disadvantages by allowing SOVERSION bump to directly
>> pass the NEW queue. I'm not goin
Paul Wise writes:
> On Fri, 2022-08-26 at 11:58 +0100, Simon McVittie wrote:
>> For instance, take rust-glib-sys, a package of Rust bindings for the
>> GLib library, which is one of the libraries whose handling prompted
>> this thread.
> I feel like the right way to organise this upstream is for
On Sat, Aug 27, 2022 at 09:50:41AM +0200, Gard Spreemann wrote:
> > Strong motivations such as "I use this package, seriously" are not
> > likely to wear out very easily through time. Packages maintained
> > with a strong motivation are better cared among all packages in our
> > archive.
>
> I hum
On Sat, 27 Aug 2022 at 09:01:01 +0800, Paul Wise wrote:
> > I don't think building from the least-derived form is always the
> > right thing to do.
>
> Personally, I believe that instances of that represent bugs in how the
> upstream source trees and build processes are organised.
While I'm flatt
Am Sat, Aug 27, 2022 at 09:53:40AM -0400 schrieb M. Zhou:
> In my fuzzy memory, the last discussion on NEW queue improvement
> involves the disadvantages by allowing SOVERSION bump to directly
> pass the NEW queue. I'm not going to trace back, because I know
> this will not be implemented unless so
Am Fri, Aug 26, 2022 at 04:13:43PM -0400 schrieb M. Zhou:
> If one's enthusiasm on working on some package is eventually
> worn out after a break, then try to think of the following question:
>
> Is it really necessary to introduce XXX to Debian?
May be I'm repeating myself but having packages
"M. Zhou" writes:
> On Sat, 2022-08-27 at 09:50 +0200, Gard Spreemann wrote:
>>
>> I humbly disagree. Even from my own point of view, I may well be very
>> motivated to package something I use seriously all the time,
>> seriously. But then I see its dependency chain of 10 unpackaged
>> items,
>>
Hello,
On Sat 27 Aug 2022 at 04:22PM +02, Vincent Bernat wrote:
>
> On 2022-08-27 15:53, M. Zhou wrote:
>
>> That's why I still hope ftp team to recruit more people. This is
>> a very direct and constructive way to speed up everything.
>> More volunteers = higher bandwidth.
>> Recruiting more peo
Hello,
On Fri 26 Aug 2022 at 11:58AM +01, Simon McVittie wrote:
> More generally, I don't think it's always useful to talk about "the"
> source or "the" preferred form for modification, as though there is only
> one. I think it would be more appropriate to consider whether the form
> in which som
On 2022-08-27 15:53, M. Zhou wrote:
That's why I still hope ftp team to recruit more people. This is
a very direct and constructive way to speed up everything.
More volunteers = higher bandwidth.
Recruiting more people doesn't seem to have a serious disadvantage.
It does not seem to work. Eith
On Sat, 2022-08-27 at 09:50 +0200, Gard Spreemann wrote:
>
> contributing work. In some sense, contributing to Debian becomes
> mostly
> about waiting. (Sure, there is something to be said about extremely
> short, fragmented attention spans being unhealthy – but some
> contributions are naturally
Gard Spreemann writes:
> Oh no, then we instead insist that related work stops
Sorry, this was imprecise of me. We of course don't insist that related
work stops. But I really fear that that is the consequence in a great
many cases.
-- Gard
Paul Wise writes:
> There are a lot of examples of busywork in Debian, such as documenting
> licenses, packaging dependencies, removing non-free files that are only
> in source packages, runtime selection of correct CPU instructions,
> fixing build failures, porting reverse dependencies to newer
"M. Zhou" writes:
> To be honest, in terms of volunteered reviewing work, waiting
> for several months is not something new. In academia, it may
> take several months to years to get a journal paper response.
Sure, but
(1) that situation isn't popular in academia either,
(2) at least you can
On Fri, 2022-08-26 at 11:58 +0100, Simon McVittie wrote:
> I don't think it's always useful to talk about "the" source or "the"
> preferred form for modification, as though there is only one.
I see both the licensing and source aspects of the Free Software
movement as aspiring to providing a high
On Fri, 2022-08-26 at 11:58 +0100, Simon McVittie wrote:
> I don't think building from the least-derived form is always the
> right thing to do.
Personally, I believe that instances of that represent bugs in how the
upstream source trees and build processes are organised.
> For instance, take ru
On Fri, Aug 26, 2022 at 04:13:43PM -0400, M. Zhou wrote:
> If one's enthusiasm on working on some package is eventually
> worn out after a break, then try to think of the following question:
>
> Is it really necessary to introduce XXX to Debian?
> Must I do this to have fun?
>
> Strong motiva
To be honest, in terms of volunteered reviewing work, waiting
for several months is not something new. In academia, it may
take several months to years to get a journal paper response.
I've ever tried to think of possible ways to improve the process, but
several observations eventually changed my
> "Simon" == Simon McVittie writes:
Simon> I don't think building from the least-derived form is always
Simon> the right thing to do. For instance, take rust-glib-sys, a
Simon> package of Rust bindings for the GLib library, which is one
Simon> of the libraries whose handling p
Le vendredi 26 août 2022, 10:58:28 UTC Simon McVittie a écrit :
> On Fri, 26 Aug 2022 at 09:09:25 +0200, Jonas Smedegaard wrote:
> > The way I see it, the process is clear: provide *source* to build from.
> >
> > If there is "source" built from another source, then that other source
> > is the tru
On Fri, 26 Aug 2022 at 09:09:25 +0200, Jonas Smedegaard wrote:
> The way I see it, the process is clear: provide *source* to build from.
>
> If there is "source" built from another source, then that other source
> is the true source.
I hope you agree that we are doing this in order to get some de
Jonas Smedegaard writes:
> Quoting Gard Spreemann (2022-08-26 08:49:21)
>> On August 25, 2022 10:52:56 AM GMT+02:00, "Sebastian Dröge"
>> wrote:
>> >PS: To preempt any questions as for why, the background for my decision
>> >to stop maintaining any packages is this thread, but it's really just
Quoting Gard Spreemann (2022-08-26 08:49:21)
> On August 25, 2022 10:52:56 AM GMT+02:00, "Sebastian Dröge"
> wrote:
> >PS: To preempt any questions as for why, the background for my decision
> >to stop maintaining any packages is this thread, but it's really just
> >the straw that broke the camel
37 matches
Mail list logo
