||
|We would also like to reveal the codename of Debian 15, which will be
"Buttercup". This name follows the tradition of naming Debian releases
after characters from the Toy Story movies. We hope you like it and
look forward to your contributions to make Debian 15 another great
release. |
F
On Wed, Jul 05, 2023 at 11:05:05PM +0200, Joaquín Rufo Gutierrez wrote:
> No, Debian 13 will be released on 2024 occasionally.
Who are you, sorry?
The person who sent this "announcement" doesn't seem to be part of the
Debian Project, they're also not listed as a member of the release
team at https://www.debian.org/intro/organization
Someone from the release team might confirm my assumption, but for now
please assume this is a fake/troll emai
Il 05/07/2023 22:50, Joaquín Rufo Gutierrez ha scritto:
|Hello Debian users, We are happy to announce that Debian 13,
codenamed "Trixie", is expected to be released sometime in 2024,
following the usual 2-year release cycle.|
|
|
|Hi, sorry but if it were |||2-year release cycle | shouldn't i
No, Debian 13 will be released on 2024 occasionally.
El mié, 5 jul 2023 a las 23:04, Mike Hommey () escribió:
> On Wed, Jul 05, 2023 at 10:50:34PM +0200, Joaquín Rufo Gutierrez wrote:
> > Hello Debian users,
> >
> > We are happy to announce that Debian 13, codenamed "Trixie", is
> > expected to b
On Wed, Jul 05, 2023 at 10:50:34PM +0200, Joaquín Rufo Gutierrez wrote:
> Hello Debian users,
>
> We are happy to announce that Debian 13, codenamed "Trixie", is
> expected to be released sometime in 2024, following the usual 2-year
> release cycle.
Bookworm was released in 2023. The usual 2-year
Hello Debian users,
We are happy to announce that Debian 13, codenamed "Trixie", is
expected to be released sometime in 2024, following the usual 2-year
release cycle. The exact release date will depend on the progress of
testing and bug fixing, but we will keep you updated on the
development stat
On Sun, 13 Nov 2016 15:43:26 +0100, gregor herrmann
wrote:
>On Sun, 13 Nov 2016 10:29:13 +0100, Marc Haber wrote:
>
>> On Thu, 10 Nov 2016 08:26:46 +0100, Christoph Biedl
>> wrote:
>> >Finally, there's a thing called "trust": I trust the Release Team does
>> >this solely in order to keep the free
On Sun, Nov 13, 2016 at 11:23:24AM +, Steve McIntyre wrote:
> FTAOD: I thank the release team for their tireless work on making each
> Debian release better than the last. We keep on adding more and more
> software and making things harder and harder to stabilise and release,
> and I 100% suppo
On Sun, 13 Nov 2016 10:29:13 +0100, Marc Haber wrote:
> On Thu, 10 Nov 2016 08:26:46 +0100, Christoph Biedl
> wrote:
> >Finally, there's a thing called "trust": I trust the Release Team does
> >this solely in order to keep the freeze time as short as possible,
> >everybody hates that time anyway.
Marc Haber writes:
> I would feel a lot less uncomfortable if the teams who are using
> automated tools to auto-file RC bugs for third-rate policy violations
> which will auto-remove a (99,99% of the cases) perfectly working
> package from testing in a time where a maintainer would probably not
>
Samuel Thibault, on Sun 13 Nov 2016 12:25:33 +0100, wrote:
> Marc Haber, on Sun 13 Nov 2016 12:16:46 +0100, wrote:
> > But we currently treat "does not build at all" or "eats my entire
> > ~ on installation" the same way like "leaves an idle directory in
> > /var/lib after an
> > install-purge-rein
On Sun, Nov 13, 2016 at 12:16:46PM +0100, Marc Haber wrote:
> Yes. But we currently treat "does not build at all" or "eats my entire
> ~ on installation" the same way like "leaves an idle directory in
> /var/lib after an
> install-purge-reinstall-old-version-update-remove-reinstall-purge
> cycle".
]] Marc Haber
> On Thu, 10 Nov 2016 00:24:20 +0100, Wouter Verhelst
> wrote:
>
> >If the release team is willing to consider exceptions when
> >the automated machinery was jumping the gun a little, however, then
> >okay, I think it might be a good idea to try this out.
>
> If you only get an ex
Marc Haber, on Sun 13 Nov 2016 12:16:46 +0100, wrote:
> But we currently treat "does not build at all" or "eats my entire
> ~ on installation" the same way like "leaves an idle directory in
> /var/lib after an
> install-purge-reinstall-old-version-update-remove-reinstall-purge
> cycle".
Don't conf
Marc Haber whined:
>On Thu, 10 Nov 2016 07:37:00 +, Niels Thykier
>
>>"""
>>The release managers may make exceptions to these guidelines as they see
>>fit. *Such exceptions are not precedents and you should not assume that
>>your package has a similar exception*. Please talk to us if you need
On Sun, 13 Nov 2016 12:11:06 +0100, Samuel Thibault
wrote:
>Marc Haber, on Sun 13 Nov 2016 11:48:06 +0100, wrote:
>> I'd rather have a badly maintained package than none.
>
>That's probably the real point where people differ.
>
>To me, releasing in Debian means some given level of quality.
Yes. B
Marc Haber, on Sun 13 Nov 2016 11:48:06 +0100, wrote:
> I'd rather have a badly maintained package than none.
That's probably the real point where people differ.
To me, releasing in Debian means some given level of quality.
Samuel
On Sun, Nov 13, 2016 at 11:55:13AM +0100, Marc Haber wrote:
> This means that we didn't to this with squeeze, wheezy and jessie.
we did this for jessie. the fact that you were not paying attention
doesnt change reality.
--
cheers,
Holger
signature.asc
Description: Digital signature
Marc Haber, on Sun 13 Nov 2016 11:56:09 +0100, wrote:
> On Sun, 13 Nov 2016 11:46:36 +0100, Samuel Thibault
> wrote:
> >Marc Haber, on Sun 13 Nov 2016 11:37:54 +0100, wrote:
> >> On Sun, 06 Nov 2016 11:51:36 +, Steve McIntyre
> >> wrote:
> >> >Releasing Debian is work for all of us, not just
Marc Haber, on Sun 13 Nov 2016 11:55:13 +0100, wrote:
> On Sun, 13 Nov 2016 11:45:23 +0100, Samuel Thibault
> wrote:
> >Marc Haber, on Sun 13 Nov 2016 11:37:13 +0100, wrote:
> >> On Sun, 6 Nov 2016 13:06:33 +0200, Lars Wirzenius wrote:
> >> >I'm even willing to justify my opinion: Keeping testing
On Sun, 13 Nov 2016 10:46:07 +, "Adam D. Barratt"
wrote:
>On Sun, 2016-11-13 at 11:28 +0100, Marc Haber wrote:
>> This is a quite nice opportunity to say something like "you haven't
>> been nice enough to us in the past or you have dared to speak up when
>> you didn't like what we did, so you'
On Sun, 13 Nov 2016 11:46:36 +0100, Samuel Thibault
wrote:
>Marc Haber, on Sun 13 Nov 2016 11:37:54 +0100, wrote:
>> On Sun, 06 Nov 2016 11:51:36 +, Steve McIntyre
>> wrote:
>> >Releasing Debian is work for all of us, not just the Release Team...
>>
>> So you are actually suggesting that peo
On Sun, 13 Nov 2016 11:45:23 +0100, Samuel Thibault
wrote:
>Marc Haber, on Sun 13 Nov 2016 11:37:13 +0100, wrote:
>> On Sun, 6 Nov 2016 13:06:33 +0200, Lars Wirzenius wrote:
>> >I'm even willing to justify my opinion: Keeping testing in a state
>> >that can be released seems to be the only way in
Marc Haber:
> On Wed, 9 Nov 2016 19:45:02 +0100, gregor herrmann
> wrote:
>> I don't quite understand where all this fuzz about auto-removals
>> suddenly comes from. The auto-removals exist since Septemer 2013 [0]
>> and they were also in place for the jessie freeze [1], with the small
>> differen
On Sun, 13 Nov 2016 11:07:18 +0100, Christoph Biedl
wrote:
>Marc Haber wrote...
>
>> This is exactly the problem I have with the current policy: I fail to
>> see why this measure will shorten the freeze.
>
>I don't. But I'd say we'll just watch what's going to happen and resume
>this discussion on
On Thu, 10 Nov 2016 00:24:20 +0100, Wouter Verhelst
wrote:
>What if I did notice, but fixing the bug takes longer than the 15 days
>(and I agree that we shouldn't release with that bug, so I agree that
>the severity is correct)?
>
>15 days is a pretty short time for irreversible changes in Debian,
On Sun, 6 Nov 2016 12:53:42 +0100, Christian Seiler
wrote:
>And if the problem is complicated, they have other
>options: request for help on debian-devel@ and debian-mentors@,
>request an exception from the release team to mark a bug as
>stretch-ignore in specific cases, request an extension by th
Marc Haber, on Sun 13 Nov 2016 11:37:54 +0100, wrote:
> On Sun, 06 Nov 2016 11:51:36 +, Steve McIntyre
> wrote:
> >Releasing Debian is work for all of us, not just the Release Team...
>
> So you are actually suggesting that people who are neither on the
> release team nor maintaining a key pa
On Sun, 2016-11-13 at 11:28 +0100, Marc Haber wrote:
> On Thu, 10 Nov 2016 07:37:00 +, Niels Thykier
> >"""
> >The release managers may make exceptions to these guidelines as they see
> >fit. *Such exceptions are not precedents and you should not assume that
> >your package has a similar excep
Marc Haber, on Sun 13 Nov 2016 11:37:13 +0100, wrote:
> On Sun, 6 Nov 2016 13:06:33 +0200, Lars Wirzenius wrote:
> >I'm even willing to justify my opinion: Keeping testing in a state
> >that can be released seems to be the only way in which we can make a
> >release in a reasonable time frame. We'v
On Sun, 6 Nov 2016 13:06:33 +0200, Lars Wirzenius wrote:
>I'm even willing to justify my opinion: Keeping testing in a state
>that can be released seems to be the only way in which we can make a
>release in a reasonable time frame. We've tried several other
>approaches, which haven't worked. The a
On Sun, 06 Nov 2016 11:51:36 +, Steve McIntyre
wrote:
>Releasing Debian is work for all of us, not just the Release Team...
So you are actually suggesting that people who are neither on the
release team nor maintaining a key package are not working?
Greetings
Marc
--
---
Marc Haber, on Sun 13 Nov 2016 11:30:18 +0100, wrote:
> On Wed, 9 Nov 2016 14:01:13 +, Ian Jackson
> wrote:
> >If it turns out to be a more common problem and there are many
> >packages affected, then this would mean delays to the stretch release,
> >indeed.
>
> One of my issues is that this
On Wed, 9 Nov 2016 19:45:02 +0100, gregor herrmann
wrote:
>I don't quite understand where all this fuzz about auto-removals
>suddenly comes from. The auto-removals exist since Septemer 2013 [0]
>and they were also in place for the jessie freeze [1], with the small
>difference that now the point-of
On Wed, 9 Nov 2016 14:01:13 +, Ian Jackson
wrote:
>If it turns out to be a more common problem and there are many
>packages affected, then this would mean delays to the stretch release,
>indeed.
One of my issues is that this new policy means a switch from "we'll
release when it's ready" to "
On Thu, 10 Nov 2016 07:37:00 +, Niels Thykier
wrote:
> * As James noted; sending an update to the bug will reset the timer.
Did I miss the documentation about this? It does not seem to be in the
freeze policy.
> * Also, if you do not have time for a given bug, please consider
> tagging it
On Thu, 10 Nov 2016 08:36:21 +0100, Ole Streicher
wrote:
>Wouter Verhelst writes:
>> On Tue, Nov 08, 2016 at 11:05:59AM +0100, Christian Seiler wrote:
>>> 30 days within the deep freeze should be plenty enough - and as I
>>> said: if the problem is more complicated, just talk to the release
>>> t
On Tue, 8 Nov 2016 11:05:59 +0100, Christian Seiler
wrote:
>Yes, especially since autoremovals are not instantaneous, but for
>packages with rdeps (and the rdeps themselves) will happen at
>least 30 days in the future - and you will get an email in time.
>(For packages without rdeps it's 15 days.
Marc Haber wrote...
> This is exactly the problem I have with the current policy: I fail to
> see why this measure will shorten the freeze.
I don't. But I'd say we'll just watch what's going to happen and resume
this discussion once stretch is released.
Chri- "somewhen December 2017" stoph
On Thu, 10 Nov 2016 10:17:57 +0100, Emilio Pozuelo Monfort
wrote:
>And yes, we will give exceptions on a case by case basis, as we have always
>done.
This will create a third class of packages: The ones that are not
important enough to get an exception, which will in turn demotivate
package main
On Thu, 10 Nov 2016 08:26:46 +0100, Christoph Biedl
wrote:
>Finally, there's a thing called "trust": I trust the Release Team does
>this solely in order to keep the freeze time as short as possible,
>everybody hates that time anyway. This trust was created by the very
>people behind it, and the wa
On 10/11/16 08:26, Christoph Biedl wrote:
> Ian Jackson wrote...
>
>> I think what is really worrying people is the fear that they might
>> miss something, for good reasons, and then find that their work that
>> they care about is thrown out of stretch.
>>
>> It is difficult to address this fear w
Wouter Verhelst writes:
> On Tue, Nov 08, 2016 at 11:05:59AM +0100, Christian Seiler wrote:
>> 30 days within the deep freeze should be plenty enough - and as I
>> said: if the problem is more complicated, just talk to the release
>> team _while the package is still in testing_.
>
> Let's say I'm
Wouter Verhelst:
> On Tue, Nov 08, 2016 at 11:05:59AM +0100, Christian Seiler wrote:
>> 30 days within the deep freeze should be plenty enough - and as I
>> said: if the problem is more complicated, just talk to the release
>> team _while the package is still in testing_.
>
> Let's say I'm on holi
Ian Jackson wrote...
> I think what is really worrying people is the fear that they might
> miss something, for good reasons, and then find that their work that
> they care about is thrown out of stretch.
>
> It is difficult to address this fear with logical arguments intended
> to demonstrate tha
On Thu, Nov 10, 2016 at 12:24:20AM +0100, Wouter Verhelst wrote:
> On Tue, Nov 08, 2016 at 11:05:59AM +0100, Christian Seiler wrote:
> > 30 days within the deep freeze should be plenty enough - and as I
> > said: if the problem is more complicated, just talk to the release
> > team _while the packa
On Wed, 2016-11-09 at 22:55 +0200, Adrian Bunk wrote:
> Is anyone tracking what packages are installed from backports on
> Debian machines, and the CVEs in them?
backports is unsupported by the security team, so DSA & backports users
rely on service maintainers and backporters to do the right thi
gregor herrmann writes ("Re: More 5 november in the release schedule"):
> I don't quite understand where all this fuzz about auto-removals
> suddenly comes from. The auto-removals exist since Septemer 2013 [0]
> and they were also in place for the jessie freeze [1], wit
On Tue, Nov 08, 2016 at 11:05:59AM +0100, Christian Seiler wrote:
> 30 days within the deep freeze should be plenty enough - and as I
> said: if the problem is more complicated, just talk to the release
> team _while the package is still in testing_.
Let's say I'm on holiday (or I get hit by a bus
On Wed, Nov 09, 2016 at 11:16:36AM +0800, Paul Wise wrote:
> On Wed, Nov 9, 2016 at 1:36 AM, Emilio Pozuelo Monfort wrote:
>
> > Right. We want auto-removals to be useful for the release process, so that
> > we
> > don't end up with a thousand of RC bugs in testing when we freeze, most of
> > th
On Wed, 09 Nov 2016 14:01:13 +, Ian Jackson wrote:
> If it turns out to be a more common problem and there are many
> packages affected, then this would mean delays to the stretch release,
> indeed. But it would also highlight where the real problem is - ie,
> not with the maintenance of the
Marvin Renich writes ("Re: More 5 november in the release schedule"):
> Emilio Pozuelo Monfort [161108 16:01]:
> > It is true for other removals from testing, which can happen in two
> > different ways:
> >
> > - The package was removed from unstable
>
* Emilio Pozuelo Monfort [161108 16:01]:
> It is true for other removals from testing, which can happen in two different
> ways:
>
> - The package was removed from unstable
> - The package was hinted for testing removal by the release team
>
> Since britney doesn't enforce (atm) that build-depe
On Wed, 09 Nov 2016 at 17:03:45 +1100, Brian May wrote:
> Another situation: You are not listed as the maintainer of the package
> you really care about, and the real maintainer ignores the autoremoval
> notifications. Other people looking at the package bug reports (there
> may be none) may not re
On 09/11/16 04:16, Paul Wise wrote:
> On Wed, Nov 9, 2016 at 1:36 AM, Emilio Pozuelo Monfort wrote:
>
>> Right. We want auto-removals to be useful for the release process, so that we
>> don't end up with a thousand of RC bugs in testing when we freeze, most of
>> them
>> on packages that nobody c
Scott Kitterman writes:
> I seem to get email when a package I maintain is marked for autoremoval
> (regardless of whether it is an issue with my package or an rdepend). That
> and it showing up on your DDPO Packages overview ought to be enough to be
> forewarned, I would have thought.
That
On Wed, Nov 9, 2016 at 1:36 AM, Emilio Pozuelo Monfort wrote:
> Right. We want auto-removals to be useful for the release process, so that we
> don't end up with a thousand of RC bugs in testing when we freeze, most of
> them
> on packages that nobody cares about, not even their maintainers.
>
>
On 11/08/2016 08:47 PM, Adrian Bunk wrote:
> On Tue, Nov 08, 2016 at 02:31:04AM -0500, Scott Kitterman wrote:
>> On Tuesday, November 08, 2016 06:19:36 PM Brian May wrote:
>>> Christian Seiler writes:
Why? Any package currently in testing still has time to enter
(until roughly end of thi
On 11/08/2016 08:31 AM, Scott Kitterman wrote:
> On Tuesday, November 08, 2016 06:19:36 PM Brian May wrote:
>> Christian Seiler writes:
>>> Why? Any package currently in testing still has time to enter
>>> (until roughly end of this year), so it's not like there is no
>>> heads-up for people. And
On Tuesday, November 08, 2016 06:19:36 PM Brian May wrote:
> Christian Seiler writes:
> > Why? Any package currently in testing still has time to enter
> > (until roughly end of this year), so it's not like there is no
> > heads-up for people. And RC bugs don't lead to immediate
> > removal from t
On Tue, Nov 8, 2016 at 3:19 PM, Brian May wrote:
> The problem is if the maintainer is not responding to RC bug reports,
> and you don't realize a package you depend on has RC bugs. This happened
> several times to me during the last freeze.
Assuming you have your package and its dependencies and
Christian Seiler writes:
> Why? Any package currently in testing still has time to enter
> (until roughly end of this year), so it's not like there is no
> heads-up for people. And RC bugs don't lead to immediate
> removal from testing, you still have quite a bit of time until
> they actually cau
Christoph Biedl, on Mon 07 Nov 2016 19:02:17 +0100, wrote:
> If I understood some remarks in IRC correctly: Filing an RC bug after
> hard freeze may lead to immediate and thus irrevocable removal from
> stretch[citation needed].
The removal is not immediate, you have time to downgrade the severity
Quoting Christoph Biedl (2016-11-07 19:02:17)
> If I understood some remarks in IRC correctly: Filing an RC bug after
> hard freeze may lead to immediate and thus irrevocable removal from
> stretch[citation needed]. If this was true, a malicious attacker could
> abuse this to kick arbitrary pack
Ian Jackson wrote...
> There's still big spikes in work for our core teams around deadlines,
> so it's still best if people sort their stuff out earlier, but the new
> arrangements are a big improvement IMO.
ACK, and also looking at the way removals were handled in the past
months (Like long grac
Christian Seiler writes ("Re: More 5 november in the release schedule"):
> If a stable release is going to happen, there needs to be some
> kind of process so that one may converge on a stable result.
> What happens if you only have a single deadline to freeze
> fully? I
On 11/06/2016 11:59 AM, Marc Haber wrote:
> On Sun, 06 Nov 2016 09:38:00 +, Niels Thykier
> wrote:
>> Marc Haber:
>>> On Sat, 5 Nov 2016 13:46:16 +0100, Sebastiaan Couwenberg
>>> wrote:
[2017-Jan-05] Soft freeze (no new packages, no re-entry, 10-day
migrations)
>>>
>>>
Marc Haber wrote:
>On Sun, 06 Nov 2016 09:38:00 +, Niels Thykier
>wrote:
>>Marc Haber:
>>> On Sat, 5 Nov 2016 13:46:16 +0100, Sebastiaan Couwenberg
>>> wrote:
[2017-Jan-05] Soft freeze (no new packages, no re-entry, 10-day
migrations)
>>>
>>> Does this really mean "on
On Sun, Nov 06, 2016 at 11:59:34AM +0100, Marc Haber wrote:
> That is really really bad. I really hoped back in 2015 that you were
> joking when you announced that.
It's really, really good. I was really glad that it isn't a joke.
I'm even willing to justify my opinion: Keeping testing in a state
On Sun, 06 Nov 2016 09:38:00 +, Niels Thykier
wrote:
>Marc Haber:
>> On Sat, 5 Nov 2016 13:46:16 +0100, Sebastiaan Couwenberg
>> wrote:
>>> [2017-Jan-05] Soft freeze (no new packages, no re-entry, 10-day
>>> migrations)
>>
>> Does this really mean "once you're out, you'll stay
On Sat, 5 Nov 2016 13:46:16 +0100, Sebastiaan Couwenberg
wrote:
> [2017-Jan-05] Soft freeze (no new packages, no re-entry, 10-day
> migrations)
Does this really mean "once you're out, you'll stay out"?
Greetings
Marc
--
-- !! No courtesy copies,
Marc Haber:
> On Sat, 5 Nov 2016 13:46:16 +0100, Sebastiaan Couwenberg
> wrote:
>> [2017-Jan-05] Soft freeze (no new packages, no re-entry, 10-day
>> migrations)
>
> Does this really mean "once you're out, you'll stay out"?
>
> Greetings
> Marc
>
Yes.
On 11/05/2016 01:39 PM, Geert Stappers wrote:
> Today is november fifth, day of the soft freeze in the Debian release
> schedule.
The soft freeze was moved to January 5th, today is the day of the
transition freeze:
"
Key release dates
[2016-Nov-05] Transition freeze
[2016-Dec-05
Hi,
(At the time of writing, it was 5 november in all timezones)
Today is november fifth, day of the soft freeze in the Debian release schedule.
I real like this fixed date. Having a clear goal is good!
Riding with "Remember, remember, the fifth of november" is cool.
Will Debi
Stefano Zacchiroli writes:
> On Mon, Feb 15, 2010 at 07:15:52PM +0100, Toni Mueller wrote:
>> On Mon, 08.02.2010 at 20:13:48 +0100, Marc Brockschmidt
>> wrote:
>> > we wish to freeze only after the number of these bugs has dropped below
>> > the mark of 300. As you can see on the usual overview
On Mon, Feb 15, 2010 at 07:15:52PM +0100, Toni Mueller wrote:
> On Mon, 08.02.2010 at 20:13:48 +0100, Marc Brockschmidt
> wrote:
> > we wish to freeze only after the number of these bugs has dropped below
> > the mark of 300. As you can see on the usual overview pages [RC-Bugs],
> great decision,
Hi,
On Mon, 08.02.2010 at 20:13:48 +0100, Marc Brockschmidt wrote:
> we wish to freeze only after the number of these bugs has dropped below
> the mark of 300. As you can see on the usual overview pages [RC-Bugs],
great decision, imho.
> Work towards fixing these bugs is greatly appreciated. W
On Thu, 29 Mar 2007, Andreas Barth wrote:
> another week or so. Our secret plan was to announce the release on April 1st
> (that would have been fun, don't you think so :) ), but well - quality is
> more important.
You realise, of course, that you can still announce the release on April
1st anyway
79 matches
Mail list logo
