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 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 r
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
[ 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 ar
24 matches
Mail list logo
