12:39 p.m.
Greetings everyone.
Today we have packager groups used in src.fedoraproject.org to allow a
group of people to maintain packages. In the past this has been used for
SIGs/packaging areas. ie, python-packaging-sig or robotics-sig or the
like.
FESCo has been asked about creating company related groups.
( https://pagure.io/fesco/issue/2966 and https://pagure.io/fesco/issue/2929 )
ie, foocorp-sig / foocopr-packagers. These groups would then be used to
help maintain packages that foocorp finds of interest/value.
This would help companies manage the people they pay to contribute.
It would allow them to more easily add/remove employees as time goes on
instead of someone having to go and add/remove someone from a bunch of
packages.
So, I promised to start a thread here about this.
Should such groups require FESCo approval?
If so, what would be requirements to approve/deny?
Should we require some documentation? ie, should the group have to make
a doc/wiki page explaining what it's for and how to reach group owners
in case of problems?
Thoughts?
kevin
12:41 a.m.
On 5/26/23 20:39, Kevin Fenzi wrote:
Greetings everyone.
Today we have packager groups used in src.fedoraproject.org to allow a
group of people to maintain packages. In the past this has been used for
SIGs/packaging areas. ie, python-packaging-sig or robotics-sig or the
like.
Thanks for the notice. Can comment on ticket as well if preferred,
though possibly the tickets should be merged.
FESCo has been asked about creating company related groups.
( https://pagure.io/fesco/issue/2966 and https://pagure.io/fesco/issue/2929 )
ie, foocorp-sig / foocopr-packagers. These groups would then be used to
help maintain packages that foocorp finds of interest/value.
This would help companies manage the people they pay to contribute.
It would allow them to more easily add/remove employees as time goes on
instead of someone having to go and add/remove someone from a bunch of
packages.
So, I promised to start a thread here about this.
Should such groups require FESCo approval?
Probably yes.
If so, what would be requirements to approve/deny?
May need to revise SIG guidelines, it may be helpful for technology
related to a company rather than just company employees since users of
the technology may want to engage in packaging. With increasing
diversity in computer architectures, expect to see a number of
specialized builds.
Encouraging inclusion of packages is good - there are people who may not
be packagers but can do the initial preparation to enable a SIG to adopt
a package. However, want good reviews as well, there may be a
disincentive for thorough reviews just to include a package. May also
be good to run a light weight version of fedora review on packages to
ensure they get updated after they have been included.
Should we require some documentation? ie, should the group have to
make
a doc/wiki page explaining what it's for and how to reach group owners
in case of problems?
Yes. Should also have a list of group members.
Thoughts?
kevin
1:04 a.m.
Am 27.05.2023 um 07:41 schrieb Benson Muite
<benson_muite(a)emailplus.org>:
On 5/26/23 20:39, Kevin Fenzi wrote:
> Greetings everyone.
> ….
> Should we require some documentation? ie, should the group have
to make
> a doc/wiki page explaining what it's for and how to reach group owners
> in case of problems?
>
Yes. Should also have a list of group members.
> Thoughts?
A big yes for documentation. But to get attention and to get included in the Fedora flow
it has to be docs, and definitely not a wiki!
Docs team can / will / is willing to help to set up everything needed.
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
PBoy(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST /UTC+2)
Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast
3:07 a.m.
Il 26/05/23 19:39, Kevin Fenzi ha scritto:
FESCo has been asked about creating company related groups.
( https://pagure.io/fesco/issue/2966 and https://pagure.io/fesco/issue/2929 )
ie, foocorp-sig / foocopr-packagers. These groups would then be used to
help maintain packages that foocorp finds of interest/value.
This would help companies manage the people they pay to contribute.
It would allow them to more easily add/remove employees as time goes on
instead of someone having to go and add/remove someone from a bunch of
packages.
I'd like this to happen. While Fedora users are doing a great job in
maintaining packages in their free time, I think having payed employees
working on this can enhance package quality and overall Fedora stability
in its whole. We just make sure no one is sponsored into packager group
only because they are added to a company group... they still have to
prove their understanding in Fedora packaging guidelines.
I'd say that these groups should be distinguished from SIGs by using a
different suffix, i.e. 'foocorp-corp' for grouping by company interests
in contrast to 'foo-sig' for grouping packages by specific 'foo' area or
'foo' stack.
I would be however against having a group as main admin of packages.
Groups can already be set as main POC for bugs and this is enough, IMO.
The primary maintainer should be a real person, while a group can be set
as admin of a package.
Mattia
4:40 a.m.
On 26/05/2023 19:39, Kevin Fenzi wrote:
Should such groups require FESCo approval?
Yes.
If so, what would be requirements to approve/deny?
All group members must prove that they're familiar with Fedora packaging
guidelines, i.e. they must receive sponsorship through the standard
procedure and not from their employer (may be biased).
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
7:18 a.m.
* Kevin Fenzi:
Today we have packager groups used in src.fedoraproject.org to allow
a
group of people to maintain packages. In the past this has been used for
SIGs/packaging areas. ie, python-packaging-sig or robotics-sig or the
like.
FESCo has been asked about creating company related groups.
( https://pagure.io/fesco/issue/2966 and https://pagure.io/fesco/issue/2929 )
ie, foocorp-sig / foocopr-packagers. These groups would then be used to
help maintain packages that foocorp finds of interest/value.
Will these groups automatically make members part of the packager group?
Or will that be a separate step?
Thanks,
Florian
7:51 a.m.
On 27/05/2023 15:18, Florian Weimer wrote:
* Kevin Fenzi:
> Today we have packager groups used in src.fedoraproject.org to allow a
> group of people to maintain packages. In the past this has been used for
> SIGs/packaging areas. ie, python-packaging-sig or robotics-sig or the
> like.
>
> FESCo has been asked about creating company related groups.
> ( https://pagure.io/fesco/issue/2966 and https://pagure.io/fesco/issue/2929 )
> ie, foocorp-sig / foocopr-packagers. These groups would then be used to
> help maintain packages that foocorp finds of interest/value.
Will these groups automatically make members part of the packager group?
Or will that be a separate step?
I think this can be like that: "To join the foocorp-SIG, packager group membership is
a requirement"
--
Ali Erdinc Koroglu
Intel, SSE | Linux OS Systems Engineering
12:50 a.m.
On Sat, May 27, 2023 at 2:52 PM Ali Erdinc Koroglu
<aekoroglu(a)linux.intel.com> wrote:
On 27/05/2023 15:18, Florian Weimer wrote:
> * Kevin Fenzi:
>
>> Today we have packager groups used in src.fedoraproject.org to allow a
>> group of people to maintain packages. In the past this has been used for
>> SIGs/packaging areas. ie, python-packaging-sig or robotics-sig or the
>> like.
>>
>> FESCo has been asked about creating company related groups.
>> ( https://pagure.io/fesco/issue/2966 and https://pagure.io/fesco/issue/2929 )
>> ie, foocorp-sig / foocopr-packagers. These groups would then be used to
>> help maintain packages that foocorp finds of interest/value.
>
> Will these groups automatically make members part of the packager group?
> Or will that be a separate step?
I think this can be like that: "To join the foocorp-SIG, packager group membership
is a requirement"
IMO, we should not call these SIGs either. I'm not sure exactly what
the naming convention should be, but one thought would be
"corp-maint_<corpname>" (or flip it around if you wish).
e.g., "corp-maint_aiven" for Aiven employees.
--
真実はいつも一つ！/ Always, there's only one truth!
1:49 a.m.
On Mon, 2023-05-29 at 07:50 +0200, Neal Gompa wrote:
On Sat, May 27, 2023 at 2:52 PM Ali Erdinc Koroglu
<aekoroglu(a)linux.intel.com> wrote:
>
>
> On 27/05/2023 15:18, Florian Weimer wrote:
> > * Kevin Fenzi:
> >
> > > Today we have packager groups used in src.fedoraproject.org to allow a
> > > group of people to maintain packages. In the past this has been used for
> > > SIGs/packaging areas. ie, python-packaging-sig or robotics-sig or the
> > > like.
> > >
> > > FESCo has been asked about creating company related groups.
> > > ( https://pagure.io/fesco/issue/2966 and
https://pagure.io/fesco/issue/2929 )
> > > ie, foocorp-sig / foocopr-packagers. These groups would then be used to
> > > help maintain packages that foocorp finds of interest/value.
> >
> > Will these groups automatically make members part of the packager group?
> > Or will that be a separate step?
>
> I think this can be like that: "To join the foocorp-SIG, packager group
membership is a
> requirement"
>
IMO, we should not call these SIGs either. I'm not sure exactly what
the naming convention should be, but one thought would be
"corp-maint_<corpname>" (or flip it around if you wish).
e.g., "corp-maint_aiven" for Aiven employees.
Maybe 'org' in the naming rather than 'corp' as not all businesses and
entities are corps. More
sedate naming and would cover other distros, charities and other groups in general?
Regards
Phil
--
*** Playing the game for the games own sake. ***
Associations:
* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.
WWW: https://kathenas.org
Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg
Twitter: @kathenasorg
Instagram: @kathenasorg
IRC: kathenas
GPG: 724AA9B52F024C8B
1:56 a.m.
On Mon, May 29, 2023 at 8:50 AM Philip Wyett <philip.wyett(a)kathenas.org> wrote:
On Mon, 2023-05-29 at 07:50 +0200, Neal Gompa wrote:
> On Sat, May 27, 2023 at 2:52 PM Ali Erdinc Koroglu
> <aekoroglu(a)linux.intel.com> wrote:
> >
> >
> > On 27/05/2023 15:18, Florian Weimer wrote:
> > > * Kevin Fenzi:
> > >
> > > > Today we have packager groups used in src.fedoraproject.org to allow
a
> > > > group of people to maintain packages. In the past this has been used
for
> > > > SIGs/packaging areas. ie, python-packaging-sig or robotics-sig or
the
> > > > like.
> > > >
> > > > FESCo has been asked about creating company related groups.
> > > > ( https://pagure.io/fesco/issue/2966 and
https://pagure.io/fesco/issue/2929 )
> > > > ie, foocorp-sig / foocopr-packagers. These groups would then be used
to
> > > > help maintain packages that foocorp finds of interest/value.
> > >
> > > Will these groups automatically make members part of the packager group?
> > > Or will that be a separate step?
> >
> > I think this can be like that: "To join the foocorp-SIG, packager group
membership is a
> > requirement"
> >
>
> IMO, we should not call these SIGs either. I'm not sure exactly what
> the naming convention should be, but one thought would be
> "corp-maint_<corpname>" (or flip it around if you wish).
>
> e.g., "corp-maint_aiven" for Aiven employees.
>
>
Maybe 'org' in the naming rather than 'corp' as not all businesses and
entities are corps. More
sedate naming and would cover other distros, charities and other groups in general?
Sure. I'm fine with that. I think it's just important to not call it a
SIG, because it's not a "special interest group" in the sense that we
use it for.
--
*** Playing the game for the games own sake. ***
Associations:
* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.
Right, it's fairly well-known how broad my association in FOSS is too,
so I totally get this point. :)
--
真実はいつも一つ！/ Always, there's only one truth!
2:01 a.m.
On Mon, 2023-05-29 at 08:56 +0200, Neal Gompa wrote:
On Mon, May 29, 2023 at 8:50 AM Philip Wyett
<philip.wyett(a)kathenas.org> wrote:
> On Mon, 2023-05-29 at 07:50 +0200, Neal Gompa wrote:
> > On Sat, May 27, 2023 at 2:52 PM Ali Erdinc Koroglu
> > <aekoroglu(a)linux.intel.com> wrote:
> > >
> > > On 27/05/2023 15:18, Florian Weimer wrote:
> > > > * Kevin Fenzi:
> > > >
> > > > > Today we have packager groups used in src.fedoraproject.org to
allow a
> > > > > group of people to maintain packages. In the past this has been
used for
> > > > > SIGs/packaging areas. ie, python-packaging-sig or robotics-sig
or the
> > > > > like.
> > > > >
> > > > > FESCo has been asked about creating company related groups.
> > > > > ( https://pagure.io/fesco/issue/2966 and
https://pagure.io/fesco/issue/2929 )
> > > > > ie, foocorp-sig / foocopr-packagers. These groups would then be
used to
> > > > > help maintain packages that foocorp finds of interest/value.
> > > >
> > > > Will these groups automatically make members part of the packager
group?
> > > > Or will that be a separate step?
> > >
> > > I think this can be like that: "To join the foocorp-SIG, packager
group membership is a
> > > requirement"
> > >
> >
> > IMO, we should not call these SIGs either. I'm not sure exactly what
> > the naming convention should be, but one thought would be
> > "corp-maint_<corpname>" (or flip it around if you wish).
> >
> > e.g., "corp-maint_aiven" for Aiven employees.
> >
> >
>
> Maybe 'org' in the naming rather than 'corp' as not all businesses
and entities are corps. More
> sedate naming and would cover other distros, charities and other groups in general?
>
Sure. I'm fine with that. I think it's just important to not call it a
SIG, because it's not a "special interest group" in the sense that we
use it for.
Agreed. SIG is not appropriate in this instance.
> --
> *** Playing the game for the games own sake. ***
>
>
> Associations:
>
> * Debian Maintainer (DM)
> * Fedora/EPEL Maintainer.
> * Contributor member of the AlmaLinux foundation.
>
Right, it's fairly well-known how broad my association in FOSS is too,
so I totally get this point. :)
Indeed. A man after my own heart. ;-)
Regards
Phil
--
*** Playing the game for the games own sake. ***
Associations:
* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.
WWW: https://kathenas.org
Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg
Twitter: @kathenasorg
Instagram: @kathenasorg
IRC: kathenas
GPG: 724AA9B52F024C8B
12:20 p.m.
On Mon, May 29, 2023 at 07:49:54AM +0100, Philip Wyett wrote:
On Mon, 2023-05-29 at 07:50 +0200, Neal Gompa wrote:
> On Sat, May 27, 2023 at 2:52 PM Ali Erdinc Koroglu
> <aekoroglu(a)linux.intel.com> wrote:
> >
> >
> > On 27/05/2023 15:18, Florian Weimer wrote:
> > > * Kevin Fenzi:
> > >
> > > > Today we have packager groups used in src.fedoraproject.org to allow
a
> > > > group of people to maintain packages. In the past this has been used
for
> > > > SIGs/packaging areas. ie, python-packaging-sig or robotics-sig or
the
> > > > like.
> > > >
> > > > FESCo has been asked about creating company related groups.
> > > > ( https://pagure.io/fesco/issue/2966 and
https://pagure.io/fesco/issue/2929 )
> > > > ie, foocorp-sig / foocopr-packagers. These groups would then be used
to
> > > > help maintain packages that foocorp finds of interest/value.
> > >
> > > Will these groups automatically make members part of the packager group?
> > > Or will that be a separate step?
> >
> > I think this can be like that: "To join the foocorp-SIG, packager group
membership is a
> > requirement"
Right, packager would be required.
It's worth noting however that new members could easily be added to
the packager group by using the co-maintain process. But thats fine,
IMHO.
> IMO, we should not call these SIGs either. I'm not sure
exactly what
> the naming convention should be, but one thought would be
> "corp-maint_<corpname>" (or flip it around if you wish).
>
> e.g., "corp-maint_aiven" for Aiven employees.
>
>
Maybe 'org' in the naming rather than 'corp' as not all businesses and
entities are corps. More
sedate naming and would cover other distros, charities and other groups in general?
Yeah, org sounds good, thats a great suggestion!
kevin
12:50 p.m.
I'm not necessarily opposed to this, but I'm not sure I'm in favor of
it. It certainly beats a company using a shared account against policy
to allow for multiple maintainers. On the other hand, what are the
practical use cases here? As Kevin and Zbigniew said in
https://pagure.io/fesco/issue/2929 , interest-based groups instead of
employer-based groups seem like a better approach. Seems like the main
place this would be used is when the org is the upstream project, and
even then, an interest-based group open to the broader community seems
more in the Fedora spirit. So to address the specific questions:
Should such groups require FESCo approval?
Yes. These groups should be exceptional cases.
If so, what would be requirements to approve/deny?
The group must represent something for with there is no broader
community interest. (e.g. I'm interesting in maintaining packages
produced by FunnelFiascCorp, but there's no broader FunnelFiasco SIG
because it's not a broader thing like weather or program management)
Should we require some documentation? ie, should the group have to
make
a doc/wiki page explaining what it's for and how to reach group owners
in case of problems?
No, because it won't be maintained. (I'd like to say yes, but I know
better) The fact that it's a group means we can see who the group
members are and thus can figure out how to contact them if needed.
6:21 p.m.
On Mon, May 29, 2023 at 01:50:04PM -0400, Ben Cotton wrote:
I'm not necessarily opposed to this, but I'm not sure I'm
in favor of
it. It certainly beats a company using a shared account against policy
to allow for multiple maintainers. On the other hand, what are the
practical use cases here? As Kevin and Zbigniew said in
https://pagure.io/fesco/issue/2929 , interest-based groups instead of
employer-based groups seem like a better approach. Seems like the main
place this would be used is when the org is the upstream project, and
even then, an interest-based group open to the broader community seems
more in the Fedora spirit. So to address the specific questions:
Yeah, I think some of these groups cross large areas of interest, so
it's hard to say 'xyz sig' because they are interested in a number of
disparite areas.
> Should such groups require FESCo approval?
Yes. These groups should be exceptional cases.
> If so, what would be requirements to approve/deny?
The group must represent something for with there is no broader
community interest. (e.g. I'm interesting in maintaining packages
produced by FunnelFiascCorp, but there's no broader FunnelFiasco SIG
because it's not a broader thing like weather or program management)
> Should we require some documentation? ie, should the group have to make
> a doc/wiki page explaining what it's for and how to reach group owners
> in case of problems?
No, because it won't be maintained. (I'd like to say yes, but I know
better) The fact that it's a group means we can see who the group
members are and thus can figure out how to contact them if needed.
Yeah, thats definitely a good point.
kevin
10:44 a.m.
On 2023-05-29 10:50, Ben Cotton wrote:
I'm not necessarily opposed to this, but I'm not sure I'm
in favor of
it. It certainly beats a company using a shared account against policy
to allow for multiple maintainers. On the other hand, what are the
practical use cases here? As Kevin and Zbigniew said in
https://pagure.io/fesco/issue/2929 , interest-based groups instead of
employer-based groups seem like a better approach. Seems like the main
place this would be used is when the org is the upstream project, and
even then, an interest-based group open to the broader community seems
more in the Fedora spirit. So to address the specific questions:
With my Meta hat on, something like this would be useful for us in a few
ways:
- it makes it easier to onboard new internal folks to help out with
package maintenance
- it generally removes toil and makes it harder to forget to add someone
else as admin to the packages
- it makes tools like the packager dashboard more useful, as we'd be
able to track all packages of interest from a single place
If all the packages that an organization maintains are within the same
space, I agree that a traditional SIG would work better, but that
doesn't make a ton of sense in our specific example. Also, full
disclosure: we actually already have a FAS group (see
https://pagure.io/fedora-infrastructure/issue/10586) that was created a
while ago so that we could make a copr group for packit builds of our
packages (https://copr.fedorainfracloud.org/groups/g/meta/coprs/). We've
refrained from using it for anything else until there's clarity around
desired usage and policies from FESCo.
Cheers
Davide
324
days inactive
329
days old
14 comments
11 participants
participants (11)
-
Ali Erdinc Koroglu -
Ben Cotton -
Benson Muite -
Davide Cavalca -
Florian Weimer -
Kevin Fenzi -
Mattia Verga -
Neal Gompa -
Peter Boy -
Philip Wyett -
Vitaly Zaitsev