#37 Should we need i18n-sig fas group?
Closed: Fixed None Opened 9 years ago by pnemade.

= phenomenon =
This is based on https://lists.fedoraproject.org/pipermail/devel/2014-October/203114.html

some points to discuss
1) Do we need i18n-sig fas group?
2) What should it be used for? CC'ing on i18n bugs, group commit access on i18n packages
3) Adding all i18n package maintainers to i18n-sig
4) Should this be kept small? ( I mean no fonts packages added to i18n-sig) Thus we endup with 162 packages.

As of today https://admin.fedoraproject.org/pkgdb/packager/i18n-team we got 263 packages there of which 101 fonts packages.


I think good to have this one. Also need to set criteria for adding one to the group.

following up from today's meeting:

Replying to [ticket:37 pnemade]:

some points to discuss
1) Do we need i18n-sig fas group?

  • might help with sharing package maintenance load
  • might help for updating a large number of i18n packages together
  • like huge updates for ibus?
  • if we move to i18n-sig, we don't need i18n-team group anymore

2) What should it be used for? CC'ing on i18n bugs, group commit access on i18n packages
3) Adding all i18n package maintainers to i18n-sig
4) Should this be kept small? ( I mean no fonts packages added to i18n-sig) Thus we endup with 162 packages.

As of today https://admin.fedoraproject.org/pkgdb/packager/i18n-team we got 263 packages there of which 101 fonts packages.

the discussion is postponed later to see more input.

  • i18n-sig looks better than i18n-team.
  • tag i18n packages in tagger
  • fonts-sig idea also looks good. but need to decide on it.

Do we have any quick requirement for this?

Discussed this with Pierre-YvesChibon and concluded we don't need i18n-sig FAS group. Below is summary of the discussion

1) i18n-team is a pseudo-user and it is working fine in pkgdb2.

2) we can track packages for i18n-team as https://admin.fedoraproject.org/pkgdb/packager/i18n-team/

3) Benefits that FAS user group can provide are
a) Share ACL's on packages
b) Setup private mailing list. The idea of the private lists is that in case of group the mailing list has the bugzilla account and you'll want to account for potential security bug

4) Concluded that we are less interested in group setup.

Login to comment on this ticket.

Metadata