On Mon, May 02, 2011 at 11:48:27AM -0400, Scott Kitterman wrote:
On Monday, May 02, 2011 07:31:31 AM Lucas Nussbaum wrote:
...
How we deal with freezes is the hard point in this discussion. I'm
personnally in favor of the freeze rolling for 3 months, then fork
frozen and unfreeze rolling
On Monday, May 02, 2011 12:26:05 PM Jan Hauke Rahm wrote:
On Mon, May 02, 2011 at 11:48:27AM -0400, Scott Kitterman wrote:
On Monday, May 02, 2011 07:31:31 AM Lucas Nussbaum wrote:
...
How we deal with freezes is the hard point in this discussion. I'm
personnally in favor of the
On Sun, Mar 28, 2010 at 09:53:56AM +, Philipp Kern wrote:
On 2010-03-28, Wouter Verhelst wou...@grep.be wrote:
With old buildd, it was always possible to add this bug # after the
fact. I don't know what the case is with new buildd/new wanna-build, but
it might be a good idea to look
On Tue, 30 Mar 2010, Wouter Verhelst wrote:
You always have to wait for the BTS confirmation first.
Perhaps it would be nice to talk to the debbugs maintainers and work out
a way in which the BTS can inform wanna-build of a bug number without
buildd admin intervention? Maybe this could work
On Tue, 30 Mar 2010, Raphael Hertzog wrote:
X-Debbugs-Cc and a script should be more than enough, you can
certainly parse the pseudo-headers to find out the packages and the
version. And when you report the bug, you can add a custom
pseudo-header Arch that the BTS would ignore but that your
On Sat, Mar 27, 2010 at 11:13:20PM +0100, Kurt Roeckx wrote:
On Fri, Mar 26, 2010 at 03:11:12PM +0100, Raphael Hertzog wrote:
On Fri, 26 Mar 2010, Marc 'HE' Brockschmidt wrote:
You mean like the existing pages on buildd.debian.org? You just need to
feed them the list of affected packages
On Sat, 27 Mar 2010, Kurt Roeckx wrote:
The BTS supports filing bugs against source packages, so you also
file against the version of the source package. A FTBFS bug is now
almost always reported against the source package, including binNMUs.
That's good for reporting FTBFS but users finding
On Fri, 26 Mar 2010, Sune Vuorela wrote:
On 2010-03-26, Raphael Hertzog hert...@debian.org wrote:
That said I think those transition repositories are going to be more used
(and thus tested) than experimental because they are targeted. Users who
want to test the latest KDE or Gnome will
On 2010-03-28, Wouter Verhelst wou...@grep.be wrote:
With old buildd, it was always possible to add this bug # after the
fact. I don't know what the case is with new buildd/new wanna-build, but
it might be a good idea to look into that...
That hasn't changed. It's mildly annoying though that
On Sun, Mar 28, 2010 at 09:28:43AM +0200, Wouter Verhelst wrote:
On Sat, Mar 27, 2010 at 11:13:20PM +0100, Kurt Roeckx wrote:
On Fri, Mar 26, 2010 at 03:11:12PM +0100, Raphael Hertzog wrote:
On Fri, 26 Mar 2010, Marc 'HE' Brockschmidt wrote:
You mean like the existing pages on
On Sat, 27 Mar 2010 00:09:53 +0100
Stéphane Glondu st...@glondu.net wrote:
3/ some maintainers are too confident that nothing is going to break
And even if they do tests, they cannot do them on all architectures.
With edos-debcheck you can. You simply need to download the relevant
Stéphane Glondu st...@glondu.net writes:
Raphael Hertzog a écrit :
I don't an exhaustive answer but here are some points:
1/ you can't request bin-nmus of reverse-dependencies in experimental
(to verify that all packages build fine with the updated package, and
that's one of the main
On Fri, Mar 26, 2010 at 03:11:12PM +0100, Raphael Hertzog wrote:
On Fri, 26 Mar 2010, Marc 'HE' Brockschmidt wrote:
You mean like the existing pages on buildd.debian.org? You just need to
feed them the list of affected packages to get that.
Good if it can be done with a simple link to
On Fri, Mar 26, 2010 at 12:37:59PM +0100, Alexander Reichle-Schmehl wrote:
Hi!
Neil Williams schrieb:
Wouldn't a simpler method be to identify uploads that inadvertently
impair an ongoing transition and bump that one upload to experimental
or simply tell the DD not to upload to unstable?
[ Bcc debian-release for info, discussion welcome on -devel ]
Hello,
one of our biggest problems is dealing with transitions because they tend
to get interdependant and it's thus very difficult to move packages from
sid to testing. Also many transitions are badly managed by the maintainers
who
[ Not quite sure why you sent it to debian-release when I tried to have the
discussion on -devel only, anyway ]
On Fri, 26 Mar 2010, Philipp Kern wrote:
[ Just a few quick thoughts. ]
On 2010-03-26, Raphael Hertzog hert...@debian.org wrote:
Multiple transitions will still end up mixed in
Raphael Hertzog hert...@debian.org writes:
To resolve the problems I suggest to serialize transitions in sid.
This was already discussed a few times.
First the archive should block package uploads to sid that would be
starting a new transition (defining this in more details is left for
On 2010-03-26, Raphael Hertzog hert...@debian.org wrote:
That said I think those transition repositories are going to be more used
(and thus tested) than experimental because they are targeted. Users who
want to test the latest KDE or Gnome will happily add such a repository if
its sole
On 10:51 Fri 26 Mar , Raphael Hertzog wrote:
To resolve the problems I suggest to serialize transitions in sid.
First the archive should block package uploads to sid that would be
starting a new transition (defining this in more details is left for
later). Instead transitions should be
On Fri, 26 Mar 2010 10:51:43 +0100
Raphael Hertzog hert...@debian.org wrote:
one of our biggest problems is dealing with transitions because they tend
to get interdependant and it's thus very difficult to move packages from
sid to testing. Also many transitions are badly managed by the
Hi!
Neil Williams schrieb:
Wouldn't a simpler method be to identify uploads that inadvertently
impair an ongoing transition and bump that one upload to experimental
or simply tell the DD not to upload to unstable?
[..]
Maybe extending dput functionality to check a file on a central server
[ I find the tone of your mail needlessly aggressive, we're just
discussing an idea at this point and seeing if it's worth investing more
time into it ]
On Fri, 26 Mar 2010, Marc 'HE' Brockschmidt wrote:
No, this can't be defined later. It's a central part. Would any new
binary lead to a
Raphael Hertzog a écrit :
Preparing the transition in experimental is not always done and takes
much more energy than such a system would take.
Why, actually?
I don't an exhaustive answer but here are some points:
1/ you can't request bin-nmus of reverse-dependencies in experimental
(to
Neil Williams a écrit :
I did a form of that for Emdebian Crush (emrecent) which used
edos-debcheck to see if the upload was going to break the repository
prior to making the upload. [...]
Hum... interesting. If an upload is going to break the repository, dak
could indeed ask some kind of
24 matches
Mail list logo
