On Thu, Apr 27, 2006 at 09:56:06AM -0400, Stefano Zacchiroli wrote:
> On Thu, Apr 27, 2006 at 03:43:47AM +0200, Wouter Verhelst wrote:
> > That's because sometimes it takes that long to find out whether the
> > failure is really the maintainer's problem rather than the buildd
> > admin's.
>
> Ok,
On Thu, Apr 27, 2006 at 03:43:47AM +0200, Wouter Verhelst wrote:
> That's because sometimes it takes that long to find out whether the
> failure is really the maintainer's problem rather than the buildd
> admin's.
Ok, so it is not true that they can be distinguished automatically from
failures whi
On Wed, Apr 26, 2006 at 08:08:50PM -0400, Stefano Zacchiroli wrote:
> On Thu, Apr 27, 2006 at 01:28:09AM +0200, Wouter Verhelst wrote:
> > That's why we have FTBFS bugs.
>
> The efficiency of that is far lower. FTBFS bugs are manually submitted,
> more then once I experienced a gap of weeks betwee
On Thu, Apr 27, 2006 at 01:28:09AM +0200, Wouter Verhelst wrote:
> That's why we have FTBFS bugs.
The efficiency of that is far lower. FTBFS bugs are manually submitted,
more then once I experienced a gap of weeks between the actual FTBFS and
the bug report.
Having the possibility of subscribing
On Wed, Apr 26, 2006 at 03:07:58PM -0400, Stefano Zacchiroli wrote:
> On Mon, Apr 24, 2006 at 07:31:13PM +0200, Wouter Verhelst wrote:
> > > Those cases can be treated differently than failures due to other
> > > reasons, though.
> > Uh, yes; and they are. But that's not the point.
> >
> > The poi
On Mon, Apr 24, 2006 at 07:31:13PM +0200, Wouter Verhelst wrote:
> > Those cases can be treated differently than failures due to other
> > reasons, though.
> Uh, yes; and they are. But that's not the point.
>
> The point really is that build failures rarely need maintainer
> intervention. Botheri
On Mon, Apr 24, 2006 at 11:36:47PM +0200, Raphael Hertzog wrote:
> On Mon, 24 Apr 2006, Wouter Verhelst wrote:
> > > Those cases can be treated differently than failures due to other
> > > reasons, though.
> >
> > Uh, yes; and they are. But that's not the point.
> >
> > The point really is that b
On Mon, 24 Apr 2006, Wouter Verhelst wrote:
> > Those cases can be treated differently than failures due to other
> > reasons, though.
>
> Uh, yes; and they are. But that's not the point.
>
> The point really is that build failures rarely need maintainer
> intervention. Bothering the maintainer
On Mon, Apr 24, 2006 at 09:33:46AM -0400, Stefano Zacchiroli wrote:
> On Sun, Apr 23, 2006 at 02:21:05PM +0200, Wouter Verhelst wrote:
> > Not in my opinion. Most failures I come around are things involving
> > build-dependencies that aren't available yet. There's nothing a
> > maintainer can or, i
On Sun, Apr 23, 2006 at 02:21:05PM +0200, Wouter Verhelst wrote:
> Not in my opinion. Most failures I come around are things involving
> build-dependencies that aren't available yet. There's nothing a
> maintainer can or, indeed, needs to do about that.
Those cases can be treated differently than
On Sat, Apr 22, 2006 at 09:46:08AM +0200, Raphael Hertzog wrote:
> I wanted to do that from the very first day of the PTS but Ryan Murray
> never agreed to send mails on failed build. He said that many
> compilations fail because of a (temporarily) broken buildd and that
> it would generate too man
On Sat, Apr 22, 2006 at 03:29:06PM +0200, Raphael Hertzog
<[EMAIL PROTECTED]> wrote:
> On Sat, 22 Apr 2006, Mike Hommey wrote:
> > > We would still need a way to reset the set of keyword of this
> > > email when the maintainer changes.
> >
> > Or have simpler rules: you can't change the set of key
Scripsit Raphael Hertzog <[EMAIL PROTECTED]>
> I would be in favor of a tighter integration between the PTS and the
> @packages.debian.org email address too for example.
>
> I could implement a default subscription to the PTS for package
> maintainers but you first need to solve several problems:
On Sat, 22 Apr 2006, Mike Hommey wrote:
> > We would still need a way to reset the set of keyword of this email
> > when the maintainer changes.
>
> Or have simpler rules: you can't change the set of keyword for
> @p.d.o.
>
> If a maintainer wants some special set of keyword, he can still
> subsc
On Sat, Apr 22, 2006 at 09:38:53AM +0200, Raphael Hertzog
<[EMAIL PROTECTED]> wrote:
> On Fri, 21 Apr 2006, Mike Hommey wrote:
> > > - when the maintainer changes, we logically need to unsubcribe the
> > > previous. So this must be recorded somewhere. (it's not a
> > > subscription like the others
On Sat, 22 Apr 2006, Simon Huggins wrote:
> On Fri, Apr 21, 2006 at 03:46:36PM +0200, Raphael Hertzog wrote:
> > On Fri, 21 Apr 2006, Simon Huggins wrote:
> > > I'll go look at adding the PTS to pkg-xfce now anyway.
> > Thanks!
>
> Except as discussed on IRC in #alioth it sends to the first packag
On Sat, 22 Apr 2006, Andreas Metzler wrote:
> I guess more people are interested in that, but this should be
> different keyword triggered when debian-release marks a package for
> bin-NMU, but not for the >10 separate uploads.
I tend to agree. In fact I have a wishlist bug to show the bin-nmu on
On Fri, 21 Apr 2006, Mike Hommey wrote:
> > - when the maintainer changes, we logically need to unsubcribe the previous.
> > So this must be recorded somewhere. (it's not a subscription like the
> > others)
>
> Isn't that a non issue if you subscribe @p.d.o ?
I didn't thought of subscribing t
Mike Hommey <[EMAIL PROTECTED]> wrote:
[...]
> I'd say upload-binary should be sent to the maintainer. It helps seing
> when stuff are built and uploaded,
[...]
Hello,
Eh no. I am not interested at all that the gazillion of build-daemons
grab my package and upload it to Debian.[1] For me that's ju
On Fri, Apr 21, 2006 at 03:46:36PM +0200, Raphael Hertzog wrote:
> On Fri, 21 Apr 2006, Simon Huggins wrote:
> > I'll go look at adding the PTS to pkg-xfce now anyway.
> Thanks!
Except as discussed on IRC in #alioth it sends to the first package
affected if many packages are so I've not added this
On Fri, Apr 21, 2006 at 09:01:53AM +0200, Raphael Hertzog <[EMAIL PROTECTED]>
wrote:
> Russ wrote:
> > > In fact, upload notifications (the one that includes the changelog) are
> > > not, so far as I can tell, sent to the maintainer by default and I end up
> > > subscribing to the PTS to get those
On Fri, 21 Apr 2006, Simon Huggins wrote:
> Sure the config file was clearer on that than your mail certainly.
:-)
> Yes this makes more sense now. I must admit I still thought the PTS was
> only really a way to get all the bugs for a package.
>
> Is there a reason that when you subscribe to th
On Thu, Apr 20, 2006 at 08:49:58AM +0200, Raphael Hertzog wrote:
> On Thu, 20 Apr 2006, Simon Huggins wrote:
> > On Wed, Apr 19, 2006 at 11:13:13PM +0200, Raphael Hertzog wrote:
> > > * All existing packaging projects should use svnmailer to send SVN diffs
> > > to the Package Tracking System. A
Russ wrote:
> > In fact, upload notifications (the one that includes the changelog) are
> > not, so far as I can tell, sent to the maintainer by default and I end up
> > subscribing to the PTS to get those even for packages where I'm the only
> > maintainer.
I subscribe to debian-devel-changes for
On Thu, Apr 20, 2006 at 05:27:28PM -0700, Russ Allbery <[EMAIL PROTECTED]>
wrote:
> Raphael Hertzog <[EMAIL PROTECTED]> writes:
>
> > No, this has never been the case. The maintainer gets the bug reports
> > from the BTS directly and the PTS is useful for people who are not the
> > maintainer but
Raphael Hertzog <[EMAIL PROTECTED]> writes:
> No, this has never been the case. The maintainer gets the bug reports
> from the BTS directly and the PTS is useful for people who are not the
> maintainer but which do want to receive all the information that the
> maintainer usually receives.
In fac
On Thu, 20 Apr 2006, Stefano Zacchiroli wrote:
> Meanwhile, which is the PTS keyword that will control the receipt of svn
> commit notifications? Looking at [1] the only one I can figure out is
> "cvs". Can that be generalized and/or "svn" added? I know, it's a really
> minor point, but why not sig
On Thu, Apr 20, 2006 at 11:13:14AM +0200, Raphael Hertzog wrote:
> Furthermore, the PTS has a very fine-grained mechanism to select which
> messages one wants to receive. Thus you can always work around any problem
> by enabling or disabling a specific keyword on a specific subscription.
Thanks fo
On Thu, 20 Apr 2006, Frank Küster wrote:
> > I even documented that configuration in the sample configuration file.
> > That's what I've done with python-modules recently. Some people subscribe
> > to the -commits list because they are very involved in the team and other
> > just use the PTS to fol
Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> I even documented that configuration in the sample configuration file.
> That's what I've done with python-modules recently. Some people subscribe
> to the -commits list because they are very involved in the team and other
> just use the PTS to follow t
On Thu, 20 Apr 2006, Simon Huggins wrote:
> On Wed, Apr 19, 2006 at 11:13:13PM +0200, Raphael Hertzog wrote:
> > * All existing packaging projects should use svnmailer to send SVN diffs
> > to the Package Tracking System. A sample configuration file is provided
> > and I can help if you have tr
On Wed, Apr 19, 2006 at 11:13:13PM +0200, Raphael Hertzog wrote:
> * All existing packaging projects should use svnmailer to send SVN diffs
> to the Package Tracking System. A sample configuration file is provided
> and I can help if you have troubles installing it.
Are you proposing that exi
32 matches
Mail list logo
