Re: [OM Cooker] Separate qa mailing list, why?!?!

Hi,

Le vendredi 02 ao=C3=BBt 2013 =C3=A0 09:02 +0200, Rapha=C3=ABl Jadot a =C3=
=A9crit :
>=20
> Le ven. 02 ao=C3=BBt 2013 03:31:01 CEST, David Walser a =C3=A9crit :
> > On 08/01/2013 09:23 PM, Ben Bullard wrote:
> >> Any QA teams work is ultimately public and should be as is ours. Yet a=
ll
> >> organizations at times see a need do do some things privately with a
> >> small work group. This is not new. It is not unusual. The 6/24 .iso is=
 a
> >> prime example of something that most definitely should have been teste=
d
> >> internally before public release. This type of testing can't be done
> >> while communicating on a list open to the public. Do any of you actual=
ly
> >> believe that Fedora or OpenSuSE release an Alpha .iso without internal
> >> QA? I know for a fact that they don't.=20

As a long time contributer on Mandriva, a Mageia founder,
ex-packager/sysadmin and current Fedora member, I can safely tell "Ben,
please stop bullshitting on that for Fedora". But since never ending
titles and vulgarity are far from being a proper way to convince people,
I will back my claims with a link :
https://lists.fedoraproject.org/pipermail/test-announce/2013-May/thread.htm=
l

As you can see, there is announce for explicit testing of test compose
iso before releasing alpha. And there is nothing 'private', anyone can
join the list, download the iso, or read the archive.

There is no nightly iso due to lack of manpower, storage and bandwidth
concern. Like maye the TC are not marketed enough due to manpower and
timing concern ( ie, the time to advertise it widely, it is likely out
of date ).

And the things that are handled privately in Fedora are  :
- security issues, and most of them become public after, thanks to
bugzilla flexibility
- all Board tickets, not public after, due to trac limitation ( and also
becuase no one spent time to fix the limitation, migrate to something
else, etc )
- various discusion of the community working group, a group made to
handle private matters and disagreements.
- puppet infrastructure, due to old technical limitations.=20
( and of course, the various password and private keys, because they are
private )

Among the board issues, there is :
- trademark issues, so kinda required to be handled privately by US laws
and lawyers
- issue with difficult people, so stuff people may not want to be seen
publically

and the remaining are just suggestions and issues that are then
discussed on public irc meeting, or public n some other ways.

For the infrastructure, that's not more complex. Puppet code is private
because it was like this before due to password ( in a time puppet
couldn't separate password from the rest ) and because no one want to
spend time to audit the git repository to know if it can be published
now. The rest of the code is public ( koji, bodhi ), and the new
management system configuration is public as well ( migrating to ansible
). Discussions around infra is on public ml, irc channel is public,
meeting are public.


> >> Hence they both have private
> >> channels of communication for various work groups as do many opensourc=
e
> >> groups, non-profit, for profit business organizations. Again not only =
is
> >> this not unusual it is standard practice.

Private communication channel for something that are toxic and should be
avoided.=20
Private lists are against the concept of transparency and accounting,
and they tend to disengage people from the project. This also create
fear among volunteers that something was decided without them knowing,
and that they are not good enough to know.

This create various management headaches for sysadmins who need to make
sure there is no "leak".=20

And by adding a barrier when someone want to join, this prevent some
people from helping, because each step you had is a step that may
prevent someone from being productive and excited.

So you should have very good reasons to have such private lists in the
first place. And "noise prevention" is not one of those reasons. For
this, there is moderation.

> > Fair enough, but I don't really see the need for the *communication*
> > to be private.  The way Mageia handles it is the actually ISOs
> > themselves, while they are being internally tested by the QA team, are
> > available on a password-protected rsync server, and the passwords are
> > distributed by private e-mail.  All of the actual communication takes
> > place on IRC or an online collaboratively-edited document, both of
> > which are public, although it's mostly just QA team members looking at
> > this communication.

The rsync password stuff is something that should have been avoided, but
I didn't scream loud enough for that. You get nothing by adding
complexity to the process of testing iso except less testers.

>=20
> In fact I agree on most points, however most list are open and=20
> accessible publicly. Per =C3=98yvind and QA team both are hiring good=20
> questions, we need noiseless medium of communications and at the same=20
> time we would need a place where we could see who's who and what's the=
=20
> next step for each team.
>=20
> About Mageia, well they have something better than us which is the=20
> double board mailing list, one private, one public.

The board private ml was created to discuss issues that are sensitive in
practice such as discussing stuff that need to be kept private by law
or by request of people (personal information), see the example of what
is private in Fedora.

AFAIK, that list was almost unused (and given the time I spent on making
it work due to sympa, it kinda retrospectively piss me off), and during
the time I was serving on board, I was waiting on having enough mails to
propose to declassified or something, and there was so few mails that
this was not even something to discuss. I cannot even find archives of
this, so maybe it was not used at all during those years.
=20
Having a glimpse of the volume of the mail on private mls would have
been something I would have pushed to defuse the idea of "there is lots
of stuff going on behind the curtain" if this didn't imply coding on
sympa.=20

> I asked for our council list to be accessible publicly, but it's true=20
> we have to deal with some personal data that have been removed first=20
> and need to clean it before opening to public (but it's still work to=20
> do, and we still lack manpower)
>=20
> Mageia has also a big advantage (which is in other way a disadvantage),=
=20
> most of people leading it live close to each other with the same=20
> language, I participated to some part of the kickoff, and it's far far=
=20
> easier to organize things quickly when you don't have to manage a gap=20
> of 24h of timezone, from Western USA to New Zealand. They have created=
=20
> a company dedicated to Mageia, and can work on its organization mostly=
=20
> every day.

The company is not "dedicated to Mageia", it is "dedicated to make sure
that people in the company can have a job they like after being fired by
Mandriva management and work as they want, with the freedom of working
on Mageia". In practice, Hupstream is selling services around lots of
stuff that are not Mageia ( packaging training, build system deployment,
websites, support on various system, etc ), and that's really outside
Mageia involvement. At most, some members use Mageia as a example of
their work, ie as something to put on the CV. And it was also quite
clear that being part of a company would not have anything more than not
being part.

--=20
Michael Scherer