8:08 p.m.
At the FESCo meeting that took place on 3/6/2009, it was decided that
on Monday, 3/9/2009, the 'provenpackager' group would be emptied and
repopulated with only sponsors in the 'packager' group, who would be
given user status in the provenpackager group. This was done for a
few reasons:
1) The initial method of seeding the provenpackager group was seen by
some to be arbitrary - any packager who owned 8 or more packages was
admitted to the group without question.
2) Due to 1, the provenpackager group did not have the desired effect
- the removal of ACL's on all but maybe a few packages.
In order for anyone else that is not currently a sponsor to be
admitted to the group, a process very similar to new sponsor
acceptance (however a distinct process) will be put into effect:
1) The user makes their desire to be a member of provenpackager known
to FESCo (they can do this in really any way - mailing list, IRC, file
a ticket, etc)
2) Much as is the process for new sponsors, a discussion will take
place for 1 week on the sponsors list.
3) Based on the input from step 2, FESCo will vote on the individual
in their regular meeting.
Also, any user that becomes a sponsor will also be added to the
'provenpackager' group.
It is anticipated that the volume of requests at first will be
moderately large. This is expected and will be dealt with in the
normal course of business.
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce
3:24 a.m.
Jon Stanley wrote:
At the FESCo meeting that took place on 3/6/2009, it was decided
that
on Monday, 3/9/2009, the 'provenpackager' group would be emptied and
repopulated with only sponsors in the 'packager' group, who would be
given user status in the provenpackager group. This was done for a
few reasons:
1) The initial method of seeding the provenpackager group was seen by
some to be arbitrary - any packager who owned 8 or more packages was
admitted to the group without question.
2) Due to 1, the provenpackager group did not have the desired effect
- the removal of ACL's on all but maybe a few packages.
In order for anyone else that is not currently a sponsor to be
admitted to the group, a process very similar to new sponsor
acceptance (however a distinct process) will be put into effect:
1) The user makes their desire to be a member of provenpackager known
to FESCo (they can do this in really any way - mailing list, IRC, file
a ticket, etc)
2) Much as is the process for new sponsors, a discussion will take
place for 1 week on the sponsors list.
3) Based on the input from step 2, FESCo will vote on the individual
in their regular meeting.
Also, any user that becomes a sponsor will also be added to the
'provenpackager' group.
It is anticipated that the volume of requests at first will be
moderately large. This is expected and will be dealt with in the
normal course of business.
Well. Here's my mail. As secondary arch maintainer (alpha), I'd like to
be added to the provenpackager group - of course...
Merci,
Oliver
9:47 a.m.
Oliver Falk (oliver(a)linux-kernel.at) said:
Well. Here's my mail. As secondary arch maintainer (alpha),
I'd like to
be added to the provenpackager group - of course...
Assuming the alpha team has a full normal secondary arch group (and you're
in it), you shouldn't need provenpackager access.
Bill
10:22 a.m.
On Tue, Mar 10, 2009 at 10:47:08AM -0400, Bill Nottingham wrote:
Oliver Falk (oliver(a)linux-kernel.at) said:
> Well. Here's my mail. As secondary arch maintainer (alpha), I'd like to
> be added to the provenpackager group - of course...
Assuming the alpha team has a full normal secondary arch group (and you're
in it), you shouldn't need provenpackager access.
Wouldn't it be better if secondary arch group member gained their rights
through the provenpackager process, instead of through another process?
And same for releng, security, and QA members?
--
Pat
10:34 a.m.
On Tue, Mar 10, 2009 at 04:22:53PM +0100, Patrice Dumas wrote:
On Tue, Mar 10, 2009 at 10:47:08AM -0400, Bill Nottingham wrote:
> Oliver Falk (oliver(a)linux-kernel.at) said:
> > Well. Here's my mail. As secondary arch maintainer (alpha), I'd like to
> > be added to the provenpackager group - of course...
>
> Assuming the alpha team has a full normal secondary arch group (and you're
> in it), you shouldn't need provenpackager access.
Wouldn't it be better if secondary arch group member gained their rights
through the provenpackager process, instead of through another process?
And same for releng, security, and QA members?
No, because provenpackager is not at the same permission level as those.
josh
10:46 a.m.
On Tue, Mar 10, 2009 at 11:34:53AM -0400, Josh Boyer wrote:
>
>Wouldn't it be better if secondary arch group member gained their rights
>through the provenpackager process, instead of through another process?
>
>And same for releng, security, and QA members?
No, because provenpackager is not at the same permission level as those.
Do you mean that they can also change packages with ACL on? Or are you
referring to something else?
--
Pat
11:42 a.m.
On Tue, Mar 10, 2009 at 04:46:04PM +0100, Patrice Dumas wrote:
On Tue, Mar 10, 2009 at 11:34:53AM -0400, Josh Boyer wrote:
> >
> >Wouldn't it be better if secondary arch group member gained their rights
> >through the provenpackager process, instead of through another process?
> >
> >And same for releng, security, and QA members?
>
> No, because provenpackager is not at the same permission level as those.
Do you mean that they can also change packages with ACL on? Or are you
referring to something else?
None of those groups are CVS ACL groups from what I remember.
The members of some of those groups have cvsadmin, which is higher than
provenpackager. Being a part of those groups does not immediately grant
you cvsadmin priviledges though.
josh
11:55 a.m.
On Tue, Mar 10, 2009 at 12:42:10PM -0400, Josh Boyer wrote:
None of those groups are CVS ACL groups from what I remember.
The members of some of those groups have cvsadmin, which is higher than
provenpackager. Being a part of those groups does not immediately grant
you cvsadmin priviledges though.
So, what I am more or less proposing is that people in these groups
first try to become provenpackager and then can be in the cvsadmin group
based on another process. This would certainly add more transparency,
and allow to know who wants to do QA and help with security and
releng. Of course there are other processes, because access in cvs is
only part of the privileges needed by people in, say, releng, but
access in cvs is one of the required access.
It doesn't necessarily mean that people in these groups have to
be packagers, but that they follow roughly the same trust system
and go through the same gates when it makes sense, as is the case for
the cvs access.
--
Pat
12:13 p.m.
On Tue, Mar 10, 2009 at 05:55:47PM +0100, Patrice Dumas wrote:
On Tue, Mar 10, 2009 at 12:42:10PM -0400, Josh Boyer wrote:
>
> None of those groups are CVS ACL groups from what I remember.
>
> The members of some of those groups have cvsadmin, which is higher than
> provenpackager. Being a part of those groups does not immediately grant
> you cvsadmin priviledges though.
So, what I am more or less proposing is that people in these groups
first try to become provenpackager and then can be in the cvsadmin group
based on another process. This would certainly add more transparency,
and allow to know who wants to do QA and help with security and
releng. Of course there are other processes, because access in cvs is
only part of the privileges needed by people in, say, releng, but
access in cvs is one of the required access.
That sounds somewhat reasonable.
It doesn't necessarily mean that people in these groups have to
be packagers, but that they follow roughly the same trust system
and go through the same gates when it makes sense, as is the case for
the cvs access.
My only issue with your proposal is that it seems to imply people have
magically been granted access to cvsadmin just because they are in a
particular group. I haven't seen that to be the case at all.
There are only 15 people in the cvsadmin group, and each one of them
has been added because they actually do cvsadmin work (as in the
CVSAdmin requests for packages).
There is nobody from the QA team or Security teams in cvsadmin that
I can tell.
josh
5:02 p.m.
On Tue, Mar 10, 2009 at 01:13:48PM -0400, Josh Boyer wrote:
>
>So, what I am more or less proposing is that people in these groups
>first try to become provenpackager and then can be in the cvsadmin group
>based on another process. This would certainly add more transparency,
>and allow to know who wants to do QA and help with security and
>releng. Of course there are other processes, because access in cvs is
>only part of the privileges needed by people in, say, releng, but
>access in cvs is one of the required access.
That sounds somewhat reasonable.
I am not sure, in fact. I think that the infras policies are better.
It is in fact quite reasonable that I know nothing about this group,
that it is not documented in the packagers part, it is for infras.
>It doesn't necessarily mean that people in these groups have
to
>be packagers, but that they follow roughly the same trust system
>and go through the same gates when it makes sense, as is the case for
>the cvs access.
My only issue with your proposal is that it seems to imply people have
magically been granted access to cvsadmin just because they are in a
particular group. I haven't seen that to be the case at all.
In fact I am not implying much. I thought that I missed a packager
group, but in fact it is not the case.
There are only 15 people in the cvsadmin group, and each one of them
has been added because they actually do cvsadmin work (as in the
CVSAdmin requests for packages).
Ok. So this is very different from what I had in mind. It is more
an infra issue, not necessarily relevant to go through provenpackager.
But it is also clearly not the kind of group I was referring to.
This is a good group for established infras people and packagers, but
not for people interested in helping releng, but not already in the
inner circles. People in that case should also go through the
infra/releng procedures, sure, but also going through provenpackager
to be able to do some releng stuff without being in the inner releng
circle is what I had in mind.
There is nobody from the QA team or Security teams in cvsadmin that
I can tell.
So where are they, and isn't provenpackager a good place for most of
them, and maybe even higher for some (in the security group for closed
ACLs)?
--
Pat
5:13 p.m.
On Tue, Mar 10, 2009 at 11:34:53AM -0400, Josh Boyer wrote:
>
>Wouldn't it be better if secondary arch group member gained their rights
>through the provenpackager process, instead of through another process?
>
>And same for releng, security, and QA members?
No, because provenpackager is not at the same permission level as those.
Ok, coming back at that level of the thread, because I was lost afterwards.
What I am saying is that people interested in releng, in secondary arch,
in QA, in security may want to become provenpackager even if they have
not gained the trust of the inner infras/releng circles. That way they can
help for stuff relevant for one of these fields without being fully
involved with infras/releng. For example, fix broken deps, FTBFS, specs for
build on secondary arches, do security stuff, without being formally in
one of those groups.
--
Pat
10:37 a.m.
Patrice Dumas wrote:
On Tue, Mar 10, 2009 at 10:47:08AM -0400, Bill Nottingham wrote:
> Oliver Falk (oliver(a)linux-kernel.at) said:
>> Well. Here's my mail. As secondary arch maintainer (alpha), I'd like to
>> be added to the provenpackager group - of course...
> Assuming the alpha team has a full normal secondary arch group (and you're
> in it), you shouldn't need provenpackager access.
Wouldn't it be better if secondary arch group member gained their rights
through the provenpackager process, instead of through another process?
And same for releng, security, and QA members?
There was a meeting at one point (I think FESCo but I could be wrong)
where the cvsadmin groups was given responsibility for putting new
members in cvsadmin. I believe that this technically covers all the
groups except secondary arches -- who have the same powers but different
groups and different responsibilities.
Just pointing out the history; not necessarily what should be.
-Toshio
12:04 p.m.
On Tue, Mar 10, 2009 at 08:37:29AM -0700, Toshio Kuratomi wrote:
>
There was a meeting at one point (I think FESCo but I could be wrong)
where the cvsadmin groups was given responsibility for putting new
members in cvsadmin. I believe that this technically covers all the
groups except secondary arches -- who have the same powers but different
groups and different responsibilities.
Just pointing out the history; not necessarily what should be.
It is somehow odd to have a complex trust system with many levels
of control (roughly packager -> provenpackager -> sponsor) for
contributors that have less power, while there is no apparent
control/procedure for the cvsadmin group. At least people having
cvsadmin powers granted should be provenpackagers, and maybe
cvsadmin members could be identified and something about them
could be added in the policies pages, be it only a mention to an
informal process to become cvsadmin.
--
Pat
5:05 p.m.
On Tue, Mar 10, 2009 at 06:04:38PM +0100, Patrice Dumas wrote:
On Tue, Mar 10, 2009 at 08:37:29AM -0700, Toshio Kuratomi wrote:
> >
> There was a meeting at one point (I think FESCo but I could be wrong)
> where the cvsadmin groups was given responsibility for putting new
> members in cvsadmin. I believe that this technically covers all the
> groups except secondary arches -- who have the same powers but different
> groups and different responsibilities.
>
> Just pointing out the history; not necessarily what should be.
It is somehow odd to have a complex trust system with many levels
of control (roughly packager -> provenpackager -> sponsor) for
contributors that have less power, while there is no apparent
control/procedure for the cvsadmin group. At least people having
cvsadmin powers granted should be provenpackagers, and maybe
cvsadmin members could be identified and something about them
could be added in the policies pages, be it only a mention to an
informal process to become cvsadmin.
To answer to myself, now that I stand corrected, cvsadmin is outside
of the packager trust system, and in the infras trust system, so it is
right as is (more precisely I don't have an opinion on it).
--
Pat
3:36 a.m.
Jon Stanley wrote:
At the FESCo meeting that took place on 3/6/2009, it was decided
that
on Monday, 3/9/2009, the 'provenpackager' group would be emptied and
repopulated with only sponsors in the 'packager' group, who would be
given user status in the provenpackager group.
Is there some definition of what a "provenpackager role" is supposed to
mean and how it is different from a "sponsor role"?
Ralf
5:07 a.m.
On Tue, Mar 10, 2009 at 09:36:01AM +0100, Ralf Corsepius wrote:
Jon Stanley wrote:
> At the FESCo meeting that took place on 3/6/2009, it was decided that
> on Monday, 3/9/2009, the 'provenpackager' group would be emptied and
> repopulated with only sponsors in the 'packager' group, who would be
> given user status in the provenpackager group.
Is there some definition of what a "provenpackager role" is supposed to
mean and how it is different from a "sponsor role"?
provenpackagers are people who can change all the packages with
opened ACLs. Sponsors are the people who can accept new contributors in
fedora.
--
Pat
5:19 a.m.
Patrice Dumas wrote:
On Tue, Mar 10, 2009 at 09:36:01AM +0100, Ralf Corsepius wrote:
> Jon Stanley wrote:
>> At the FESCo meeting that took place on 3/6/2009, it was decided that
>> on Monday, 3/9/2009, the 'provenpackager' group would be emptied and
>> repopulated with only sponsors in the 'packager' group, who would be
>> given user status in the provenpackager group.
> Is there some definition of what a "provenpackager role" is supposed to
> mean and how it is different from a "sponsor role"?
provenpackagers are people who can change all the packages with
opened ACLs. Sponsors are the people who can accept new contributors in
fedora.
<devil's advocate>
Well, with this definition, "provenpackager" is an acknowledgment of
"technical skills", while "sponsors" is a "social/political
role".
It also doesn't have any connection to the role "sponsors" once used to
have: To guide and educate new-comer packagers.
<devil's advocate>
Ralf
5:41 a.m.
On Tue, 10 Mar 2009 11:19:13 +0100, Ralf wrote:
<devil's advocate>
Well, with this definition, "provenpackager" is an acknowledgment of
"technical skills",
This isn't clear to me yet. Package rebuilds in Rawhide don't need
"technical skills". It's trivial to bump Release and submit build
requests. Unless the person who does that also creates patches and
modifies packages beyond ordinary rebuild attempts. In that case, however,
I wonder where the maintainers of such packages are? Or perhaps the task
of rebuilding is considered as grunt work, and the maintainers explicitly
give their okay in private mail (or on IRC)?
What I'd like to avoid is that some people step in and hide non-responsive
maintainers by updating and upgrading packages without being an official
co-maintainer (or by rebuilding packages in Rawhide without taking care of
open bugzilla tickets).
Understanding what exactly the "provenpackager" membership is used for
would be helpful.
while "sponsors" is a "social/political role".
Sounds questionable. In particular since sponsors must review packages of
a contributor they want to sponsor.
5:57 a.m.
On Tue, Mar 10, 2009 at 11:41:50AM +0100, Michael Schwendt wrote:
On Tue, 10 Mar 2009 11:19:13 +0100, Ralf wrote:
Understanding what exactly the "provenpackager" membership is used for
would be helpful.
Maybe things have changed, but my understanding was that provenpackager
would be the "Experienced packagers" referred to on:
http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToMod...
which also lays out what provenpackagers are allowed to do.
--
Pat
6:03 a.m.
On Tue, 10 Mar 2009 11:57:31 +0100, Patrice wrote:
Maybe things have changed, but my understanding was that
provenpackager
would be the "Experienced packagers" referred to on:
http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToMod...
which also lays out what provenpackagers are allowed to do.
=:-o 1st of April is still weeks away.
Why is there an exception for "Red Hat packagers"?
| Definition of the term "Experienced packagers"
|
| [...]
|
| Red Hat packagers that have been through a number of reviews and
| have been packagers for more than 4 months.
6:12 a.m.
On Tue, Mar 10, 2009 at 12:03:00PM +0100, Michael Schwendt wrote:
On Tue, 10 Mar 2009 11:57:31 +0100, Patrice wrote:
> Maybe things have changed, but my understanding was that provenpackager
> would be the "Experienced packagers" referred to on:
>
>
http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToMod...
>
> which also lays out what provenpackagers are allowed to do.
=:-o 1st of April is still weeks away.
Why is there an exception for "Red Hat packagers"?
| Definition of the term "Experienced packagers"
|
| [...]
|
| Red Hat packagers that have been through a number of reviews and
| have been packagers for more than 4 months.
It was added at that time to include experienced Red Hat packagers
coming from core who weren't sponsors. Now Red Hat packagers in that
position should be provenpackagers.
--
Pat
5:06 p.m.
Michael Schwendt wrote:
What I'd like to avoid is that some people step in and hide
non-responsive
maintainers by updating and upgrading packages without being an official
co-maintainer (or by rebuilding packages in Rawhide without taking care of
open bugzilla tickets).
I think the important part is that someone does the work, whether officially
the maintainer or not.
If Bugzilla tickets are being ignored, the non-responsive maintainer process
should be started for those, independently of whether some rebuilds for
broken dependencies by non-maintainers happened or not. If the broken
dependencies were the only issue, then having anyone, no matter whom, fix
them solves the problem.
Kevin Kofler
5:42 a.m.
On Tue, Mar 10, 2009 at 11:19:13AM +0100, Ralf Corsepius wrote:
Patrice Dumas wrote:
>
> provenpackagers are people who can change all the packages with opened
> ACLs. Sponsors are the people who can accept new contributors in
> fedora.
<devil's advocate>
Well, with this definition, "provenpackager" is an acknowledgment of
"technical skills", while "sponsors" is a "social/political
role".
That's not that clear, since sponsors also have to help their sponsoree
on a technical level, and have to evaluate the technical skills of
potential contributors which also imply some level of technical skill.
But indeed, the sponsor evaluates potential new contributors, while
the provenpackager fixes other people packages.
It also doesn't have any connection to the role
"sponsors" once used to
have: To guide and educate new-comer packagers.
It is in the definition of sponsors, but I wanted to make it short. In
more length they are the people who can accept new contributors in
fedora and guide and educate them.
--
Pat
6:17 a.m.
On Tue, 10 Mar 2009 11:42:12 +0100, Patrice wrote:
On Tue, Mar 10, 2009 at 11:19:13AM +0100, Ralf Corsepius wrote:
> Patrice Dumas wrote:
>>
>> provenpackagers are people who can change all the packages with opened
>> ACLs. Sponsors are the people who can accept new contributors in
>> fedora.
>
> <devil's advocate>
>
> Well, with this definition, "provenpackager" is an acknowledgment of
> "technical skills", while "sponsors" is a "social/political
role".
That's not that clear, since sponsors also have to help their sponsoree
on a technical level, and have to evaluate the technical skills of
potential contributors which also imply some level of technical skill.
But indeed, the sponsor evaluates potential new contributors, while
the provenpackager fixes other people packages.
?? "some level of technical skill"? As every sponsor becomes a member of the
provenpackager group, what capabilities are provenpackagers missing, that
they don't simply become sponsors?
6:24 a.m.
On Tue, Mar 10, 2009 at 12:17:50PM +0100, Michael Schwendt wrote:
?? "some level of technical skill"? As every sponsor becomes a member of the
provenpackager group, what capabilities are provenpackagers missing, that
they don't simply become sponsors?
People interested in security, release engineering, other arches are
typically suited for provenpackager role, and not necessarily for sponsor
role. Also people who likes to fix others packages, but don't want to be
sponsor... Though this should be quite rare.
--
Pat
6:57 a.m.
On Tue, 10 Mar 2009 12:24:29 +0100, Patrice wrote:
On Tue, Mar 10, 2009 at 12:17:50PM +0100, Michael Schwendt wrote:
>
> ?? "some level of technical skill"? As every sponsor becomes a member of
the
> provenpackager group, what capabilities are provenpackagers missing, that
> they don't simply become sponsors?
People interested in security, release engineering, other arches are
typically suited for provenpackager role, and not necessarily for sponsor
role. Also people who likes to fix others packages, but don't want to be
sponsor... Though this should be quite rare.
You've misunderstood my question. With the current process, sponsors
need not demonstrate anything beyond technical skills (= packaging
skills in form of a couple of package reviews).
7:59 a.m.
On Tue, Mar 10, 2009 at 12:57:05PM +0100, Michael Schwendt wrote:
You've misunderstood my question. With the current process, sponsors
need not demonstrate anything beyond technical skills (= packaging
skills in form of a couple of package reviews).
I don't think so. The process of sponsor selection is mostly ad-hoc.
It is FESCo choice, in the end, and technical skill doesn't have to
be the sole motivation of FESCo:
http://fedoraproject.org/wiki/How_to_sponsor_a_new_contributor#Becoming_a...
Quoting:
When someone within the project has developed a "good reputation"
(and this is admittedly a somewhat fuzzy definition!) then someone
else will generally nominate them for sponsor status.
....
A discussion and vote will then occur during the next Fedora
Engineering Steering Committee meeting.
--
Pat
9:09 a.m.
On Tue, 10 Mar 2009 13:59:50 +0100, Patrice wrote:
> With the current process, sponsors
> need not demonstrate anything beyond technical skills (= packaging
> skills in form of a couple of package reviews).
I don't think so.
It's reality, though [on the package sponsors email list].
4:49 a.m.
Hi,
a) I'd like to self-nominate myself as a Fedora Packager Sponsor.
b) I'd like to become member of provenpackager group.
The application under b) is redundant, unless the processing of b)
takes significantly less time than the processing of a).
<ramblings>
1) The user makes their desire to be a member of provenpackager
known
to FESCo (they can do this in really any way - mailing list, IRC, file
a ticket, etc)
What list, what IRC, where to file the ticket?
All I found was an information on wiki that sponsors nominations can
be sent to fedora-devel-list. (Allegedly, one can also send mail to
FESCo, but I were not able to find out the address.)
</rambligs>
<apology>
I'm really sorry to bother all the readers of fedora-devel-list, but
I felt I should re-gain my provenpackager status and was not able to
find a better async method.
</apology>
Have a nice day,
Stepan
6:35 a.m.
On Tue, Mar 10, 2009 at 10:49:26AM +0100, Stepan Kasal wrote:
Hi,
a) I'd like to self-nominate myself as a Fedora Packager Sponsor.
b) I'd like to become member of provenpackager group.
The application under b) is redundant, unless the processing of b)
takes significantly less time than the processing of a).
<ramblings>
> 1) The user makes their desire to be a member of provenpackager known
> to FESCo (they can do this in really any way - mailing list, IRC, file
> a ticket, etc)
What list, what IRC, where to file the ticket?
All I found was an information on wiki that sponsors nominations can
be sent to fedora-devel-list. (Allegedly, one can also send mail to
FESCo, but I were not able to find out the address.)
</rambligs>
The address is fedora-extras-steering <at> redhat.com
There is a FESCo trac instance with tickets at:
https://fedorahosted.org/fesco/
josh
8:36 a.m.
On Tue, 10 Mar 2009, Josh Boyer wrote:
>What list, what IRC, where to file the ticket?
>
>All I found was an information on wiki that sponsors nominations can
>be sent to fedora-devel-list. (Allegedly, one can also send mail to
>FESCo, but I were not able to find out the address.)
></rambligs>
The address is fedora-extras-steering <at> redhat.com
There is a FESCo trac instance with tickets at:
https://fedorahosted.org/fesco/
Does the apply button on the provenpackager group page on
admin.fedoraproject.org go to the right place? That'd be another good
off-list method if it does
https://admin.fedoraproject.org/accounts/group/view/provenpackager
later,
chris
9:01 a.m.
On Tue, Mar 10, 2009 at 9:36 AM, Chris Ricker <kaboom(a)oobleck.net> wrote:
Does the apply button on the provenpackager group page on
admin.fedoraproject.org go to the right place? That'd be another good
off-list method if it does
It goes to all of the FESCo members, so yeah. I've forwarded your
request on already :)
9:35 a.m.
Jon Stanley wrote:
On Tue, Mar 10, 2009 at 9:36 AM, Chris Ricker
<kaboom(a)oobleck.net> wrote:
> Does the apply button on the provenpackager group page on
> admin.fedoraproject.org go to the right place? That'd be another good
> off-list method if it does
It goes to all of the FESCo members, so yeah.
Is this the right thing to do?
Why isn't the community of sponsors`involved?
Ralf
5:08 p.m.
Josh Boyer wrote:
The address is fedora-extras-steering <at> redhat.com
Note that there's one annoyance: the list is moderated, so everything you
send there gets held for moderation before it's actually sent out to FESCo.
Kevin Kofler
5:42 p.m.
On Tue, Mar 10, 2009 at 11:08:22PM +0100, Kevin Kofler wrote:
Josh Boyer wrote:
> The address is fedora-extras-steering <at> redhat.com
Note that there's one annoyance: the list is moderated, so everything you
send there gets held for moderation before it's actually sent out to FESCo.
This is true. The trac instance is not (and sends email to the list).
josh
5534
days inactive
5537
days old
35 comments
11 participants
participants (11)
-
Bill Nottingham -
Chris Ricker -
Jon Stanley -
Josh Boyer -
Kevin Kofler -
Michael Schwendt -
Oliver Falk -
Patrice Dumas -
Ralf Corsepius -
Stepan Kasal -
Toshio Kuratomi