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
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 yo
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
On Sun, Mar 28, 2010 at 09:53:56AM +, Philipp Kern wrote:
> On 2010-03-28, Wouter Verhelst 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..
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 b
On 2010-03-28, Wouter Verhelst 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 you cannot d
On Fri, 26 Mar 2010, Sune Vuorela wrote:
> On 2010-03-26, Raphael Hertzog 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
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 findin
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 p
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 u
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 t
Stéphane Glondu 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 task in pr
On Sat, 27 Mar 2010 00:09:53 +0100
Stéphane Glondu 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
Packages.gz file. edos
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 co
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 experiment
[ 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 d
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
tha
On Fri, 26 Mar 2010 10:51:43 +0100
Raphael Hertzog 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 maintainers
> who are r
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 2010-03-26, Raphael Hertzog 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 purpose is to contain
Raphael Hertzog 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
> later).
No, this ca
[ 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 wrote:
> > Multiple transitions will still end up mixed in sid if you pus
22 matches
Mail list logo
