proposal: new approach

Bruce Dubbs bruce.dubbs at gmail.com
Fri Jul 24 16:49:52 PDT 2009


Randy McMurchy wrote:
> Bruce Dubbs wrote these words on 07/24/09 18:03 CST:
> 
>> I think we do need to mark each package with some sort of indication about when 
>> it was last reviewed.  We do have a Last updated on: tag, but that's not always 
>> the best indication because it is automatically updated for things like 
>> whitespace changes.
>>
>> The exact method of doing this mark is not really important.  I like the 
>> suggestion made earlier to add a line to each package with "Last checked against 
>> LFS 6.5", possibly within the introduction of the package
> 
> I don't believe that adds any value. Our target is LFS-6.5. If a package
> was updated (that's what a changelog is for), then it is obvious what
> version it was checked against.
> 
> Furthermore, how are we to distinguish which packages were checked
> against 6.3 and which were checked against 6.4? Answer: impossible
> to tell unless someone builds it and then it is 6.5. So, in essence,
> everything will be checked against 6.5, or it wasn't checked. So what
> is the point in adding the obvious? It was either checked against 6.5
> (changelog points this out) or it wasn't checked at all.
> 
> I'm against this idea. I don't want to release a stable book that
> says "this package last checked against (some previous version other
> than the stable LFS we targeted). I think it would look amateurish.
> 
> I think we're better off just continuing to update as we always have.
> If we find breakage we fix it. I'm against "versioning" the updates.

I understand your point, but I was thinking of the future.  It's true that any 
package we update now should be against 6.5.  The absence of a line that says 
"Last Reviewed means that it was before 6.5.

In the future, if we get behind again, then the Last Checked line does provide 
some useful information.

For the present, it gives a quick check (without searching through 200+ tickets) 
that a package was reviewed recently and doesn't need further review right now.

I think its a reasonable approach, even if we want to remove it for a release.

   -- Bruce




More information about the blfs-dev mailing list