[Mageia-sysadm] perl team alias?

Michael Scherer misc at zarb.org
Wed Aug 17 12:13:43 CEST 2011


Le mercredi 17 août 2011 à 10:11 +0200, Buchan Milne a écrit :
> On Wednesday, 17 August 2011 00:51:48 Michael Scherer wrote:
> > Le dimanche 14 août 2011 à 14:15 +0200, Jerome Quelin a écrit :
> > > hi,
> > > 
> > > up till now, i was the only one taking care of the perl stack within
> > > mageia. however, kharec is joining me in this effort, and i have a
> > > padawan interested to help perl packaging in mageia.
> > > 
> > > to that end, i was wondering whether it'd be possible to have an alias
> > > such as perl at xxx.mageia.org - or whatever scheme you want, i don't
> > > really care. this would allow to assign perl bugs to this alias when
> > > triaging them. or add this alias as cc: to make sure the perl team is
> > > aware of them.
> > > 
> > > i don't want a mailing list, since dev questions, comments and other
> > > should go to -dev.  however, if you have another solution to provide,
> > > let me know!
> > 
> > While I would not be against creating sub team ( because that's what it
> > is ), I would rather have people first think to the various governance
> > issues and problem before proposing a technical solution.
> > 
> > Aliases are obscure per definition, and assigning something to a aliases
> > would mean that most people would not know who is in CC ( especially
> > with regards to our privacy policy ).
> > 
> > We do need to decide who decide a new aliases should be given, and what
> > it entails ( ie, what would perl take in account ? all perl modules ?
> > all perl software ? ). And who decide who goes in the aliases/team.
> > This would also have a impact on the maintainer db at various level,
> > technical and organisational, etc.
> 
> Is there yet a maintainer DB? I would be in favour of a system of maintainer 
> groups, where a group may have multiple maintainers, and multiple packages, 
> and have an alias, and/or aliases for each package in the group, with 
> recipients being the members of the group.

Boklm coded a quick hack in bash for that. 
See around
http://svnweb.mageia.org/adm/puppet/modules/buildsystem/templates/maintdb?view=log

Maybe we should start to think splitting the build system module in
smaller chunks.

I think everybody agreed on having maintainers group, so the next step
is to decide on what that mean exactly, and then to code it. 

> Such a group may also require an owner, who would have the ability to add or 
> remove packages or maintainers.

That would make ldap suitable for that I guess, and would be in favor of
pushing this to ldap rather than bash, but it was easier to do in bash. 

But that still do not solve the issue about team governance, and add the
problem of editing the team ( even if catdap was enhanced for that,
since i18n team is almost auto managed ). 

> > To me, the answer would still be to have auto assignement of CC based on
> > maint db + a subscription database, but so far, no one coded it.
> 
> Well, I would think it *should* be the maintainer database, and just have a 
> postfix alias map for it.

This would put some restriction since the maintainer db is restricted to
maintainers ( ie, not apprentice ) and I think we need a richer system
that does more for bugzilla. IMHO, people that are not maintainers could
be interested into getting notification of bugs on some rpms.

For example :
  - while not wanting to take care of a library, a packager would want
to be notified of error on it, because some of his packages use it

  - while not being packager, a upstream developer could subscribe to
our bugzilla to get notification ( was done at plf for upload on some
package )

  - users who are testers, or advanced users of a software would
subscribe to be able to confirm or test bugs. This also goes with some
ideas of madb, to ease collaboration of users and packagers.

- apprentices, who are not maintainers ( and so cannot be added to the
maint db ), could get bug about rpm they want to help.

So while not everything can be done right now, I think we should keep
those goal in mind when designing the system. Especially make clear what
is the goal of the aliases, and make a way to see who is behind it, and
when to use it, and when to not use it. For example, I am not sure that
assigning a bug to a team is not equivalent to assigning it to no
one :/ 

IMHO, the easiest would be to indeed add group maintainer to the current
code base for maintainer db, and find some way to do auto assignement in
bugzilla. For example, a cron job to modify bugzilla when something is
assigned to triage ?

-- 
Michael Scherer



More information about the Mageia-sysadm mailing list