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 "sli
+++ Matthias Klumpp [2013-06-07 23:50 +0200]:
> 2013/6/7 Tollef Fog Heen :
> > ]] 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
On Tue, Jun 11, 2013 at 11:10:53AM +0200, Cyril Brulebois wrote:
> Chow Loong Jin (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
Chow Loong Jin (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 works.
>
> Tha
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
> > >
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
> >
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
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 sh
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 tha
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" an
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
2013/6/7 Tollef Fog Heen :
> ]] 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 wa
]] 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 shou
* Philipp Kern [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 message
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 turns
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
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 DPA
2013/6/6 Joachim Breitner :
> [..]
> 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 listmas...@lists.debian.org
Archive:
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 an
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.
Genera
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" a
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 versio
22 matches
Mail list logo
