On Tue, Nov 30, 2021 at 2:41 PM Otto Urpelainen wrote:
>
> Have you considered submitting a link to this to the Koji docs? A while
> ago, I tried to set up a dev Koji environment just by following the
> docs. Having a pointer to this would have been very useful.
No, but that's a good idea!
Ken Dreyer kirjoitti 30.11.2021 klo 20.56:
On Sun, Oct 10, 2021 at 2:33 PM Dan Čermák
wrote:
Maybe we can make a VM image (for KVM/qemu + VirtualBox) with a small
set of Fedora infra, including Koji+Bodhi.
How about a vagrant box or a docker-compose file :)
However, I'm a little worried
Could be useful for me to do too, I'm new to infra as an apprentice.
On Tue, 30 Nov 2021 at 18:57, Ken Dreyer wrote:
> On Sun, Oct 10, 2021 at 2:33 PM Dan Čermák
> wrote:
> > > Maybe we can make a VM image (for KVM/qemu + VirtualBox) with a small
> > > set of Fedora infra, including
On Sun, Oct 10, 2021 at 2:33 PM Dan Čermák
wrote:
> > Maybe we can make a VM image (for KVM/qemu + VirtualBox) with a small
> > set of Fedora infra, including Koji+Bodhi.
>
> How about a vagrant box or a docker-compose file :)
>
> However, I'm a little worried that this might be too fat or not
Hello Otto,
I like the "Web based course" idea alot. I had thought of creating something as
a pod of containerized parts of the whole to be used in a cloud server
environment, or on a single machine and would be a reactive app, or collection
of say.
Anyway, I am very receptive to these ideas,
On Wed, Oct 6, 2021 at 5:21 AM Vít Ondruch wrote:
>
>
> Dne 06. 10. 21 v 9:44 Zbigniew Jędrzejewski-Szmek napsal(a):
> > On Wed, Oct 06, 2021 at 09:39:46AM +0200, Vít Ondruch wrote:
> >> Dne 05. 10. 21 v 18:04 Stephen John Smoogen napsal(a):
> >>> On Tue, 5 Oct 2021 at 11:28, Matthew Miller
>
Vitaly Zaitsev via devel writes:
> On 05/10/2021 18:04, Stephen John Smoogen wrote:
>> So we need a real proposal with an end to end idea of what
>> is being done, what is to be learned, and how it is to be 'watched' by
>> real developers to make sure people are learning things.
>
> Maybe we can
Kevin Fenzi writes:
> Another possible way we could do this is have this setup in our staging
> env. ie, they do the same things, but it's in staging (which we never
> compose anyhow). That has the danger of something being broken in stg
> without us realizing it, or them diverging.
+1 on
Dne 06. 10. 21 v 20:06 Stephen Snow napsal(a):
On Wed, 2021-10-06 at 18:39 +0200, Vít Ondruch wrote:
--snip--
So it
seems we are in agreement with the `dummy-onboarding-` prefix
No, it should be something more appropriate like `entry-level-tutor-`
Keep it coming please :)
or something
, discussing this back and forth, we figured that it might
also
where new coming package maintainer could gradually gain experience
with
the packaging workflows. So the simplest tasks could be:
1) Add changelog entry into onboarding package and open PR with the
change. This would not require too many
On Wed, 2021-10-06 at 18:39 +0200, Vít Ondruch wrote:
--snip--
> So it
> seems we are in agreement with the `dummy-onboarding-` prefix
No, it should be something more appropriate like `entry-level-tutor-`
or something equally as nuetrally offensive. Dummy is a very negative
word with no value
Dne 06. 10. 21 v 15:08 Zbigniew Jędrzejewski-Szmek napsal(a):
On Wed, Oct 06, 2021 at 11:20:47AM +0200, Vít Ondruch wrote:
Dne 06. 10. 21 v 9:44 Zbigniew Jędrzejewski-Szmek napsal(a):
On Wed, Oct 06, 2021 at 09:39:46AM +0200, Vít Ondruch wrote:
Dne 05. 10. 21 v 18:04 Stephen John Smoogen
On Wed, Oct 06, 2021 at 11:20:47AM +0200, Vít Ondruch wrote:
>
> Dne 06. 10. 21 v 9:44 Zbigniew Jędrzejewski-Szmek napsal(a):
> >On Wed, Oct 06, 2021 at 09:39:46AM +0200, Vít Ondruch wrote:
> >>Dne 05. 10. 21 v 18:04 Stephen John Smoogen napsal(a):
> >>>On Tue, 5 Oct 2021 at 11:28, Matthew Miller
that it might
also
where new coming package maintainer could gradually gain experience
with
the packaging workflows. So the simplest tasks could be:
1) Add changelog entry into onboarding package and open PR with the
change. This would not require too many privileges. Alternatively
this
current Fedora
Dne 06. 10. 21 v 9:44 Zbigniew Jędrzejewski-Szmek napsal(a):
On Wed, Oct 06, 2021 at 09:39:46AM +0200, Vít Ondruch wrote:
Dne 05. 10. 21 v 18:04 Stephen John Smoogen napsal(a):
On Tue, 5 Oct 2021 at 11:28, Matthew Miller wrote:
On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via
On 05/10/2021 18:04, Stephen John Smoogen wrote:
So we need a real proposal with an end to end idea of what
is being done, what is to be learned, and how it is to be 'watched' by
real developers to make sure people are learning things.
Maybe we can make a VM image (for KVM/qemu + VirtualBox)
that it might
also
where new coming package maintainer could gradually gain experience
with
the packaging workflows. So the simplest tasks could be:
1) Add changelog entry into onboarding package and open PR with the
change. This would not require too many privileges. Alternatively
this
current
On Wed, Oct 06, 2021 at 09:39:46AM +0200, Vít Ondruch wrote:
>
> Dne 05. 10. 21 v 18:04 Stephen John Smoogen napsal(a):
> >On Tue, 5 Oct 2021 at 11:28, Matthew Miller wrote:
> >>On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote:
> Is this really necessary?
> >>>Yes.
Dne 05. 10. 21 v 18:04 Stephen John Smoogen napsal(a):
On Tue, 5 Oct 2021 at 11:28, Matthew Miller wrote:
On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote:
Is this really necessary?
Yes. Because anyone can add something like this:
%post
rm -rf /
And it will destroy
maintainer could gradually gain experience
with
the packaging workflows. So the simplest tasks could be:
1) Add changelog entry into onboarding package and open PR with the
change. This would not require too many privileges. Alternatively
this
current Fedora contributors might be interested to send such PR
On Tue, Oct 5, 2021 at 11:27 AM Matthew Miller wrote:
>
> On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote:
> > >Is this really necessary?
> >
> > Yes. Because anyone can add something like this:
> > %post
> > rm -rf /
> >
> > And it will destroy the installed system or
On Tue, 5 Oct 2021 at 11:28, Matthew Miller wrote:
>
> On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote:
> > >Is this really necessary?
> >
> > Yes. Because anyone can add something like this:
> > %post
> > rm -rf /
> >
> > And it will destroy the installed system or even
On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote:
> >Is this really necessary?
>
> Yes. Because anyone can add something like this:
> %post
> rm -rf /
>
> And it will destroy the installed system or even the hardware.
Yeah, but... that's not going get through the PR
forth, we figured that it might
> also
> where new coming package maintainer could gradually gain experience
> with
> the packaging workflows. So the simplest tasks could be:
>
> 1) Add changelog entry into onboarding package and open PR with the
> change. This would not req
On Tue, Oct 05, 2021 at 12:28:03PM +0200, Petr Menšík wrote:
> I like the idea.
>
> I think we can even setup tests namespace repo for it, which would
> ensure all content in this package is %doc only. It does not contain
> %post scripts and no executable, unless strictly predefined content.
>
I like the idea.
I think we can even setup tests namespace repo for it, which would
ensure all content in this package is %doc only. It does not contain
%post scripts and no executable, unless strictly predefined content.
That CI repo would have more strict access to ensure newcomers cannot
avoid
Dne 04. 10. 21 v 16:22 Vitaly Zaitsev via devel napsal(a):
On 04/10/2021 10:57, Vít Ondruch wrote:
Recently, there have been a lot of discussions on this list as well
as we have internally about onboarding. During our internal
brainstorming, we were initially discussing that it could be
On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote:
> On 04/10/2021 19:52, Zbigniew Jędrzejewski-Szmek wrote:
> >Is this really necessary?
>
> Yes. Because anyone can add something like this:
> %post
> rm -rf /
>
> And it will destroy the installed system or even the
On Mon, Oct 4, 2021 at 8:58 AM Vít Ondruch wrote:
> Thoughts?
Anything that improves the onboarding
process can only be a good thing.
I would recommend that before going
too deep into weeds that you need a
small group of "non-packagers"(*) to
see if this is the right approach from
their
On 04/10/2021 19:52, Zbigniew Jędrzejewski-Szmek wrote:
Is this really necessary?
Yes. Because anyone can add something like this:
%post
rm -rf /
And it will destroy the installed system or even the hardware.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On Mon, Oct 04, 2021 at 02:42:58PM -0400, Matthew Miller wrote:
> On Mon, Oct 04, 2021 at 05:52:33PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > I like the idea!
> > > We can block such a package from ever appearing in a compose in pungi.
> > Is this really necessary? The package will not be
On Mon, Oct 04, 2021 at 05:52:33PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > I like the idea!
> > We can block such a package from ever appearing in a compose in pungi.
> Is this really necessary? The package will not be open to anyone,
> but only for approved contributors. Malicious
On Mon, Oct 04, 2021 at 10:10:35AM -0700, Kevin Fenzi wrote:
> On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote:
> > Thoughts?
>
> I like the idea!
>
> We can block such a package from ever appearing in a compose in pungi.
Is this really necessary? The package will not be open to
lso be good idea to actually have something such as "onboarding"
> > package, where new coming package maintainer could gradually gain
> > experience with the packaging workflows. So the simplest tasks could
> > be:
> >
> > 1) Add changelog entry into onboar
On Mon, 4 Oct 2021 at 13:25, Josh Boyer wrote:
>
> On Mon, Oct 4, 2021 at 1:10 PM Kevin Fenzi wrote:
> >
> > On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote:
> > > Thoughts?
> >
> > I like the idea!
>
> It's indeed a good idea.
>
> > We can block such a package from ever appearing in
On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote:
> However, discussing this back and forth, we figured that it might
> also be good idea to actually have something such as "onboarding"
> package, where new coming package maintainer could gradually gain
> experie
t from ever appearing in the buildroots. You
wouldn't want someone adding something to it that injected code that
impacted the builds of other packages.
josh
> So, perhaps we seperate it into:
>
>
> open a bug, submit a pr, do a scratch build, look at ci
>
>
> get added a
On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote:
> Thoughts?
I like the idea!
We can block such a package from ever appearing in a compose in pungi.
So, perhaps we seperate it into:
open a bug, submit a pr, do a scratch build, look at ci
get added as commit to onboard
On 04/10/2021 10:57, Vít Ondruch wrote:
Recently, there have been a lot of discussions on this list as well as
we have internally about onboarding. During our internal brainstorming,
we were initially discussing that it could be useful to have some
package one can experiment with without being
This is a great idea.
I've been reading through the new packager documentation this weekend and
attempting to get my first package submitted. It would be really nice if there
was a way to go all the way through the process with a "real" package, but
without effecting anything, to help those who
e some package one can experiment with without being too much
> worried about the result.
>
> However, discussing this back and forth, we figured that it might
> also be good idea to actually have something such as "onboarding"
> package, where new coming package m
discussing that it could be useful
to have some package one can experiment with without being too much
worried about the result.
However, discussing this back and forth, we figured that it might
also be good idea to actually have something such as "onboarding"
package, where new comi
figured that it might also be good idea to
actually have something such as "onboarding" package, where new coming package
maintainer could gradually gain experience with the packaging workflows. So the simplest
tasks could be:
1) Add changelog entry into onboarding package and open PR with
e some package one can experiment with without being too much
> worried about the result.
>
> However, discussing this back and forth, we figured that it might
> also be good idea to actually have something such as "onboarding"
> package, where new coming package m
.
However, discussing this back and forth, we figured that it might also
be good idea to actually have something such as "onboarding" package,
where new coming package maintainer could gradually gain experience with
the packaging workflows. So the simplest tasks could be:
1) Add
45 matches
Mail list logo
