long term support release
Kevin Kofler
kevin.kofler at chello.at
Thu Jan 24 17:09:26 UTC 2008
Michael Schwendt <mschwendt.tmp0701.nospam <at> arcor.de> writes:
> It may be "OK" in general, but it was very disappointing. Fedora Legacy
> leadership was not willing to learn from mistakes. As you may remember,
> Fedora Legacy started inside bugzilla.fedora.us, copied also the fedora.us
> package submission/review/approval process, including the corresponding
> bugzilla keywords. It had one foot in the grave already at the start. This
> resulted in updates waiting several weeks for approval, simply because the
> people providing those updates were treated as completely untrusted or
> incapable and were not permitted to publish any updates without prior
> approval. They had to wait endlessly for another person to sign off the
> updates, and obviously, even fewer volunteers were interested enough to be
> responsible for approving updates. For a project where speed does matter
> this was inacceptable and drove away or scared off contributors.
I pretty much agree it was the extremely burdensome QA which killed Fedora
Legacy (it got relaxed a bit later on, but it was still too big of a burden and
most of the potential contributors had already given up). Insistence on not
trusting Bugzilla's authentication (requiring GPG signatures of Bugzilla
messages) didn't help streamline the process either.
I think a FL-like project with _no_ QA (i.e. working like FE used to (as soon
as the package is built, it gets signed and released in the next push), but
without ACLs or even a honor-based concept of maintainership like in the old
FE) would be more likely to work. If someone wants to fix a security issue in a
package, let them do it and push the package immediately as soon as it's
available.
Kevin Kofler
More information about the fedora-devel-list
mailing list