Re: Guidelines for packaging projects on Alioth

[Wouter Verhelst]

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, so it is not true that they can be distinguished automatically from
> failures which are not maintainer's problem.

If that were the case, we wouldn't need buildd maintainers.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Stefano Zacchiroli]

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 which are not maintainer's problem. That was the assumption I
was making from your previous replies.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: Guidelines for packaging projects on Alioth

[Wouter Verhelst]

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 between the actual FTBFS and
> the bug report.

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.

> Having the possibility of subscribing to the PTS and receive
> notification of such failure would be far more efficient.

You would still need the manual work to figure the above out.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Stefano Zacchiroli]

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 to the PTS and receive
notification of such failure would be far more efficient.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: Guidelines for packaging projects on Alioth

[Wouter Verhelst]

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 point really is that build failures rarely need maintainer
> > intervention.  Bothering the maintainer with things that do not concern
> > them, therefore, seems of little point to me.
> 
> I try to rephrase my point. If build failures which do not concern
> maintainers can be distinguished from failures that do concern them,
> then we can mail maintainers only about the latter, avoiding bothering
> them with the former.

That's why we have FTBFS bugs.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Stefano Zacchiroli]

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.  Bothering the maintainer with things that do not concern
> them, therefore, seems of little point to me.

I try to rephrase my point. If build failures which do not concern
maintainers can be distinguished from failures that do concern them,
then we can mail maintainers only about the latter, avoiding bothering
them with the former.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: Guidelines for packaging projects on Alioth

[Wouter Verhelst]

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 build failures rarely need maintainer
> > intervention.  Bothering the maintainer with things that do not concern
> > them, therefore, seems of little point to me.
> 
> And of course build failures that the maintainer must solve will result in
> FTBFS bugs (sooner or later). And these will go to the PTS like all the
> bugs.

That's the idea, yes.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Raphael Hertzog]

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 with things that do not concern
> them, therefore, seems of little point to me.

And of course build failures that the maintainer must solve will result in
FTBFS bugs (sooner or later). And these will go to the PTS like all the
bugs.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Wouter Verhelst]

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, indeed, needs to do about that.
> 
> 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 with things that do not concern
them, therefore, seems of little point to me.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Stefano Zacchiroli]

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 failures due to other
reasons, though.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: Guidelines for packaging projects on Alioth

[Wouter Verhelst]

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 many error messages for nothing because the
> maintainer can't help fix the buildd issue.
> 
> I don't know if the situation improved in the last 3 years, would it be
> more reasonable to do that nowadays?

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.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Mike Hommey]

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 keyword for
> > @p.d.o.
> > 
> > If a maintainer wants some special set of keyword, he can still
> > subscribe with his own address.
> 
> But then he will get the mail twice. :-|

He still can choose those keywords he's not subscribed to with the
@p.d.o.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Henning Makholm]

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:
> - decide which keywords they will receive by default (all except bts,
>   bts-control and upload-binary is my choice, and maybe katie-other)

Perhaps we could start by only auto-subscribing the maintainer to a
currently unused keyword, say "pdo". The next step would be to start
redirecting [EMAIL PROTECTED] to that keyword.

Subsequently, services that currently send mail directly to
maintainers could be migrated one by one to send only to the PTS, and
at the same time the relevant keyword could be added to the
auto-subscribe-the-maintainer set.

(I would dearly love to do this with the testing migration notices I
send out from my "trille" cronjob. There are a handful of maintainers
who have asked for a way to opt out, which I have not got around to
hack my own implementation for).

The ideal, I think, would be to centralize in the PTS *all* automatic
emailing to maintainers, such that all everyting be opted into or out
of by a common interface.

(Hm, one may need except Katie mail that gets sent as a result of the
upload that changes the maintainer, but before the PTS gets a chance
to take note of the change. Some thought will be needed here. Perhaps
Katie ought to piggyback a "by the way, the latest maintainer is NNN"
header onto such mail it sends to the PTS - which would also allow the
PTS to take note immediately).

> - 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)

This would appear to be main implementation challenge, yes, but I'm
not sure I agree with your premise.  I think I would find it tedious
to distinguish between "keywords I subscribe to as maintainer" and
"keywords I subscribe to as myself", so I would prefer a solution
where this distinction does not exist, even if it means that I have to
explicitly unsubscribe from packages I let go of.

How about a crude strategy: Whenever the maintainer of the package
changes, the new maintainer automatically gets subscribed to the
default keywords *under his own address* and *iff he has no
subscription at all to the package already*.

The old maintainer does not get unsubscribed (the may still want to
follow the package) but is sent a notice reminding him to unsubscribe
manually if he wants to get rid of the PTS mail.

This would have the advantage of simplicity, both for the implementor
_and_ for the maintainers.

> - in many cases, the maintainer doesn't want the "diff" since there's a
>   dedicated mailing list for that on alioth ... is it OK if we leave the
>   problem up to the maintainer to change the set of keyword accepted ?

That would be the point, wouldn't it? Off the top of my head, I don't
think that version diffs should be a maintainer-default keyword, for
the reason you cite. (But I'm not personally affected by the choice
either way, so my opinion may not be important).

-- 
Henning Makholm   "Larry wants to replicate all the time ... ah, no,
   all I meant was that he likes to have a bang everywhere."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Raphael Hertzog]

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
> subscribe with his own address.

But then he will get the mail twice. :-|

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Mike Hommey]

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)
> > 
> > Isn't that a non issue if you subscribe @p.d.o ?
> 
> I didn't thought of subscribing this email. In this case, yes it's a
> non issue but you have different issue: if the first maintainer
> changes the default keyword he chooses to receive, then the second
> maintainer won't know it and may not receive everything that he expect
> to receive.
> 
> 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
subscribe with his own address.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Raphael Hertzog]

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 package
> affected if many packages are so I've not added this in yet.
> 
> We're sending to our list (as we have been for ages) for now.

Please send to both the PTS and the list. You can use separate group for
the PTS and for the commit list to be sure to miss absolutely nothing.

[bysource]
for_repos = (.*/|)svn/(?P[^/]+)$
for_paths = (desktop/trunk|goodies)/(?P[^/]+)/
bcc_addr = %(package)[EMAIL PROTECTED]
to_fake = %(package)[EMAIL PROTECTED]
show_nonmatching_paths = ignore

[mailinglist]
for_repos = (.*/|)svn/(?P[^/]+)$
for_paths = .*
to_addr = [EMAIL PROTECTED]

This way the PTS may miss some commits done over several packages but the
mailing list will not.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Raphael Hertzog]

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 the
web interface already.

> cu andreas
> [1] I am interested when they do not build package, of course. ;-)

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 many error messages for nothing because the
maintainer can't help fix the buildd issue.

I don't know if the situation improved in the last 3 years, would it be
more reasonable to do that nowadays?

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Raphael Hertzog]

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 this email. In this case, yes it's a non
issue but you have different issue: if the first maintainer changes the
default keyword he chooses to receive, then the second maintainer won't
know it and may not receive everything that he expect to receive.

We would still need a way to reset the set of keyword of this email when
the maintainer changes.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Andreas Metzler]

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 just >10
*useless* mails for every upload I do.

> and when binNMU occur.

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.
cu andreas
[1] I am interested when they do not build package, of course. ;-)
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.(c) Jasper Ffforde


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Simon Huggins]

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 in yet.

We're sending to our list (as we have been for ages) for now.

Simon.

-- 
"I fought in the Korean war, you know.  I killed four men..." - Basil "He
was in the catering corps.  He poisoned them." - Sybil, Fawlty Towers


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Mike Hommey]

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 even for packages where I'm the only
> > > maintainer.
> 
> I subscribe to debian-devel-changes for that. :-)
> 
> On Fri, 21 Apr 2006, Mike Hommey wrote:
> > ... and maintainers should be subscribed to that by default.
> 
> There's room for improvement indeed.
> 
> 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:
> - decide which keywords they will receive by default (all except bts,
>   bts-control and upload-binary is my choice, and maybe katie-other)

I'd say upload-binary should be sent to the maintainer. It helps seing
when stuff are built and uploaded, and when binNMU occur.

> - 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 ?

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Raphael Hertzog]

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 the PTS you don't just get
> everything by default?

Yes, the PTS is not a "developer-only" tool. It's also for users who care
about a specific software in Debian and they certainly don't care about
the diff of the packaging. They do want to know when a new version comes
out and they may help duplicating bugs and so on. But not much more.

(Well, that's the theory, I never did any study of who the subscribers
are)

> I'll go look at adding the PTS to pkg-xfce now anyway.

Thanks!

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Simon Huggins]

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 sample configuration file is provided
> > >   and I can help if you have troubles installing it. 
> > Are you proposing that existing projects that send to a project mailing
> > list should change and send to the PTS and if so can you put forward
> > some reasons?
> No, I'm not proposing that. I'm just asking to send diffs to the PTS
> as well as to the mailing list.
> I even documented that configuration in the sample configuration file.

Sure the config file was clearer on that than your mail certainly.

> 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 the 2-3 packages that are of
> interest to them.

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 the PTS you don't just get
everything by default?

(cf 
http://www.debian.org/doc/manuals/developers-reference/ch-resources.en.html#s-pkg-tracking-system
 )

I'll go look at adding the PTS to pkg-xfce now anyway.

Simon

-- 
... "Did someone say they wanted toast?" -- Talkie Toaster


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Raphael Hertzog]

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 that. :-)

On Fri, 21 Apr 2006, Mike Hommey wrote:
> ... and maintainers should be subscribed to that by default.

There's room for improvement indeed.

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:
- decide which keywords they will receive by default (all except bts,
  bts-control and upload-binary is my choice, and maybe katie-other)
- 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)
- in many cases, the maintainer doesn't want the "diff" since there's a
  dedicated mailing list for that on alioth ... is it OK if we leave the
  problem up to the maintainer to change the set of keyword accepted ?

Of course help to implement it is always welcome...

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Mike Hommey]

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 which do want to receive all the information that the
> > maintainer usually receives.
> 
> 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.

... and maintainers should be subscribed to that by default.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Russ Allbery]

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 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.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Raphael Hertzog]

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 signaling it :)

It's "cvs" yes. I have no plan to introduce a svn keyword... if I change
something here I would replace "cvs" by "vcs" but I'm not sure that people
would understand "vcs" better than "cvs" or "svn". So I might as well keep
cvs and simply document that it is valid for any kind of "version control
system".

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Stefano Zacchiroli]

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 for the info, I will do this for pkg-vim and pkg-ocaml-maint.

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 signaling it :)

Cheers.

[1] 
http://www.debian.org/doc/manuals/developers-reference/ch-resources.en.html#s-pkg-tracking-system

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: Guidelines for packaging projects on Alioth

[Raphael Hertzog]

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 follow the 2-3 packages that are of interest to them.
> 
> But isn't the maintainer automatically subscribed to all messages to the
> PTS?

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.

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.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Frank Küster]

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 the 2-3 packages that are of interest to them.

But isn't the maintainer automatically subscribed to all messages to the
PTS?  This would mean that if the maintainer is set to a mailing list,
the list receives all commit messages.  This deceives the purpose of
having a separate list for commit messages.

For pkg-tetex, we send the commit messages with logs to the maintainer
list - no problem redirecting this to the PTS.  But the full diffs would
only clutter the list and are better in pkg-tetex-commits.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: Guidelines for packaging projects on Alioth

[Raphael Hertzog]

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 troubles installing it. 
> 
> Are you proposing that existing projects that send to a project mailing
> list should change and send to the PTS and if so can you put forward
> some reasons?

No, I'm not proposing that. I'm just asking to send diffs to the PTS as
well as to the mailing list.

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 the 2-3 packages that are of interest to them.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Guidelines for packaging projects on Alioth

[Simon Huggins]

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 existing projects that send to a project mailing
list should change and send to the PTS and if so can you put forward
some reasons?

I'm just curious really.

-- 
Simon  [ [EMAIL PROTECTED] ] *\  "Peace and understanding through  \**
** ]-+-+-+-+-+-+-+-+-[ **\brute force." -- David Parsons  \*
** [  Htag.pl 0.0.22 ] ***\\


signature.asc
Description: Digital signature