FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 10-21-2008, 09:14 PM
Toshio Kuratomi
 
Default

There's a new SOP that describes what we do to Bugzilla in Fedora:

https://fedoraproject.org/wiki/Infrastructure/SOP/Bugzilla

How to deal with the following occurrences is one of the things in it:

-------- Original Message --------
Subject: Errors while syncing bugzilla with the PackageDB
Date: Tue, 21 Oct 2008 20:12:26 +0000 (UTC)
From: accounts@fedoraproject.org
To: admin@fedoraproject.org


The following errors were encountered while updating bugzilla with
information
from the Package Database. Please have the problems taken care of:

({'product': u'Fedora', 'component': u'aircrack-ng', 'initialowner':
u'opensource@till.name', 'initialcclist': [u'dah21@students.pti.edu',
u'opensource@till.name']}, 504, 'The name dah21@students.pti.edu is not
a valid username.
Either you misspelled it, or the person has
not
registered for a Red Hat Bugzilla account.')


-Toshio

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 10-21-2008, 09:39 PM
Michael Schwendt
 
Default

On Sat, 11 Oct 2008 23:33:41 +0200, Patrice Dumas wrote:

> My proposal was clear: start the project when somebody has volunteered
> for each of the packages that are in @code and @base (and maybe other
> comps groups, I don't remember exactly). And keep a page with the
> packages maintained such as not to give wrong expectations.

Be careful with a project based on promises. Somebody might volunteer to
maintain a package, but leave the project already prior to the first
important security-fix due to lack of time or because of more important
obligations. Learn from Fedora Legacy's fate. Not enough commitment from
the target group. Too much bureaucracy for the few people who prepared
updates [= a slow review process in bugzilla even for small patches copied
from RHEL, lack of trust, all contributors had to wait for reviews,
bottle-necks in the build'n'release process]. With every week a security
update had to wait somewhere in a review ticket, some more people
(including contributors) left the target group.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-21-2008, 09:50 PM
Michael Schwendt
 
Default

On Sun, 12 Oct 2008 00:17:05 +0200, Patrice Dumas wrote:

> I was interested in
> legacy at some point, but everything was so different than in fedora
> extras that it deterred me.

Fedora Legacy was close to dead already much earlier, failing to deliver
updates for Red Hat Linux 7.3 and 9. Originally, it had started with parts
of the fedora.us infrastructure (the Fedora Extras predecessor), using the
same bugzilla, the same review'n'release process in bugzilla, a human-driven
build-system, but not inheriting the existing web of trust. Even simple
updates took four or more weeks to be looked at in bugzilla.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-21-2008, 09:54 PM
"Stephen John Smoogen"
 
Default

On Tue, Oct 21, 2008 at 3:39 PM, Michael Schwendt <mschwendt@gmail.com> wrote:
> On Sat, 11 Oct 2008 23:33:41 +0200, Patrice Dumas wrote:
>
>> My proposal was clear: start the project when somebody has volunteered
>> for each of the packages that are in @code and @base (and maybe other
>> comps groups, I don't remember exactly). And keep a page with the
>> packages maintained such as not to give wrong expectations.
>
> Be careful with a project based on promises. Somebody might volunteer to
> maintain a package, but leave the project already prior to the first
> important security-fix due to lack of time or because of more important
> obligations. Learn from Fedora Legacy's fate. Not enough commitment from
> the target group. Too much bureaucracy for the few people who prepared
> updates [= a slow review process in bugzilla even for small patches copied
> from RHEL, lack of trust, all contributors had to wait for reviews,
> bottle-necks in the build'n'release process]. With every week a security
> update had to wait somewhere in a review ticket, some more people
> (including contributors) left the target group.
>

Now that we are constructive talking.. how can we lower the
bureaucracy and build trust in an environment where its all based on
who knows who and relationships take a long time to build up (I mean
this for any project from the Linux kernel, etc.) And you are correct,
my attitude towards Ralph earlier stunk.



--
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-21-2008, 09:59 PM
Patrice Dumas
 
Default

On Tue, Oct 21, 2008 at 11:39:12PM +0200, Michael Schwendt wrote:
> On Sat, 11 Oct 2008 23:33:41 +0200, Patrice Dumas wrote:
>
> > My proposal was clear: start the project when somebody has volunteered
> > for each of the packages that are in @code and @base (and maybe other
> > comps groups, I don't remember exactly). And keep a page with the
> > packages maintained such as not to give wrong expectations.
>
> Be careful with a project based on promises. Somebody might volunteer to
> maintain a package, but leave the project already prior to the first
> important security-fix due to lack of time or because of more important
> obligations. Learn from Fedora Legacy's fate. Not enough commitment from
> the target group. Too much bureaucracy for the few people who prepared
> updates [= a slow review process in bugzilla even for small patches copied
> from RHEL, lack of trust, all contributors had to wait for reviews,
> bottle-necks in the build'n'release process]. With every week a security
> update had to wait somewhere in a review ticket, some more people
> (including contributors) left the target group.

My proposal has always been to use the exact same procedures than in
fedora, so nothing like in fedora legacy.

--
Pat

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-22-2008, 12:00 AM
Michael Schwendt
 
Default

On Tue, 21 Oct 2008 15:54:20 -0600, Stephen John Smoogen wrote:

> Now that we are constructive talking.. how can we lower the
> bureaucracy and build trust in an environment where its all based on
> who knows who and relationships take a long time to build up (I mean
> this for any project from the Linux kernel, etc.)

Well, that's the interesting part of starting such a project. How many
of the "interested developers" will be new people who would register in
FAS for the first time? How much information about themselves are they
willing to disclose? Inside the Fedora project you need to ask yourself
anyway how much you trust fellow contributors? Some are with the project
for several years, but you need to rely on the sponsorship process as you
don't know everyone (and you don't verify regularly that it's still the
same person who uses a fedora account or that the intentions are still
good).

How many volunteer specialists are available to support some of the huge
core packages? Copying and rediff'ing patches only is one thing, porting
patches between versions is something completely different. In an older
discussion I've suggested a dry-run for such a project. It could start
with F8 EOL, albeit a boring period and a lot to do (evaluating
vulnerability notifications alone is a lot of work). How patient would
contributors stay before they would give up or switch to another dist?

If reviewing is needed, the core team of a LTS project could sign off
patches submitted by completely new contributors, who haven't been active
in Fedora before. It ought not create significant delays in getting
something published, as contributors will likely become unsatisfactory
soon with productivity issues or find other reasons to leave. There are
existing procedures, such as the sponsor- or mentor-model for new
people. Existing infrastructure would help, too: pkg cvs commit diffs
posted to a mailing-list, for example, which is not a separate list on a
server in some other domain. This adds the possibility that some
completely unexpected pair of eyes skims over the diffs, rather than just
a small number of contributors. More convenient than having to do rpmdiff
manually. Source tarballs can be checksum-compared with newer Fedora
branches in lookaside cache.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-22-2008, 12:08 AM
Michael Schwendt
 
Default

On Tue, 21 Oct 2008 23:59:06 +0200, Patrice Dumas wrote:

> My proposal has always been to use the exact same procedures than in
> fedora, so nothing like in fedora legacy.

In Fedora you don't become a kernel/glibc/X pkg maintainer all of a
sudden. You would either work at Red Hat, or you would have to use the
current kernel-maintainers as your proxy for quite a long time before they
would approve a "commits" request in pkgdb.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-22-2008, 12:52 AM
Patrice Dumas
 
Default

On Wed, Oct 22, 2008 at 02:08:53AM +0200, Michael Schwendt wrote:
> On Tue, 21 Oct 2008 23:59:06 +0200, Patrice Dumas wrote:
>
> > My proposal has always been to use the exact same procedures than in
> > fedora, so nothing like in fedora legacy.
>
> In Fedora you don't become a kernel/glibc/X pkg maintainer all of a
> sudden. You would either work at Red Hat, or you would have to use the
> current kernel-maintainers as your proxy for quite a long time before they
> would approve a "commits" request in pkgdb.

The idea here is to open ACLs for release that are no longer supported.

--
Pat

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-22-2008, 09:16 AM
Michael Schwendt
 
Default

On Wed, 22 Oct 2008 02:52:17 +0200, Patrice Dumas wrote:

> On Wed, Oct 22, 2008 at 02:08:53AM +0200, Michael Schwendt wrote:
> > On Tue, 21 Oct 2008 23:59:06 +0200, Patrice Dumas wrote:
> >
> > > My proposal has always been to use the exact same procedures than in
> > > fedora, so nothing like in fedora legacy.
> >
> > In Fedora you don't become a kernel/glibc/X pkg maintainer all of a
> > sudden. You would either work at Red Hat, or you would have to use the
> > current kernel-maintainers as your proxy for quite a long time before they
> > would approve a "commits" request in pkgdb.
>
> The idea here is to open ACLs for release that are no longer supported.

I do understand that, but we talk past eachother. Let's assume you start
with the F-8 branch opened up to all packagers. Then you still need a
procedure where previously unknown people join the project and be
sponsored or something like that to get direct access to the pkgs and
buildsys and so on.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-22-2008, 09:29 AM
Patrice Dumas
 
Default

On Wed, Oct 22, 2008 at 11:16:21AM +0200, Michael Schwendt wrote:
>
> I do understand that, but we talk past eachother. Let's assume you start
> with the F-8 branch opened up to all packagers. Then you still need a
> procedure where previously unknown people join the project and be
> sponsored or something like that to get direct access to the pkgs and
> buildsys and so on.

I see, you mean that, given the different target, people wanting to
participate to a fedora EOL would be different from people participating
in fedora (say, like, people wanting to participate in EPEL but not
in fedora). I didn't thought about that, but it seems to me that going
through bugzilla should be enough? The EOL SIG should take care of the
patches.

--
Pat

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 09:46 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org