changes are needed, we need keep moving

[Eric Rostetter]

Quoting Pekka Savola <pekkas at netcore.fi>:

> On Thu, 2 Jun 2005, Eric Rostetter wrote:
> >>   If one distribution version of a package has one VERIFY vote, all the
> >>   versions will automatically be released after a timeout of XX (where
> >>   I suggest XX is 2 weeks) from the first VERIFY -- except if someone
> >>   identifies issues which require discussion or more work.
> >
> > You might as well just publish them without testing then. One verify vote
> > isn't significantly different than no verify votes.  I'd say any plan
> > that requires only one verify vote is worthless.
> 
> I disagree.

I'm wondering if I misunderstand what you are proposing.  But I'm not
sure.

If you mean that it only takes 1 verify vote for any version of an update
to publish an update (across all versions) than I stand by what I said.  
Otherwise, I'd have to ask that you clarify what you mean.

> Patches are typically very similar across all the
> versions.  The sanity of the patches has already been checked at
> PUBLISH.  Checking that the program actually works in one platform is
> definitely better than nothing.

I didn't read your statement that way earlier.  If you mean we get enough
verify votes for a version, then publish the rest, fine.  But I thought
you said if we have one, single, lonely vote we should publish just
because of a timeout, which is bad.

For example, one of our first (if not our first) kernel updates published
had to be immediately re-issued.  It was verified by several people, so
it should have been good.  But all testers tested it with grub, and the
problem was in lilo.  So we need to have a larger number of people voting,
to make sure we cover enough cases to allow the QA testing to be at all
reasonable.  Even with our current system, errors get through because
the testing sample just isn't big enough.  So I'm against anything that
in principle allows us to publish with less testing in less-diverse 
environments.

> > I'm not against the timeout, in fact there is supposed to be a timeout
> > in the process, though I don't remember what it is.  Perhaps we need to
> > revisit the timeout issue, with the goal of putting someone in charge of
> > watching the packages for timeout conditions.
> 
> AFAIK, there is no timeout, at least it isn't documented.  You may be
> remembering the situation with RHL72/RHL73 and RHL8/RHL9 where I
> recall there was something like a timeout but that case no longer
> exists.

I don't think there is anything in writing, but I think if we check the
mailing lists from long ago this was covered, and a timeout was established.

> > Right now, no one is AFAIK
> > watching for such situations, so even if something had multiple verify
> votes
> > and has stalled, no one notices and pushes it out.  Seems like another
> > essential job waiting to be filled.
> 
> Regardless of the timeout, there exists the case where VERIFY vote has
> been given but the fact has not been recorded in the status
> whiteboard, so the package is organized in the wrong place in the
> issues list.

Yes, this is a large part of the problem now (I've never figured out yet
how to update the whiteboard).  That is why I'm proposing this as a "job"
that some one needs to step up and fill (remember we defined some jobs
on the web site, most all of which are no filled yet).

> As said I disagree with this view, but even with this, a project like
> fedora legacy is even more worthless if it doesn't produce anything or
> doesn't do it in a sufficiently timely manner.

I may just not understand what you mean, so I'll give you that
benefit of the doubt for now.

> > If people are using testing-updates and not reporting their success,
> > then that is the issue, and that is what needs to be fixed.  I'm not
> > sure if this is the case.  If it is, maybe we could make posting a
> > success report easier (e.g. a web form they fill out?)
> 
> Well, as I said half a year ago, all this fuss about PGP signatures
> and bugzilla turns people away.  Most folks don't want to do
> self-introductions, pgp generations, register bugzilla accounts, etc.

Let's discuss how we can stream-line this then...
 
> But at this point, I doubt there is much more to be done about it.

Never know, maybe we can come up with something easier...

> >>  If something breaks with the update, we'll just
> >> fix it afterwards and say "well, you should have tested the update in
> >> 2 weeks and reported the problems".
> >
> > And they will rightly say, "No, FL legacy released it as tested and
> > passing QA, so the problem is with FL and not me."
> 
> If the users don't want to involve themselves in helping the project,
> I don't see how we should be concerned about "complaints" from such
> users.

This is why Red Hat went commercial, and look at all the bad press they
got from that, and how they got almost no good press.

If you want commercial support, buy it from Red Hat or Progeny or someone.
Otherwise, if you want "free" support you have to "work" for it.

> I am not against posting the URL regularly, but I doubt it'll do much
> good.  Those that want to know it, already do.  Reposting it more than
> monthly probably doesn't make any difference.

Actually, I think it makes a big difference.  I think when it was posted
weekly it made a big difference.  And I know I look at it when it hits
the mailing list, and I pretty much never look otherwise.  So it 
definately has an effect on me.  And I'd bet on others too.
  
Getting it on the FL web page would also be a good thing though, and take
some of the effort off you and/or others posting it e.g. weekly to the
mailing list.  Any progress on that yet Jesse?

> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

-- 
Eric Rostetter