On Sat, 05 Nov 2016 04:44:05 +0100
Kevin Kofler wrote:
> Kevin Fenzi wrote:
> > Actually we have autosigning all setup, but it needs a fedpkg update
> > flag day. (Which we hope to do after f25 is out). So, it doesn't
> > depend on this feature.
>
> Why does a pure server-side feature (autosig
Kevin Fenzi wrote:
> Actually we have autosigning all setup, but it needs a fedpkg update
> flag day. (Which we hope to do after f25 is out). So, it doesn't depend
> on this feature.
Why does a pure server-side feature (autosigning) need a client (fedpkg)
flag day?
Kevin Kofler
_
Pavel Raiskup wrote:
> On Friday, October 28, 2016 12:17:13 AM CET Kevin Kofler wrote:
>> Users should be using a stable release, not Rawhide. Rawhide is for doing
>> development, it is not meant to be used.
>
> There's hidden potential, then. I would say your statement is way too
> strict anywa
On Wednesday, November 2, 2016 7:27:34 AM CDT Neal Gompa wrote:
> On Wed, Nov 2, 2016 at 6:59 AM, Christian Stadelmann
>
> wrote:
> > One good thing we would gain from using bodhi for rawhide is having all
> > packages signed, especially in Rawhide. Since rawhide is used by
On Wed, 2 Nov 2016 07:27:34 -0400
Neal Gompa wrote:
> On Wed, Nov 2, 2016 at 6:59 AM, Christian Stadelmann
> wrote:
> > One good thing we would gain from using bodhi for rawhide is having
> > all packages signed, especially in Rawhide. Since rawhide is used
> > by deve
On Wed, Nov 2, 2016 at 6:59 AM, Christian Stadelmann
wrote:
> One good thing we would gain from using bodhi for rawhide is having all
> packages signed, especially in Rawhide. Since rawhide is used by developers,
> this is a pretty important thing to do.
That's something that wil
One good thing we would gain from using bodhi for rawhide is having all
packages signed, especially in Rawhide. Since rawhide is used by developers,
this is a pretty important thing to do.
___
devel mailing list -- devel@lists.fedoraproject.org
To
On jueves, 27 de octubre de 2016 10:05:03 AM CDT Matthew Miller wrote:
> On Thu, Oct 27, 2016 at 12:53:27PM +0200, Vít Ondruch wrote:
> > * And probably last think, why the Rawhide should be really exception?
> > Why we should not use Bodhi if we are using it anywhere else?
> &g
On Thu, 27 Oct 2016 12:53:27 +0200
Vít Ondruch wrote:
> Hi all,
>
> I am thinking, why we don't have enabled Bodhi for Rawhide? I know
> that you might think now that I went nut and it is bureaucracy, but
> let me explain.
>
> If I understand it correctly, during sev
On Tue, 1 Nov 2016 08:55:35 -0400
Matthew Miller wrote:
> On Tue, Nov 01, 2016 at 09:20:45AM +, Petr Pisar wrote:
> > >> Already implemented. You can supress test failures by a python
> > >> code in a .rpmlint file in package's dist-git repository.
> > > I can? Where is this documented? Can
On 2016-11-01, Matthew Miller wrote:
> On Tue, Nov 01, 2016 at 09:20:45AM +, Petr Pisar wrote:
>> >> Already implemented. You can supress test failures by a python code in
>> >> a .rpmlint file in package's dist-git repository.
>> > I can? Where is this documented? Can we add a link to that
>>
On Tue, Nov 01, 2016 at 09:20:45AM +, Petr Pisar wrote:
> >> Already implemented. You can supress test failures by a python code in
> >> a .rpmlint file in package's dist-git repository.
> > I can? Where is this documented? Can we add a link to that
> > documentation to the output from Taskotro
On 2016-10-31, Matthew Miller wrote:
> On Mon, Oct 31, 2016 at 04:19:54PM +, Petr Pisar wrote:
>> Already implemented. You can supress test failures by a python code in
>> a .rpmlint file in package's dist-git repository.
>
> I can? Where is this documented? Can we add a link to that
> documen
On Mon, Oct 31, 2016 at 04:19:54PM +, Petr Pisar wrote:
> > Yeah, so I guess "all" is the wrong word. It'd be nice to be able to
> > review and override specific rpmlint errors on a per-package bases (and
> > maybe a process to review those overrides to prevent abuse when there's
> > a real pro
On 2016-10-27, Matthew Miller wrote:
> Yeah, so I guess "all" is the wrong word. It'd be nice to be able to
> review and override specific rpmlint errors on a per-package bases (and
> maybe a process to review those overrides to prevent abuse when there's
> a real problem).
Already implemented. Y
t for it to complete and
> file an update. You also would not be able to do any chain builds.
That's truth, but are mechanisms even now to make this non-problem.
> > Lets use Bodhi for Rawhide, where the submitted update would immediately
> > go into Rawhide, unless maintainer wis
if we are using it anywhere else?
>>> Lets use Bodhi for Rawhide, where the submitted update would
>>> immediately
>>> go into Rawhide, unless maintainer wishes some testing period.
>>> Any comments on this topic?
>>
>> What if we leave Rawhide as
Dne 28.10.2016 v 00:17 Kevin Kofler napsal(a):
>
>> * From time to time, there is necessary to build some framework, which
>> consist of several components which must be released together.
>> Currently, we either temporarily break Rawhide or we are asking for side
>> tag. But why not use koji for
Adam Williamson wrote:
> You can't run several of the checks without some kind of step
> where package builds are grouped somehow. Running depcheck on a single
> package makes no sense; how do you do an API rebuild? The 'depcheck'
> test for any single build that's part of an API bump+rebuild opera
ove
> > to see these checks running in Koji, but there is no support for them
> > and I don't even see the support coming. So enabling Bodhi for Rawhide
> > would give us this opportunity.
>
> Either add these checks to Koji or just do them in a separate, post-build
Vít Ondruch wrote:
> I am thinking, why we don't have enabled Bodhi for Rawhide? I know that
> you might think now that I went nut and it is bureaucracy, but let me
> explain.
>
> If I understand it correctly, during several past years, our build
> process was more stream
On Thu, Oct 27, 2016 at 05:17:59PM +0200, Vít Ondruch wrote:
> Why Koji functionality? If there was Bodhi for Rawhide enabled, then
> this is probably fedpkg extension. E.g. "fedpkg build" knows when the
> build succeeds, then it can immediately follow with "fedpkg
On Thu, Oct 27, 2016 at 08:15:21AM -0700, Adam Williamson wrote:
> > > My concern would be further diluting and already thin QA community
> > > with yet another thing to test.
> > What if updates to Bikeshed which pass all the automated tests were
> > pushed automatically in batches every, say, wee
On Thu, Oct 27, 2016 at 10:48:24AM -0400, Josh Boyer wrote:
> My concern isn't "how do we get Bikeshed tested". It's "how do we
> make sure Rawhide continues to be tested if Bikeshed exists and
> promises to be somehow a more stable rawhide".
Simple: it probably wouldn't.
> Rawhide testing today
On 10/27/2016 08:05 AM, Matthew Miller wrote:
On Thu, Oct 27, 2016 at 12:53:27PM +0200, Vít Ondruch wrote:
* And probably last think, why the Rawhide should be really exception?
Why we should not use Bodhi if we are using it anywhere else?
Lets use Bodhi for Rawhide, where the submitted update
On Thu, 2016-10-27 at 10:37 -0400, Matthew Miller wrote:
> On Thu, Oct 27, 2016 at 10:12:09AM -0400, Josh Boyer wrote:
> > > What if we leave Rawhide as it is, but create the new
> > > somewhat-better-than-Rawhide repo that Dennis Gilmore was talking about
> > > last year, and enable Bodhi on that?
ine to take the
>>> "--type bugfix|enhancement|security" option so that could be passed on
>>> in some way.
>> But I like this one.
> Practically speaking, I'm not quite sure how it'd be carried through --
> is there koji functionality that we're no
On Thu, Oct 27, 2016 at 04:35:17PM +0200, Vít Ondruch wrote:
> This means to go to some unexplored lands. I am not sure I am fan of
> this idea.
> > It might be nice for the "fedpkg build" command line to take the
> > "--type bugfix|enhancement|security" option so that could be passed on
> > in som
On Thu, Oct 27, 2016 at 10:37 AM, Matthew Miller
wrote:
> On Thu, Oct 27, 2016 at 10:12:09AM -0400, Josh Boyer wrote:
>> > What if we leave Rawhide as it is, but create the new
>> > somewhat-better-than-Rawhide repo that Dennis Gilmore was talking about
>> > last year, and enable Bodhi on that? (T
On Thu, Oct 27, 2016 at 10:12:09AM -0400, Josh Boyer wrote:
> > What if we leave Rawhide as it is, but create the new
> > somewhat-better-than-Rawhide repo that Dennis Gilmore was talking about
> > last year, and enable Bodhi on that? (The thing that I very desperately
> > want to be named "Fedora
Dne 27.10.2016 v 16:05 Matthew Miller napsal(a):
> On Thu, Oct 27, 2016 at 12:53:27PM +0200, Vít Ondruch wrote:
>> * And probably last think, why the Rawhide should be really exception?
>> Why we should not use Bodhi if we are using it anywhere else?
>> Lets use Bodhi f
On Thu, Oct 27, 2016 at 10:05 AM, Matthew Miller
wrote:
> On Thu, Oct 27, 2016 at 12:53:27PM +0200, Vít Ondruch wrote:
>> * And probably last think, why the Rawhide should be really exception?
>> Why we should not use Bodhi if we are using it anywhere else?
>> Lets use Bod
On Thu, Oct 27, 2016 at 12:53:27PM +0200, Vít Ondruch wrote:
> * And probably last think, why the Rawhide should be really exception?
> Why we should not use Bodhi if we are using it anywhere else?
> Lets use Bodhi for Rawhide, where the submitted update would immediately
> go into Raw
under your controll when you'll get the side
tag, when it is merged, etc.
>
>> Lets use Bodhi for Rawhide, where the submitted update would immediately
>> go into Rawhide, unless maintainer wishes some testing period.
>>
>> Any comments on this topic?
> Question:
Dne 27.10.2016 v 13:42 Neal Gompa napsal(a):
> On Thu, Oct 27, 2016 at 6:53 AM, Vít Ondruch wrote:
>> Hi all,
>>
>> I am thinking, why we don't have enabled Bodhi for Rawhide? I know that
>> you might think now that I went nut and it is bureaucracy, but let me
&
On Thursday, October 27, 2016 12:53:27 PM CEST Vít Ondruch wrote:
> Hi all,
>
> I am thinking, why we don't have enabled Bodhi for Rawhide? I know that
> you might think now that I went nut and it is bureaucracy,
Not at all to me.
> but let me
> explain.
>
>
On Thu, Oct 27, 2016 at 6:53 AM, Vít Ondruch wrote:
> Hi all,
>
> I am thinking, why we don't have enabled Bodhi for Rawhide? I know that
> you might think now that I went nut and it is bureaucracy, but let me
> explain.
>
> If I understand it correctly, during sev
Hi all,
I am thinking, why we don't have enabled Bodhi for Rawhide? I know that
you might think now that I went nut and it is bureaucracy, but let me
explain.
If I understand it correctly, during several past years, our build
process was more streamlined and we are trying to do the Ra
38 matches
Mail list logo