long term support release

[Michael Schwendt]

On Thu, 24 Jan 2008 13:24:57 -0500, Jesse Keating wrote:

> On Thu, 24 Jan 2008 17:09:26 +0000 (UTC)
> Kevin Kofler wrote:
> 
> > 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.
> 
> That's pretty terrible because now you have no trust that the issue was
> actually fixed.

FL did not guarantee anything either.

You can offer post-release reviews. That means, confirmation of fixes
after publishing updates as soon as they are available. The queue of what
to review might grow hopelessly. But meanwhile, the people who work on
update packages can earn trust and stay productive. Only with lower hurdles
you can find out whether a project fails because of lack of man-power.

The opposite is even more "terrible". No fix to offer for several weeks
because it sits somewhere in bugzilla waiting for a reviewer, who only is
courageous enough to review on a single dist. Then perhaps only a
test-build, and still nobody to approve it finally, so it could be moved
to the stable updates repo. You can't grow a community if you have nothing
to offer and if you can't raise interest because inappropriate policies
and procedures are carved into stone already.