when you work for "open source company" that
>> increasingly uses proprietary software to manage its workflow (to be
>> fair, I think at this point virtually all major companies do this,
>> which more or less demonstrates the amoral nature of these entities).
>> Maybe I&
20/3/30 11:27(e)an, Iñaki Ucar igorleak idatzi zuen:
> On Mon, 30 Mar 2020 at 09:15, Julen Landa Alustiza
> wrote:
>>
>> 20/3/30 08:40(e)an, James Cassell igorleak idatzi zuen:
>>>
>>> On Sun, Mar 29, 2020, at 11:47 PM, Neal Gompa wrote:
>>>> On S
://www.facebook.com/redhatjobs> @redhatjobs
> <https://instagram.com/redhatjobs>
> <https://red.ht/sig>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send
gt; redhatjobs
> <https://www.facebook.com/redhatjobs> @redhatjobs
> <https://instagram.com/redhatjobs>
> <https://red.ht/sig>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an
we can actually use it.
>
> Thanks,
> --Robbie
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://
rg
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorapro
mp;close_status=
lists 50 tickets for the last year and some of them are not actually
pagure issues and some others have attached fixes from the community.
--
Julen Landa Alustiza
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
; https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Julen Landa Alustiza
___
deve
dora
>users is something the Fedora project needs to do.
>
>Felix
>___
>devel mailing list -- devel@lists.fedoraproject.org
>To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>Fedora Code of Conduct:
>https://docs.fedorap
to devel-le...@lists.fedoraproject.org
>Fedora Code of Conduct:
>https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>List Archives:
>https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Julen Lan
d an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> h
continue using pagure for
dist-git, the development costs of pagure.io should be minimal or zero,
since we would be developing it for src.fp.o and other dist-git
instances as well, and then we should just have the maintenance costs.
Are the pagure.io maintenance costs a big burden for CPE? Let share the
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_
- wait for Wednesday and miss the deadline
>
>At this point I think waiting is better, however should we actually
>have the
>freeze on the 29th, as other contributors may planed their stuff
>according to
>the schedule?
Julen Landa Alustiza
__
le, it had been cross mailing test@, devel@,
xen's third party mailing list and some amazon folks with direct CCs.
Is this possible with discourse?
Julen Landa Alustiza
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
Heya,
Currently we have two different pagure instances that hosts different
use cases on them, and different use cases means different requirements,
so first of all, about what use cases we are talking about?
we have src.fp.o for distgit, some pagure.io projects that hosts actual
code develo
(snip)
20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
To me that's the all point of this
process, let's put down what we *really* *really* need and then look at
the different options.
Do we *really* *really* need to compete with other full featured git
forges on features? The ODF
t;
>> On Wed, Jan 29, 2020 at 03:22:25PM +0100, Julen Landa Alustiza wrote:
>> > (snip)
>> >
>> > 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
>> > >To me that's the all point of this process, let's put down what we
>> > >*rea
2020(e)ko urtarrilaren 29(a) 15:56:08 (CET)-(e)an, Clement Verna
-(e)k hau idatzi zuen:
>On Wed, Jan 29, 2020, 15:23 Julen Landa Alustiza
>
>wrote:
>
>> (snip)
>>
>> 20/1/29 14:49(e)an, Clement Verna igorleak idatzi zuen:
>> > To me that's the all poi
need to have,
> but they would make using Pagure much better in my opinion.
>
>
Yeah, I agree, pagure needs a better code reviewing UI
--
Julen Landa Alustiza
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
We don't have any problem to retire open source packages that works
because they don't move to python 3 for example, but at the same time we
hold dead old libraries due to proprietary software.
It looks unfair at least
___
devel mailing list -- devel@
g
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines:
>https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>>
>https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
&g
Heya,
20/2/10 14:46(e)an, Ben Cotton igorleak idatzi zuen:
FESCo is considering[1] the late Change proposal[2] below.
== Summary ==
Proposed changes to the Desktop release criteria for ARM and AArch64
in Fedora 32:
* drop Xfce on 32-bit ARM from release blocking desktops
* add Workstation on AA
From
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/OM7XMMQ57CI6YJUGLPHAYISABIBFBLLD/#VKU3C5JTUTN74VJG3UV6DMQYV2AI2LJI
You can report on bugzilla-ow...@redhat.com
Regards,
20/2/11 14:38(e)an, Michael Cronenworth igorleak idatzi zuen:
Who / Where is the best
discussion.fedoraproject.org could be self hosted, isn't it?
About github, there is a lot of fedora stuff there, imho that should be a
bigger and deeper different discussion.
Anderson, Charles R On Mon, Dec 17, 2018 at 12:14:18PM -0500, Ben Cotton wrote:
> > On Mon, Dec 17, 2018 at 12:01 PM Fabi
HSTS redirects from http to https should just elevate security and not
redirect to a different subdomain.
Altrought it supposes two redirects (http->https and then libravatar ->
www.libravatar.org) that's the correct way for HSTS
Michal Novotny igorleak hau idatzi zuen (2019 ots. 21,
og. 14:51):
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/
Nicolas Mailhot via devel igorleak hau
idatzi zuen (2019 mai. 6, al. 09:59):
Le dimanche 05 mai 2019 à 16:14 -0600, Chris Murphy a écrit :
>
> Right and that's the same with beta testing, which is how bugs like
> this can sometimes not even get found until after release. A lot of
> tests are done
Roberto Ragusa igorleak hau idatzi zuen (2019 mai.
6, al. 15:34):
> On 5/6/19 1:40 PM, Julen Landa Alustiza wrote:
>
> > We found this bug before releasing, but it is not a release blocking bug
> (the upgrade criteria just cover clean n and n-1 upgrading to n+1 and this
> bug
We are not disabling root access entirely, you can log on local console or
use su after loging with a normal user.
After installing server without the proposed changes (that could be great,
but not needed) you can log in with the normal user and use su to scalate
privileges and either change sshd_
Sorry, I'm in mobile and I miss send the draft :S
I'm not sure if it's clear: we don't really need so many constraints on
anaconda. (active root with pass and regular user) or regular user on wheel
group would be enough to elevate privileges on a just installed box remotely
hau idatzi zuen (2019 mai.
17, or. 17:10):
>
>
> On Fri, 17 May 2019 at 10:41, Julen Landa Alustiza
> wrote:
>
>> We are not disabling root access entirely, you can log on local console
>> or use su after loging with a normal user.
>>
>>
> So a lot of sites
omething.
>___
>devel mailing list -- devel@lists.fedoraproject.org
>To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>List Guidelines: https://fedoraproj
Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Julen Landa Alustiza
Julen Landa Alustiza
20/12/4 20:42(e)an, Kevin Fenzi igorleak idatzi zuen:
On Fri, Dec 04, 2020 at 12:45:03AM +0100, Miro Hrončok wrote:
On 12/3/20 4:39 PM, Petr Šabata wrote:
On Thu, Dec 3, 2020 at 4:34 PM Pierre-Yves Chibon wrote:
On Thu, Dec 03, 2020 at 04:16:56PM +0100, Petr Šabata wrote:
Since I don't see
Would be great if we add a deprecation notice (wich could include an EOL
for the symbolic-ref) to git's output while operating on master branch :D
20/12/3 16:53(e)an, Daniel P. Berrangé igorleak idatzi zuen:
On Thu, Dec 03, 2020 at 10:02:34AM -0500, Ben Cotton wrote:
https://fedoraproject.or
Good morning,
20/12/9 23:24(e)an, Kevin Fenzi igorleak idatzi zuen:
On Wed, Dec 09, 2020 at 08:02:45AM +0100, Julen Landa Alustiza wrote:
20/12/4 20:42(e)an, Kevin Fenzi igorleak idatzi zuen:
On Fri, Dec 04, 2020 at 12:45:03AM +0100, Miro Hrončok wrote:
On 12/3/20 4:39 PM, Petr Šabata
On src.fp.o, could we inject a custom message when someone trys to
fetch/clone a master branch via pagure-dist-git ?
Something like "this branch is deprecated, more info on https://foo.bar";
20/12/11 08:15(e)an, Pierre-Yves Chibon igorleak idatzi zuen:
On Thu, Dec 10, 2020 at 10:29:12AM -0800,
20/12/3 03:39(e)an, Dusty Mabe igorleak idatzi zuen:
I 100% would like to get to a point where we rebase to the latest Fedora
major soon after release. As jlebon mentioned earlier this does mean working
harder to get ahead of the curve by adopting a rawhide development stream
(not exposed to
ra does not have yet a system wide change process to even discuss it.
--
Julen Landa Alustiza
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://
my statement continues being valid:
Fedora did not decide anything, partly because there is no any proposal
to change anything yet.
--
Julen Landa Alustiza
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe se
nd an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists
42 matches
Mail list logo
