On Thu, Oct 7, 2010 at 11:35, Ansgar Burchardt wrote:
> Sandro Tosi writes:
>
>> Just a note that using Send-To requires to add a bug control file to
>> each upload to bpo which I consider a huge overkill solution to that.
>
> reportbug's README.developers.gz suggests to use dpkg's Origin and Bug
Sandro Tosi writes:
> Just a note that using Send-To requires to add a bug control file to
> each upload to bpo which I consider a huge overkill solution to that.
reportbug's README.developers.gz suggests to use dpkg's Origin and Bugs
tags (see deb-control(5)) instead of Send-To. These fields c
On Wed, 06 Oct 2010, Sandro Tosi wrote:
> On Wed, Oct 6, 2010 at 15:33, Stefano Zacchiroli wrote:
> > On Thu, Sep 30, 2010 at 07:01:29PM +0200, Sandro Tosi wrote:
> >> >From a reportbug POV, it's not a big deal to redirect the reports for
> >> bpo packages to something different than sub...@b.d.o.
On Wed, Oct 6, 2010 at 15:33, Stefano Zacchiroli wrote:
> On Thu, Sep 30, 2010 at 07:01:29PM +0200, Sandro Tosi wrote:
>> >From a reportbug POV, it's not a big deal to redirect the reports for
>> bpo packages to something different than sub...@b.d.o. What I need to
>> know is:
>>
>> - the address
On Thu, Sep 30, 2010 at 07:01:29PM +0200, Sandro Tosi wrote:
> >From a reportbug POV, it's not a big deal to redirect the reports for
> bpo packages to something different than sub...@b.d.o. What I need to
> know is:
>
> - the address where to send the bugs
> - a regular expression (bonus points i
Hi all,
On Mon, Sep 27, 2010 at 10:14, Stefano Zacchiroli wrote:
> On Wed, Sep 22, 2010 at 01:19:20PM -0700, Don Armstrong wrote:
>> On Wed, 22 Sep 2010, Stefano Zacchiroli wrote:
>> > From what concerns the BTS, Don's proposal in [2] (the main one, not
>> > the alternative solution) seems reason
On Tue, Sep 28, 2010 at 01:29:46PM +0200, Lucas Nussbaum wrote:
> On 28/09/10 at 09:16 +0200, Stefano Zacchiroli wrote:
> > On Tue, Sep 28, 2010 at 12:37:55AM +0200, Lucas Nussbaum wrote:
> > > > OK, thanks for the clarification. Still, we need to decide—sort of
> > > > now—whether we need to add s
On 28/09/10 at 09:16 +0200, Stefano Zacchiroli wrote:
> On Tue, Sep 28, 2010 at 12:37:55AM +0200, Lucas Nussbaum wrote:
> > > OK, thanks for the clarification. Still, we need to decide—sort of
> > > now—whether we need to add support in reportbug for mailing backport
> > > report bugs to the bpo li
On Tue, Sep 28, 2010 at 12:37:55AM +0200, Lucas Nussbaum wrote:
> > OK, thanks for the clarification. Still, we need to decide—sort of
> > now—whether we need to add support in reportbug for mailing backport
> > report bugs to the bpo list or not (and that might require some time, as
> > someone ne
On 27/09/10 at 10:14 +0200, Stefano Zacchiroli wrote:
> On Wed, Sep 22, 2010 at 01:19:20PM -0700, Don Armstrong wrote:
> > On Wed, 22 Sep 2010, Stefano Zacchiroli wrote:
> > > From what concerns the BTS, Don's proposal in [2] (the main one, not
> > > the alternative solution) seems reasonable to me
On Wed, Sep 22, 2010 at 01:19:20PM -0700, Don Armstrong wrote:
> On Wed, 22 Sep 2010, Stefano Zacchiroli wrote:
> > From what concerns the BTS, Don's proposal in [2] (the main one, not
> > the alternative solution) seems reasonable to me and others in the
> > thread. The proposal also seems to assu
On Thu, 23 Sep 2010, Joerg Jaspert wrote:
> Stepping in sideways here, but in case you can make use of them,
> backports is creating the same debversion info like the main
> archive. Want them synced to the bts?
Yes, please.
Don Armstrong
--
Whatever you do will be insignificant, but it is ver
>> From what concerns the BTS, Don's proposal in [2] (the main one, not
>> the alternative solution) seems reasonable to me and others in the
>> thread. The proposal also seems to assume a different Maintainer
>> field for the bpo package, as hinted above, am I wrong Don?
> Right. The idea here is
On Wed, 22 Sep 2010, Stefano Zacchiroli wrote:
> From what concerns the BTS, Don's proposal in [2] (the main one, not
> the alternative solution) seems reasonable to me and others in the
> thread. The proposal also seems to assume a different Maintainer
> field for the bpo package, as hinted above,
On 22/09/10 13:53, Stefano Zacchiroli wrote:
> Thinking about it, what we _conceptually_ need is pretty simple: a
> mechanism to declare who is the Maintainer of the bpo package and
> enforce its declaration. The responsibility of bpo maintenance will be
> on the declared bpo maintainer. If the def
On Tue, Sep 07, 2010 at 07:46:56AM +0200, Lucas Nussbaum wrote:
> Now that backports are becoming official, I think that it is the right
> time to reconsider the maintenance model of backports. I would
> personally prefer if we had the same rules of packages ownership as for
> normal packages ("nor
On Tue, Sep 07, 2010 at 12:46:12PM -0700, Don Armstrong wrote:
> On Tue, 07 Sep 2010, Steve Langasek wrote:
> > But when someone takes my package and uploads it somewhere other
> > than the main Debian archive, they incur *all* the responsibilities
> > of maintaining that package, including the res
On Wed, Sep 8, 2010 at 3:52 AM, Russ Allbery wrote:
> If there's any complexity in the backport, that's probably true. But I'll
> note here that for all the backports I do for my packages, all the changes
> in the backport are mechanical (and automated) and maintaining that in a
> VCS is just mo
Gerfried Fuchs writes:
> To me the solution is to see the person who does the backport as a part
> of the packaging team. There is the need for having a communication
> channel between the people anyway. Actually more and more packages are
> moved into team maintenance and I'm pretty puzzled abo
Bernd Zeimetz writes:
> On 09/07/2010 05:57 PM, Steve Langasek wrote:
>> I don't think it is. I have no problem with people backporting any of
>> my packages that are useful to them, but I shouldn't have to read bug
>> mail for them. I have enough bugs of my own.
> Chances are good that htese
On Tue, 07 Sep 2010, Steve Langasek wrote:
> But when someone takes my package and uploads it somewhere other
> than the main Debian archive, they incur *all* the responsibilities
> of maintaining that package, including the responsibility of
> appropriately triaging bug reports and forwarding them
On 2010-09-07, Bernd Zeimetz wrote:
> On 09/07/2010 05:57 PM, Steve Langasek wrote:
>> On Tue, Sep 07, 2010 at 11:40:09AM +0200, Holger Levsen wrote:
>>> That I dont think it is. I think you not wanting t be bothered by
>>> backports of your packages is quite an exception,
>>
>> I don't think it
On Tue, Sep 07, 2010 at 07:05:29PM +0200, Bernd Zeimetz wrote:
> On 09/07/2010 05:57 PM, Steve Langasek wrote:
> > On Tue, Sep 07, 2010 at 11:40:09AM +0200, Holger Levsen wrote:
> >> That I dont think it is. I think you not wanting t be bothered by
> >> backports of your packages is quite an except
On Tue, Sep 07, 2010 at 08:35:05PM +0200, Gerfried Fuchs wrote:
> I really would like to see us trying to work together more effectively
> instead of objecting to things right ahead without even knowing wether
> it is such a big relevant deal to make a fuzz about. IMHO it isn't, far
> from it.
We
Lucas Nussbaum schrieb am Tuesday, den 07. September 2010:
Hi,
> > > Alexander Reichle-Schmehl writes ("Backports service becoming official"):
> > > > Because of limitations in the Debian Bug Tracking System, any bugs
> > > > relevant to backporte
Hi!
* Simon McVittie [2010-09-06 19:33:34 CEST]:
> On Mon, 06 Sep 2010 at 17:52:17 +0100, Ian Jackson wrote:
> > What are the BTS limitations ?
>
> I assume the relevant limitation is that in the BTS' data model, each source
> package has a single maintainer, whereas the maintainer of a
Hi,
On Tue, Sep 07, 2010 at 02:38:32PM +0200, Raphael Hertzog wrote:
> On Tue, 07 Sep 2010, Lucas Nussbaum wrote:
> > Now that backports are becoming official, I think that it is the right
> > time to reconsider the maintenance model of backports. I would
> > personally prefer if we had the same r
On 09/07/2010 05:57 PM, Steve Langasek wrote:
> On Tue, Sep 07, 2010 at 11:40:09AM +0200, Holger Levsen wrote:
>> That I dont think it is. I think you not wanting t be bothered by
>> backports of your packages is quite an exception,
>
> I don't think it is. I have no problem with people backporti
On 09/06/2010 10:46 PM, Lucas Nussbaum wrote:
> Now that backports are becoming official, I think that it is the right
> time to reconsider the maintenance model of backports. I would
> personally prefer if we had the same rules of packages ownership as for
> normal packages ("normal" backport main
On Tue, Sep 07, 2010 at 11:40:09AM +0200, Holger Levsen wrote:
> That I dont think it is. I think you not wanting t be bothered by
> backports of your packages is quite an exception,
I don't think it is. I have no problem with people backporting any of my
packages that are useful to them, but I s
On Tue, 07 Sep 2010, Sune Vuorela wrote:
> I'm not planning to ever provide backports of any of my packages, and
> while others are welcome to do it, I do not in any way want to be
> bothered by their bugs or upload emails or anything.
Which would call for filtering, not for keeping the bad status
Hi,
On Tue, 07 Sep 2010, Lucas Nussbaum wrote:
> Now that backports are becoming official, I think that it is the right
> time to reconsider the maintenance model of backports. I would
> personally prefer if we had the same rules of packages ownership as for
> normal packages ("normal" backport ma
Hi,
On Dienstag, 7. September 2010, Sune Vuorela wrote:
> On 2010-09-07, Lucas Nussbaum wrote:
> > Now that backports are becoming official, I think that it is the right
> > time to reconsider the maintenance model of backports. I would
> > personally prefer if we had the same rules of packages o
On 2010-09-07, Lucas Nussbaum wrote:
> Now that backports are becoming official, I think that it is the right
> time to reconsider the maintenance model of backports. I would
> personally prefer if we had the same rules of packages ownership as for
> normal packages ("normal" backport maintainer =
On Tue, Sep 07, 2010 at 07:46:56AM +0200, Lucas Nussbaum wrote:
> Now that backports are becoming official, I think that it is the right
> time to reconsider the maintenance model of backports. I would
> personally prefer if we had the same rules of packages ownership as for
> normal packages ("nor
On Tue, Sep 7, 2010 at 1:46 PM, Lucas Nussbaum wrote:
> Now that backports are becoming official, I think that it is the right
> time to reconsider
Some other possibilities;
Move *-backports (and *-volatile) into the main archive like they are in Ubuntu.
Merge the backports website into www.de
On Tue, Sep 07, 2010 at 07:46:56AM +0200, Lucas Nussbaum wrote:
> On 06/09/10 at 20:32 +0300, Andrei Popescu wrote:
> > On Lu, 06 sep 10, 17:52:17, Ian Jackson wrote:
> > > Alexander Reichle-Schmehl writes ("Backports service becoming official"):
> > > >
On 06/09/10 at 20:32 +0300, Andrei Popescu wrote:
> On Lu, 06 sep 10, 17:52:17, Ian Jackson wrote:
> > Alexander Reichle-Schmehl writes ("Backports service becoming official"):
> > > Because of limitations in the Debian Bug Tracking System, any bugs
> > > relev
On 09/06/2010 07:33 PM, Simon McVittie wrote:
> On Mon, 06 Sep 2010 at 17:52:17 +0100, Ian Jackson wrote:
>> Alexander Reichle-Schmehl writes ("Backports service becoming official"):
>>> Because of limitations in the Debian Bug Tracking System, any bugs
>>>
On Mon, 06 Sep 2010 at 17:52:17 +0100, Ian Jackson wrote:
> Alexander Reichle-Schmehl writes ("Backports service becoming official"):
> > Because of limitations in the Debian Bug Tracking System, any bugs
> > relevant to backported packages still have to be reported to th
On Lu, 06 sep 10, 17:52:17, Ian Jackson wrote:
> Alexander Reichle-Schmehl writes ("Backports service becoming official"):
> > Because of limitations in the Debian Bug Tracking System, any bugs
> > relevant to backported packages still have to be reported to the
>
Alexander Reichle-Schmehl writes ("Backports service becoming official"):
> Because of limitations in the Debian Bug Tracking System, any bugs
> relevant to backported packages still have to be reported to the
> debian-backports [3] list, which have now also been moved to
&g
42 matches
Mail list logo
