On Tue, Jun 11, 2013 at 09:15:48AM +0800, Chow Loong Jin wrote:
On Mon, Jun 10, 2013 at 10:43:57PM +0200, Philipp Kern wrote:
Hi,
On Mon, Jun 10, 2013 at 07:56:24PM +0200, Anton Gladky wrote:
So, I think the developer should have a set of tools (including gb and
even slight removal
Chow,
am Tue, Jun 11, 2013 at 09:15:48AM +0800 hast du folgendes geschrieben:
On Mon, Jun 10, 2013 at 07:56:24PM +0200, Anton Gladky wrote:
So, I think the developer should have a set of tools (including gb and
even slight removal commands), which allow him to do the most of
packaging
On Tue, Jun 11, 2013 at 10:29:33AM +0200, Philipp Kern wrote:
Chow,
am Tue, Jun 11, 2013 at 09:15:48AM +0800 hast du folgendes geschrieben:
On Mon, Jun 10, 2013 at 07:56:24PM +0200, Anton Gladky wrote:
So, I think the developer should have a set of tools (including gb and
even
Chow Loong Jin hyper...@debian.org (11/06/2013):
On Tue, Jun 11, 2013 at 10:29:33AM +0200, Philipp Kern wrote:
I said random, not deterministic. Giving back until a certain test
succeeds, for instance. Because some bad code triggers a segfault
on almost every try except that it sometimes
On Tue, Jun 11, 2013 at 11:10:53AM +0200, Cyril Brulebois wrote:
Chow Loong Jin hyper...@debian.org (11/06/2013):
On Tue, Jun 11, 2013 at 10:29:33AM +0200, Philipp Kern wrote:
I said random, not deterministic. Giving back until a certain test
succeeds, for instance. Because some bad code
+++ Matthias Klumpp [2013-06-07 23:50 +0200]:
2013/6/7 Tollef Fog Heen tfh...@err.no:
]] Nicolas Dandrimont
The accepted by DSA part is a bit complicated. We didn't really want to
bother one of the busiest teams in Debian when the software wasn't even
packaged, and, when it came up, I
Thanks all for opinions! From my point of view, this tool will not be
used (hopefully) too often, but sometimes it is really necessary to try
it out before uploading a new source version.
On 06/09/2013 08:44 PM, Kurt Roeckx wrote:
I have very mixed feelings about this. I do in general think
Hi,
On Mon, Jun 10, 2013 at 07:56:24PM +0200, Anton Gladky wrote:
So, I think the developer should have a set of tools (including gb and
even slight removal commands), which allow him to do the most of
packaging work without worrying other teams/developers. And, of course,
those tools should
On Mon, Jun 10, 2013 at 10:43:57PM +0200, Philipp Kern wrote:
Hi,
On Mon, Jun 10, 2013 at 07:56:24PM +0200, Anton Gladky wrote:
So, I think the developer should have a set of tools (including gb and
even slight removal commands), which allow him to do the most of
packaging work without
On Wed, Jun 05, 2013 at 09:10:39PM +0200, Anton Gladky wrote:
Dear all,
I have a proposal to give a permission to all DDs to restart builds on
failing archs e.g. execute gb-command.
I think, most of developers are clever enough to define, whether the
built failed accidentally and needs to
On 13234 March 1977, Philipp Kern wrote:
Which begs the question if build management should be merged into dak
to provide insight about which package is new. Obviously this could
also be a defined interface but if we're going to start to reuse dak's
interfaces for that... maybe not.
Only in
On 2013-06-06 21:42, Paul Tagliamonte wrote:
Well, I don't think adding more kruft to dak is a great idea (I mean,
if
it has to happen, it has to happen), but this really shows that we need
a unified way of passing machine-readable messages between services.
Let's see how the GSoC project
* Philipp Kern pk...@debian.org [2013-06-07 12:26:37 +0200]:
On 2013-06-06 21:42, Paul Tagliamonte wrote:
Well, I don't think adding more kruft to dak is a great idea (I
mean, if
it has to happen, it has to happen), but this really shows that we need
a unified way of passing machine-readable
]] Nicolas Dandrimont
The accepted by DSA part is a bit complicated. We didn't really want to
bother one of the busiest teams in Debian when the software wasn't even
packaged, and, when it came up, I felt that the reception of the idea of
using fedmsg was a bit lukewarm. I think we should be
2013/6/7 Tollef Fog Heen tfh...@err.no:
]] Nicolas Dandrimont
The accepted by DSA part is a bit complicated. We didn't really want to
bother one of the busiest teams in Debian when the software wasn't even
packaged, and, when it came up, I felt that the reception of the idea of
using fedmsg
On Wed, Jun 05, 2013 at 09:10:39PM +0200, Anton Gladky wrote:
I think, most of developers are clever enough to define, whether the
built failed accidentally and needs to be restarted, or it requires
some fixing and uploading new version. It will save time for both DDs
and wb-team.
Generally
Hi,
Am Donnerstag, den 06.06.2013, 12:24 +0200 schrieb Philipp Kern:
On Wed, Jun 05, 2013 at 09:10:39PM +0200, Anton Gladky wrote:
I think, most of developers are clever enough to define, whether the
built failed accidentally and needs to be restarted, or it requires
some fixing and
2013/6/6 Joachim Breitner nome...@debian.org:
[..]
Can this be done using dcut files, just as with other DPA management commands?
That would be fine.
Anton
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
On 2013-06-06 12:40, Joachim Breitner wrote:
if the DPAs get wanna-build support (which I hope) you certainly don’t
want to handle nmu and gb requests for every developer’s pet
repositories, so there will be a need for a general interface. Can this
be done using dcut files, just as with other
On Thu, Jun 06, 2013 at 09:31:12PM +0200, Philipp Kern wrote:
On 2013-06-06 12:40, Joachim Breitner wrote:
Which begs the question if build management should be merged into
dak to provide insight about which package is new. Obviously this
could also be a defined interface but if we're going to
Dear all,
I have a proposal to give a permission to all DDs to restart builds on
failing archs e.g. execute gb-command.
I think, most of developers are clever enough to define, whether the
built failed accidentally and needs to be restarted, or it requires
some fixing and uploading new version.
Am Mittwoch, den 05.06.2013, 21:10 +0200 schrieb Anton Gladky:
Dear all,
I have a proposal to give a permission to all DDs to restart builds on
failing archs e.g. execute gb-command.
I think, most of developers are clever enough to define, whether the
built failed accidentally and needs
22 matches
Mail list logo
