Hello,
On Mon 27 Mar 2023 at 12:02AM +01, Steve McIntyre wrote:
> I think you're *reaching* here. I know of quite a few projects where
> they consider their CI setup to be an intergral part of project
> development. Should we therefore declare that "preferred form of
> modification" could
At 2023-03-26T13:56:55-0700, Sean Whitton wrote:
> On Sat 04 Mar 2023 at 10:58PM +01, Joerg Jaspert wrote:
> > But git or svn or even sccs and rcs is NOT, in any way, preferred
> > for of modification. Only one way of storage and handling some
> > metadata.
>
> This is Debian's official position,
Sean Whitton wrote:
>
>On Sat 04 Mar 2023 at 10:58PM +01, Joerg Jaspert wrote:
>
>> On 16792 March 1977, Adrian Bunk wrote:
>>
>>> for the contents of packages in the archive the ftp team requires that
>>> everything is in the preferred form of modification.
>>
>> Yes. Of course.
>>
>> But git or
Hello,
On Sat 04 Mar 2023 at 10:58PM +01, Joerg Jaspert wrote:
> On 16792 March 1977, Adrian Bunk wrote:
>
>> for the contents of packages in the archive the ftp team requires that
>> everything is in the preferred form of modification.
>
> Yes. Of course.
>
> But git or svn or even sccs and rcs
Hello,
On Sat 04 Mar 2023 at 07:25PM +02, Adrian Bunk wrote:
> for the contents of packages in the archive the ftp team requires that
> everything is in the preferred form of modification.
>
> It is therefore surprising that you as member of the ftp team declare
> that there is no requirement at
On Sat, Mar 04, 2023 at 07:43:37PM +, Scott Kitterman wrote:
> On March 4, 2023 5:25:35 PM UTC, Adrian Bunk wrote:
> >On Wed, Mar 01, 2023 at 05:54:38PM -0700, Sean Whitton wrote:
> >>
> >> This is a matter of perspective. The fact that dak doesn't store git
> >> histories and send them out
On 16792 March 1977, Adrian Bunk wrote:
for the contents of packages in the archive the ftp team requires that
everything is in the preferred form of modification.
Yes. Of course.
But git or svn or even sccs and rcs is NOT, in any way, preferred for of
modification. Only one way of storage
On March 4, 2023 5:25:35 PM UTC, Adrian Bunk wrote:
>On Wed, Mar 01, 2023 at 05:54:38PM -0700, Sean Whitton wrote:
>> Hello,
>
>Hi Sean,
>
>> On Sun 26 Feb 2023 at 11:38PM +02, Adrian Bunk wrote:
>>
>> > On Sun, Feb 26, 2023 at 09:57:34PM +0100, Diederik de Haas wrote:
>> >> On Sunday, 26
On Wed, Mar 01, 2023 at 05:54:38PM -0700, Sean Whitton wrote:
> Hello,
Hi Sean,
> On Sun 26 Feb 2023 at 11:38PM +02, Adrian Bunk wrote:
>
> > On Sun, Feb 26, 2023 at 09:57:34PM +0100, Diederik de Haas wrote:
> >> On Sunday, 26 February 2023 20:06:26 CET Adrian Bunk wrote:
> >>...
> >> > For
Hello,
On Sun 26 Feb 2023 at 11:38PM +02, Adrian Bunk wrote:
> On Sun, Feb 26, 2023 at 09:57:34PM +0100, Diederik de Haas wrote:
>> On Sunday, 26 February 2023 20:06:26 CET Adrian Bunk wrote:
>>...
>> > For anything in Debian, the package sources in Debian would not
>> > disappear when a
Hello,
On Mon 27 Feb 2023 at 12:17AM +01, Diederik de Haas wrote:
> But AFAIK the Debian Xen Team does use dgit (not surprising given dgit's
> maintainer (and author?)) ... and that drives me insane.
> I'm very sure that is due to me not understanding the concepts/idea/etc, but I
> can't wrap my
On Sun, Feb 26, 2023 at 02:24:26PM +0100, Bastian Germann wrote:
> During the last weeks I had a look at the Vcs situation in Debian. Currently,
> there are eight possible systems allowed and one might specify several of
> them for
> one package. No package makes use of several Vcs references and
On Sun, Feb 26, 2023 at 10:25:21AM -0700, Sean Whitton wrote:
> Why don't we just fix all those packacges, instead of changing any
> documents? Is there anyone who actually wants to introduce new packages
> not using git? I'm not so sure.
mostly agreed, i'm just sure there will be very few
On Mon, 27 Feb 2023 at 00:17:41 +0100, Diederik de Haas wrote:
> Russ Allbery wrote:
> > dgit maintains a history of every package in Debian.
>
> AFAIK the Debian Xen Team does use dgit (not surprising given dgit's
> maintainer (and author?)) ... and that drives me insane.
> I'm very sure that
On Sun, Feb 26, 2023 at 11:42:25PM +0100, Diederik de Haas wrote:
>...
> The reason that I'm such a proponent of that is that 3 weeks or 3 months from
> now, there's a reasonable chance that you (the author/committer) does no
> longer remember the details of that commit.
> In 3+ years that will
[please CC me in replies as I'm not subscribed to d-devel]
Russ Allbery wrote:
> Diederik de Haas writes:
> > Question as I don't know: is that only the package change that gets
> > uploaded to the Debian archive, or is there also a place where the (git)
> > history of the changes leading up to
On Sunday, 26 February 2023 22:38:51 CET Adrian Bunk wrote:
> On Sun, Feb 26, 2023 at 09:57:34PM +0100, Diederik de Haas wrote:
> > On Sunday, 26 February 2023 20:06:26 CET Adrian Bunk wrote:
> >...
> >
> > > For anything in Debian, the package sources in Debian would not
> > > disappear when a
On Sun, Feb 26, 2023 at 09:57:34PM +0100, Diederik de Haas wrote:
> On Sunday, 26 February 2023 20:06:26 CET Adrian Bunk wrote:
>...
> > For anything in Debian, the package sources in Debian would not
> > disappear when a repository (or salsa) disappears.
>
> Question as I don't know: is that
Diederik de Haas writes:
> Question as I don't know: is that only the package change that gets
> uploaded to the Debian archive, or is there also a place where the (git)
> history of the changes leading up to a new upload gets stored?
dgit maintains a history of every package in Debian. If you
On Sunday, 26 February 2023 20:06:26 CET Adrian Bunk wrote:
> On Sun, Feb 26, 2023 at 07:25:57PM +0100, Diederik de Haas wrote:
> > Apart from me not liking proprietary systems in general and M$ GitHub in
> > particular, you also run the risk of things disappearing entirely without
> > any notice
On Sun, Feb 26, 2023 at 07:25:57PM +0100, Diederik de Haas wrote:
>...
> Apart from me not liking proprietary systems in general and M$ GitHub in
> particular, you also run the risk of things disappearing entirely without any
> notice and without any recourse.
Perhaps tomorrow some company like
On Sunday, 26 February 2023 17:59:52 CET Bill Allombert wrote:
> > During the last weeks I had a look at the Vcs situation in Debian.
> >
> > For the allowed systems the situation in unstable is the following:
> > ...
> > svn is used by ~130 packages, many of which point to bad URLs.
> >
> > We
Hello,
On Sun 26 Feb 2023 at 02:24PM +01, Bastian Germann wrote:
> Hi!
>
> During the last weeks I had a look at the Vcs situation in Debian. Currently,
> there are eight possible systems allowed and one might specify several of
> them for
> one package. No package makes use of several Vcs
On Sun, Feb 26, 2023 at 02:24:26PM +0100, Bastian Germann wrote:
> Hi!
>
> During the last weeks I had a look at the Vcs situation in Debian. Currently,
> there are eight possible systems allowed and one might specify several of
> them for
> one package. No package makes use of several Vcs
Am 26.02.23 um 17:26 schrieb Adrian Bunk:
I do not get your point what we would gain if the cvsd maintainer
drops the Vcs-Cvs reference while continuing to maintain the package
in cvs.
That would be a prerequisite to drop Vcs-Cvs support.
It is the last package that points to a working CVS
On Sun, Feb 26, 2023 at 02:24:26PM +0100, Bastian Germann wrote:
> Hi!
>
> During the last weeks I had a look at the Vcs situation in Debian. Currently,
> there are eight possible systems allowed and one might specify several of
> them for
> one package. No package makes use of several Vcs
On Sun, Feb 26, 2023 at 02:24:26PM +0100, Bastian Germann wrote:
> During the last weeks I had a look at the Vcs situation in Debian. Currently,
> there are eight possible systems allowed
I see a difference between (dis)allowing a VCS in the Vcs-* fields and
(dis)allowing maintainers to store
On Sun, 2023-02-26 at 14:24 +0100, Bastian Germann wrote:
> Hi!
>
> During the last weeks I had a look at the Vcs situation in Debian. Currently,
> there are eight possible systems allowed and one might specify several of them
> for
> one package. No package makes use of several Vcs references
Hi!
During the last weeks I had a look at the Vcs situation in Debian. Currently,
there are eight possible systems allowed and one might specify several of them
for
one package. No package makes use of several Vcs references and frankly I do not
see why this was supported in the first place.
29 matches
Mail list logo
