Ter, 2007-06-12 às 10:26 -0300, Gustavo Franco escreveu:
Any idea on how to collect more reliable data in a opt-in base? Does a
survey on pentabarf (or public acessible) during debconf makes sense?
Huh How can opt-in data be more reliable then disperse collection?
daniel
--
To
On 6/28/07, Daniel Ruoso [EMAIL PROTECTED] wrote:
Ter, 2007-06-12 às 10:26 -0300, Gustavo Franco escreveu:
Any idea on how to collect more reliable data in a opt-in base? Does a
survey on pentabarf (or public acessible) during debconf makes sense?
Huh How can opt-in data be more reliable
Am 2007-06-14 20:25:54, schrieb Luis Matos:
i don't think this is a reliable situation.
At first look, a new package version is better than it's last.
If the kernel breaks at boot, the bootloader allows you to boot with the
old kernel as _special_ option.
Which mean YOU HAVE two different
On 6/15/07, Michael Banck [EMAIL PROTECTED] wrote:
On Thu, Jun 14, 2007 at 08:10:08PM +0200, Martijn van Oosterhout wrote:
Actually, it seems to me the real problem is that when a new kernel is
installed it is immediately used by the bootloader on the next reboot,
without asking.
That's
Marc 'HE' Brockschmidt [EMAIL PROTECTED] wrote:
I think that a package that has been in unstable for a whole release
cycle without entering testing should probably live in experimental or
not in Debian at all. I guess that is something most people can agree
on.
Hm, I was tempted to think
On Wed, 13 Jun 2007, Felipe Sateler wrote:
PS: I do agree that it would be nice if there was a way to automatically
bring in the modules you are using for the new version, or at least warn,
but I can't seem to figure out a nice and elegant way of doing that. And
no, more people using testing
On 14/06/07 at 08:31 +0200, Frank Küster wrote:
Marc 'HE' Brockschmidt [EMAIL PROTECTED] wrote:
I think that a package that has been in unstable for a whole release
cycle without entering testing should probably live in experimental or
not in Debian at all. I guess that is something most
On Thu, 14 Jun 2007, Raphael Hertzog wrote:
On Wed, 13 Jun 2007, Felipe Sateler wrote:
PS: I do agree that it would be nice if there was a way to automatically
bring in the modules you are using for the new version, or at least warn,
but I can't seem to figure out a nice and elegant way of
Lucas Nussbaum [EMAIL PROTECTED] wrote:
Hm, I was tempted to think yes, of course, but how about foo-snapshot
or bar-cvs? Why shouldn't they be in unstable, autobuilt
I think that such packages are OK in unstable, but some might argue that
they should go in experimental.
and available as
* Luis Matos [EMAIL PROTECTED], [2007-06-14 1:14 +0100]:
Qui, 2007-06-14 às 01:04 +0200, Emanuele Rocca escreveu:
Another option could be calling each snapshot cut -MM, or cut
-MM-DD if we plan to release them more than once per month.
this makes the snapshots just like the
Qua, 2007-06-13 às 20:27 -0400, Felipe Sateler escreveu:
Luis Matos wrote:
Qua, 2007-06-13 às 18:09 -0400, Felipe Sateler escreveu:
Installing a newer kernel is not an upgrade, in a sense. You are
installing new software alongside the old one. Thus the usual
expectations don't hold.
Qua, 2007-06-13 às 17:49 -0700, Steve Langasek escreveu:
On Wed, Jun 13, 2007 at 05:32:01PM +0100, Luis Matos wrote:
Um, no. That does not happen automatically. In rare cases it happens
because the release team has overridden the installability check for a
package, because
Qui, 2007-06-14 às 13:08 +0200, Emanuele Rocca escreveu:
* Luis Matos [EMAIL PROTECTED], [2007-06-14 1:14 +0100]:
Qui, 2007-06-14 às 01:04 +0200, Emanuele Rocca escreveu:
Another option could be calling each snapshot cut -MM, or cut
-MM-DD if we plan to release them more than
Le jeudi 14 juin 2007 à 14:33 +0100, Luis Matos a écrit :
I just want that automatic passages from unstable for testing, when
debian is not in a pre-stable-release state have more verifications such
as reverse depends.
I really don't understand what checks you want to add over those already
On 6/14/07, Luis Matos [EMAIL PROTECTED] wrote:
having a working system *with* only debian *oficial* packages and then
after an upgrade that system stops working properly, i call it a
regression ...
if ... *if* i had used module-assistant to use nvidia graphics (or
camera modules, or wifi, or
Luis Matos wrote:
not true. there are meta pckages that do that for me.
kernel has linux-image-2.6-k8 (for example), modules have
name-module-2.6-k8 .
I had forgotten that those existed. I have always installed my modules and
kernels directly. Taking those into account, what you say would
Qui, 2007-06-14 às 19:18 +0200, Josselin Mouette escreveu:
Le jeudi 14 juin 2007 à 14:33 +0100, Luis Matos a écrit :
I just want that automatic passages from unstable for testing, when
debian is not in a pre-stable-release state have more verifications such
as reverse depends.
I really
Qui, 2007-06-14 às 20:10 +0200, Martijn van Oosterhout escreveu:
I explicitly check to see if there's a kernel upgrade and abort if
that's the case, as I do not have the time to sort out the mess before
the next reboot. Ideally, it could just install, without having it
automatically used next
* Luis Matos ([EMAIL PROTECTED]) [070614 20:20]:
Qui, 2007-06-14 às 19:18 +0200, Josselin Mouette escreveu:
Le jeudi 14 juin 2007 à 14:33 +0100, Luis Matos a écrit :
I just want that automatic passages from unstable for testing, when
debian is not in a pre-stable-release state have more
On Thu, Jun 14, 2007 at 07:18:34PM +0200, Josselin Mouette wrote:
Le jeudi 14 juin 2007 à 14:33 +0100, Luis Matos a écrit :
I just want that automatic passages from unstable for testing, when
debian is not in a pre-stable-release state have more verifications such
as reverse depends.
I
On Thu, Jun 14, 2007 at 02:33:32PM +0100, Luis Matos wrote:
kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build
in
time (they are not free, right?) ... kernel passes to testing ...
That doesn't happen.
well ... it happened to me before etch was released
Qui, 2007-06-14 às 14:40 -0700, Steve Langasek escreveu:
It's an example that does not support your thesis. I have explained
to you
that packages are *not* propagated automatically to testing when they
break
the installability of other packages present in testing; that the
nvidia
modules
On Thu, Jun 14, 2007 at 08:10:08PM +0200, Martijn van Oosterhout wrote:
Actually, it seems to me the real problem is that when a new kernel is
installed it is immediately used by the bootloader on the next reboot,
without asking.
That's because you installed the meta-package, saying I want to
Michael Banck wrote:
On Thu, Jun 14, 2007 at 08:10:08PM +0200, Martijn van Oosterhout wrote:
Actually, it seems to me the real problem is that when a new kernel is
installed it is immediately used by the bootloader on the next reboot,
without asking.
That's because you installed the
* Lucas Nussbaum ([EMAIL PROTECTED]) [070612 23:17]:
On 12/06/07 at 22:23 +0200, Luk Claes wrote:
NO!
unstable is meant for packages that should be in the next stable release,
as such only packages that are in the maintainer's opinion ready to migrate
to testing should be uploaded to
On Wed, Jun 13, 2007 at 12:42:34AM +0100, Luis Matos wrote:
- Smooth passages are not always smooth (who had a working xorg after
the upgrade for 7, please raise their hands)
AFAIR apart from having to edit a few config files it was quite painless
(I've upgraded when Xorg was still in
On Tue, Jun 12, 2007 at 05:40:29PM -0300, Gustavo Franco wrote:
I disagree, that's what we've with experimental today mainly due to
the fact that there's just a few packages there. Consider everybody
uploading every package for unstable instead.
Experimental can and does contain packages that
Ter, 2007-06-12 às 17:03 -0700, Steve Langasek escreveu:
On Wed, Jun 13, 2007 at 12:42:34AM +0100, Luis Matos wrote:
Ter, 2007-06-12 às 22:05 +0200, Frans Pop escreveu:
Personally I think the current system is fine.
just a note, as user:
The current system is fine but:
- priority
On Wed, Jun 13, 2007 at 11:28:52AM +0100, Luis Matos wrote:
kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in
time (they are not free, right?) ... kernel passes to testing ...
automatically, the nvidia-module-2.6.50 uses 2.6.50 and not *.51, so ...
after a reboot, my
On Wed, Jun 13, 2007 at 11:28:52AM +0100, Luis Matos wrote:
The current system is fine but:
- priority from unstable should less than testing or stable ( as i
think - not for sure - happens nowadays). On experimental has less
priority.
- There are no guaranties that testing is
On 6/12/07, Steve Langasek [EMAIL PROTECTED] wrote:
On Tue, Jun 12, 2007 at 04:40:54PM -0300, Gustavo Franco wrote:
* What do you mean by switch unstable automatic nature to not
automatic
In a few words, move the 'NotAutomatic: yes' from experimental to
unstable and burn experimental.
So
Gustavo Franco [EMAIL PROTECTED] writes:
On 6/12/07, Steve Langasek [EMAIL PROTECTED] wrote:
On Tue, Jun 12, 2007 at 04:40:54PM -0300, Gustavo Franco wrote:
* What do you mean by switch unstable automatic nature to not
automatic
In a few words, move the 'NotAutomatic: yes' from experimental
On 13/06/07 at 11:19 +0200, Andreas Barth wrote:
* Lucas Nussbaum ([EMAIL PROTECTED]) [070612 23:17]:
On 12/06/07 at 22:23 +0200, Luk Claes wrote:
NO!
unstable is meant for packages that should be in the next stable release,
as such only packages that are in the maintainer's
On Wed, Jun 13, 2007 at 08:02:53AM -0300, Gustavo Franco wrote:
On 6/12/07, Steve Langasek [EMAIL PROTECTED] wrote:
On Tue, Jun 12, 2007 at 04:40:54PM -0300, Gustavo Franco wrote:
* What do you mean by switch unstable automatic nature to not
automatic
In a few words, move the
Lucas Nussbaum [EMAIL PROTECTED] writes:
On 13/06/07 at 11:19 +0200, Andreas Barth wrote:
* Lucas Nussbaum ([EMAIL PROTECTED]) [070612 23:17]:
On 12/06/07 at 22:23 +0200, Luk Claes wrote:
unstable is meant for packages that should be in the next stable release,
as such only packages that are
* Gustavo Franco [Mon, 11 Jun 2007 18:20:17 -0300]:
* Switch unstable (release) for not automatic updates
This seems like the key of your proposal, and this is, in simple words
and AIUI, why it would not bring any improvements:
- Our main objective is to have as few bugs in testing as
On 6/13/07, Lucas Nussbaum [EMAIL PROTECTED] wrote:
It would be easy to get the list of packages that haven't reached
testing in the n months (and have been in debian for more than n months).
Such a list exists:
http://bjorn.haxx.se/debian/oldest.html
--
bye,
pabs
On 13/06/07 at 15:19 +0100, Paul Wise wrote:
On 6/13/07, Lucas Nussbaum [EMAIL PROTECTED] wrote:
It would be easy to get the list of packages that haven't reached
testing in the n months (and have been in debian for more than n months).
Such a list exists:
Lucas Nussbaum [EMAIL PROTECTED] writes:
On 13/06/07 at 15:19 +0100, Paul Wise wrote:
On 6/13/07, Lucas Nussbaum [EMAIL PROTECTED] wrote:
It would be easy to get the list of packages that haven't reached
testing in the n months (and have been in debian for more than n months).
Such a list
Le mardi 12 juin 2007 à 17:40 -0300, Gustavo Franco a écrit :
I disagree, that's what we've with experimental today mainly due to
the fact that there's just a few packages there. Consider everybody
uploading every package for unstable instead.
This has already been tried by Fedora and
Qua, 2007-06-13 às 03:45 -0700, Steve Langasek escreveu:
On Wed, Jun 13, 2007 at 11:28:52AM +0100, Luis Matos wrote:
look ... i don't want guaranties ... you know what i mean ... want a
place where it says testing HAS security support, we focus on having it
stable. I don't want written
Qua, 2007-06-13 às 12:39 +0200, Gabor Gombas escreveu:
On Wed, Jun 13, 2007 at 11:28:52AM +0100, Luis Matos wrote:
kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in
time (they are not free, right?) ... kernel passes to testing ...
automatically, the
Luis Matos [EMAIL PROTECTED] writes:
but why should I??? this goes against the testing is always *WORKING*
phrase. TESTING IS NOT ALWAYS WORKING.
Having to use module-assistant != not working.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
To
Qua, 2007-06-13 às 14:16 -0700, Russ Allbery escreveu:
Luis Matos [EMAIL PROTECTED] writes:
but why should I??? this goes against the testing is always *WORKING*
phrase. TESTING IS NOT ALWAYS WORKING.
Having to use module-assistant != not working.
having a working system *with* only
Luis Matos [EMAIL PROTECTED] writes:
having a working system *with* only debian *oficial* packages and then
after an upgrade that system stops working properly, i call it a
regression ...
If you're using non-free drivers, the first part of your sentence above
doesn't apply.
Usually, however,
On Wed, Jun 13, 2007 at 03:00:15PM -0700, Russ Allbery wrote:
Many non-free drivers (and some free drivers, for that matter) are never
automatically built at the moment, although with the new mechanism for
building modules in main, hopefully that number will drop over time for
the free ones.
Luis Matos wrote:
Qua, 2007-06-13 às 14:16 -0700, Russ Allbery escreveu:
Luis Matos [EMAIL PROTECTED] writes:
but why should I??? this goes against the testing is always *WORKING*
phrase. TESTING IS NOT ALWAYS WORKING.
Having to use module-assistant != not working.
having a working
Steinar H Gunderson [EMAIL PROTECTED] writes:
On Wed, Jun 13, 2007 at 03:00:15PM -0700, Russ Allbery wrote:
Many non-free drivers (and some free drivers, for that matter) are
never automatically built at the moment, although with the new
mechanism for building modules in main, hopefully that
Russ Allbery [EMAIL PROTECTED] writes:
Steinar H Gunderson [EMAIL PROTECTED] writes:
On Wed, Jun 13, 2007 at 03:00:15PM -0700, Russ Allbery wrote:
Many non-free drivers (and some free drivers, for that matter) are
never automatically built at the moment, although with the new
mechanism for
Qua, 2007-06-13 às 15:00 -0700, Russ Allbery escreveu:
Luis Matos [EMAIL PROTECTED] writes:
having a working system *with* only debian *oficial* packages and then
after an upgrade that system stops working properly, i call it a
regression ...
If you're using non-free drivers, the first
* Joey Hess [EMAIL PROTECTED], [2007-06-11 19:56 -0400]:
Testing also needs periodic snapshots and guaranteed upgradability to
be useable by more users, amoung other points I discuss at
http://kitenet.net/~joey/code/debian/cut/
Snapshots should be made available regularly, so that users who
Qua, 2007-06-13 às 18:09 -0400, Felipe Sateler escreveu:
Luis Matos wrote:
Qua, 2007-06-13 às 14:16 -0700, Russ Allbery escreveu:
Luis Matos [EMAIL PROTECTED] writes:
but why should I??? this goes against the testing is always *WORKING*
phrase. TESTING IS NOT ALWAYS WORKING.
Qui, 2007-06-14 às 01:04 +0200, Emanuele Rocca escreveu:
* Joey Hess [EMAIL PROTECTED], [2007-06-11 19:56 -0400]:
Testing also needs periodic snapshots and guaranteed upgradability to
be useable by more users, amoung other points I discuss at
http://kitenet.net/~joey/code/debian/cut/
Luis Matos [EMAIL PROTECTED] writes:
Qua, 2007-06-13 às 15:00 -0700, Russ Allbery escreveu:
My recommendation is to always use module-assistant for all non-free
drivers that you want to use. That way, if there is a build in
non-free, you can be pleasantly surprised, but your normal method
On Wed, Jun 13, 2007 at 11:53:24AM +0200, Gabor Gombas wrote:
On Wed, Jun 13, 2007 at 12:42:34AM +0100, Luis Matos wrote:
- Smooth passages are not always smooth (who had a working xorg after
the upgrade for 7, please raise their hands)
AFAIR apart from having to edit a few config files
David Nusinow [EMAIL PROTECTED] writes:
By the time it hit testing it worked pretty well for most people. We
broke a few things, but it was nice for just about everyone. Everyone
except those people using proprietary drivers, but they know they've
already dug their own grave there. If Luis
Qua, 2007-06-13 às 16:18 -0700, Russ Allbery escreveu:
For non-free, this is inevitable without significant changes to the
way
that Debian works that I don't believe will happen. Debian has
provided a
different solution in the form of module-assistant that in my
experience
works great. I
Qua, 2007-06-13 às 19:20 -0400, David Nusinow escreveu:
By the time it hit testing it worked pretty well for most people. We
broke
a few things, but it was nice for just about everyone. Everyone except
those people using proprietary drivers, but they know they've already
dug
their own grave
On Wed, Jun 13, 2007 at 05:32:01PM +0100, Luis Matos wrote:
Um, no. That does not happen automatically. In rare cases it happens
because the release team has overridden the installability check for a
package, because maintainers have not coordinated their transitions in
unstable
On Mon, 11 Jun 2007 18:20:17 -0300, Gustavo Franco [EMAIL PROTECTED] said:
1) The 'remove experimental' proposal
* Warn developers and contributors[0]
* Remove experimental
* Switch unstable (release) for not automatic updates
This is one of the worst proposals I have seen.
On Mon, Jun 11, 2007 at 07:56:13PM -0400, Joey Hess wrote:
This assumes that experimental is used by a lot of people, which I
doubt, especially given the default apt pins and the numbers above.
There's also the fact that if you remove experimental it's easy enough
for people to set up their
* Joey Hess [EMAIL PROTECTED] [2007-06-11 19:56]:
Gustavo Franco wrote:
* developers and most active contributors are pretty much using only
stable or unstable and not testing.
What's your data?
It is well known that 87.9% of the assertions made by Debian developers in
the mailing
Gustavo Franco wrote:
Sorry, i forgot CUT it looks like a 0 proposal since it came first.
How and when do you plan to start a team for that and have you
considered who from other teams will need to join/agree on the idea?
I don't necessarily start a team for every proposal I make. :-)
I'm
Gustavo Franco wrote:
Let me outline the 'testing' pros and cons from my point of view:
cons
-
* testing metric is too simple, packages are allowed to enter testing
only after a certain period of time has passed no matter if much
people tested it before that and just when they don't
On 6/12/07, Joey Hess [EMAIL PROTECTED] wrote:
Gustavo Franco wrote:
Sorry, i forgot CUT it looks like a 0 proposal since it came first.
How and when do you plan to start a team for that and have you
considered who from other teams will need to join/agree on the idea?
I don't necessarily
Hi Luk,
On 6/12/07, Luk Claes [EMAIL PROTECTED] wrote:
Gustavo Franco wrote:
(...)
* Switch unstable (release) for not automatic updates
They are only automatic as far as the Release Team wants them to be as
explained earlier...
I'm not writing about automatic transition from unstable to
On Tue, Jun 12, 2007 at 10:29:59AM -0300, Gustavo Franco wrote:
Considering that we know that experimental is not a full branch and
there's no migration from experimental to unstable, do you agree then
we could remove experimental and switch unstable automatic nature to
not automatic (release)
Gustavo Franco wrote:
Do you think that the numbers are positive in terms of testing usage,
really? I see the numbers even if not that reliable as proof of my
argument that just a few (almost half if compared with unstable) bug
reporters are actually using testing.
Not better numbers, but
On 6/12/07, Wouter Verhelst [EMAIL PROTECTED] wrote:
On Tue, Jun 12, 2007 at 10:29:59AM -0300, Gustavo Franco wrote:
Considering that we know that experimental is not a full branch and
there's no migration from experimental to unstable, do you agree then
we could remove experimental and
On 6/12/07, Joey Hess [EMAIL PROTECTED] wrote:
Gustavo Franco wrote:
Do you think that the numbers are positive in terms of testing usage,
really? I see the numbers even if not that reliable as proof of my
argument that just a few (almost half if compared with unstable) bug
reporters are
On Tuesday 12 June 2007 21:40, Gustavo Franco wrote:
* What effect do you think removing experimental will have on
unstable? * How do you think it will have that effect?
I think it will have a positive effect if we add 'NotAutomatic: yes'
into unstable release file.
Are you also willing
On Tuesday 12 June 2007 21:51, Gustavo Franco wrote:
I don't get it, as you also realized: unstable _is_ experimental.
No, it most certainly is *not*, and any developers who treat it as such
should be drawn and quartered.
pgpvlthFzQSRb.pgp
Description: PGP signature
On Tue, Jun 12, 2007 at 04:40:54PM -0300, Gustavo Franco wrote:
On 6/12/07, Wouter Verhelst [EMAIL PROTECTED] wrote:
On Tue, Jun 12, 2007 at 10:29:59AM -0300, Gustavo Franco wrote:
Considering that we know that experimental is not a full branch and
there's no migration from experimental to
Gustavo Franco wrote:
On 6/12/07, Joey Hess [EMAIL PROTECTED] wrote:
Gustavo Franco wrote:
Do you think that the numbers are positive in terms of testing usage,
really? I see the numbers even if not that reliable as proof of my
argument that just a few (almost half if compared with unstable)
On 6/12/07, Luk Claes [EMAIL PROTECTED] wrote:
Gustavo Franco wrote:
On 6/12/07, Joey Hess [EMAIL PROTECTED] wrote:
Gustavo Franco wrote:
Do you think that the numbers are positive in terms of testing usage,
really? I see the numbers even if not that reliable as proof of my
argument that
Gustavo Franco wrote:
On 6/12/07, Luk Claes [EMAIL PROTECTED] wrote:
Gustavo Franco wrote:
On 6/12/07, Joey Hess [EMAIL PROTECTED] wrote:
Gustavo Franco wrote:
I don't get it at all why removing experimental would bring us
anything but a
more experimental unstable...
Sure, a more
On 6/12/07, Luk Claes [EMAIL PROTECTED] wrote:
Gustavo Franco wrote:
Hi Luk,
On 6/12/07, Luk Claes [EMAIL PROTECTED] wrote:
Gustavo Franco wrote:
(...)
* Switch unstable (release) for not automatic updates
They are only automatic as far as the Release Team wants them to be as
Gustavo Franco wrote:
Hi Luk,
On 6/12/07, Luk Claes [EMAIL PROTECTED] wrote:
Gustavo Franco wrote:
(...)
* Switch unstable (release) for not automatic updates
They are only automatic as far as the Release Team wants them to be as
explained earlier...
I'm not writing about automatic
On 6/12/07, Frans Pop [EMAIL PROTECTED] wrote:
On Tuesday 12 June 2007 21:40, Gustavo Franco wrote:
* What effect do you think removing experimental will have on
unstable? * How do you think it will have that effect?
I think it will have a positive effect if we add 'NotAutomatic: yes'
On Tue, Jun 12, 2007 at 05:32:21PM -0300, Gustavo Franco wrote:
On 6/12/07, Luk Claes [EMAIL PROTECTED] wrote:
NO!
unstable is meant for packages that should be in the next stable
release, as such only packages that are in the maintainer's opinion
ready to migrate to testing should be
On Tue, Jun 12, 2007 at 05:25:59PM -0300, Gustavo Franco wrote:
Promote 'quite probably broken in some ways' stuff isn't the motto.
Upload everything that we've in experimental actually seems to be more
appropriate.
Eh, you lost, now. Please go read what experimental is for.
I don't think I
On 12/06/07 at 22:23 +0200, Luk Claes wrote:
NO!
unstable is meant for packages that should be in the next stable release,
as such only packages that are in the maintainer's opinion ready to migrate
to testing should be uploaded to unstable.
Then shouldn't we have a more aggressive policy
Lucas Nussbaum wrote:
On 12/06/07 at 22:23 +0200, Luk Claes wrote:
NO!
unstable is meant for packages that should be in the next stable release,
as such only packages that are in the maintainer's opinion ready to migrate
to testing should be uploaded to unstable.
Then shouldn't we have
On Tue, Jun 12, 2007, Luk Claes wrote:
Making unstable not automatic would
mean less testing of individual versions in unstable AFAICS which is a bad
thing IMHO.
I wonder whether it would make sense to suggest default pinning levels
in Release files to
On Tue June 12 2007 02:25:59 pm Gustavo Franco wrote:
That's the point, you would be using testing for development and
cherry picking changes from unstable manually. Remember that in this
scenario we still have unstable to testing transition so if you don't
push stuff manually it will get
Ter, 2007-06-12 às 22:05 +0200, Frans Pop escreveu:
Personally I think the current system is fine.
just a note, as user:
The current system is fine but:
- priority from unstable should less than testing or stable ( as i
think - not for sure - happens nowadays). On experimental has less
Ter, 2007-06-12 às 23:32 +0200, Vince HK escreveu:
Lucas Nussbaum wrote:
On 12/06/07 at 22:23 +0200, Luk Claes wrote:
NO!
unstable is meant for packages that should be in the next stable release,
as such only packages that are in the maintainer's opinion ready to
migrate
to
On Tue, Jun 12, 2007 at 04:40:54PM -0300, Gustavo Franco wrote:
* What do you mean by switch unstable automatic nature to not
automatic
In a few words, move the 'NotAutomatic: yes' from experimental to
unstable and burn experimental.
So in your opinion, the glibc maintainers should upload
On Wed, Jun 13, 2007 at 12:42:34AM +0100, Luis Matos wrote:
Ter, 2007-06-12 às 22:05 +0200, Frans Pop escreveu:
Personally I think the current system is fine.
just a note, as user:
The current system is fine but:
- priority from unstable should less than testing or stable ( as i
think -
Am Dienstag, den 12.06.2007, 17:25 -0300 schrieb Gustavo Franco:
On 6/12/07, Frans Pop [EMAIL PROTECTED] wrote:
On Tuesday 12 June 2007 21:40, Gustavo Franco wrote:
* What effect do you think removing experimental will have on
unstable? * How do you think it will have that effect?
I would like to ask you interested in our next release to stop and
look at 'testing' for a while. I believe that now, during the start of
a development cycle and during debcamp/debconf we've a interesting
opportunity to review pros and cons of our current approach.
We believe that 'testing'
Gustavo Franco wrote:
* testing metric is too simple, packages are allowed to enter testing
only after a certain period of time has passed no matter if much
people tested it before that and just when they don't have
release-critical bugs filed against them.
Of course we have a team of RMs
On Mon, Jun 11, 2007 at 06:20:17PM -0300, Gustavo Franco wrote:
I would like to ask you interested in our next release to stop and
look at 'testing' for a while. I believe that now, during the start of
a development cycle and during debcamp/debconf we've a interesting
opportunity to review
93 matches
Mail list logo
