Re: long term support release

[Kevin Kofler <kevin kofler chello at>]

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