Re: Lintian::Collect, version numbering
On Sat, Jun 07, 2008 at 01:21:36AM -0700, Russ Allbery wrote: As previously discussed on the list, I've added a new framework for handling data collection about packages. Currently, the functionality is fairly limited, but the infrastructure is now in place and we can start growing it. Every check script now gets a third argument, which is a Lintian::Collect object (well, actually either a Lintian::Collect::Source object or undef right now, but eventually a Lintian::Collect::Source, Lintian::Collect::Binary, or Lintian::Collect::Udeb object, all of which inherit from Lintian::Collect). The idea is that any code that reads data from the lab should instead call methods in those objects, which abstracts out the interface to the lab. I've begun adding a Collect::Binary module. Could you please take a look and tell me if it fits your vision? I was especially unsure about the usage of the Util functions. Should we take the opportunity to move this module under Lintian::, too? What would you prefer for error handling in the new modules? die or return with some kind of error condition? Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian::Collect, version numbering
On Sat, Jun 07, 2008 at 01:21:36AM -0700, Russ Allbery wrote: Given that this is an infrastructure change, I think this warrants a version bump, and I'd like to propose that we change the version numbering of Lintian at the same time. Currently, all we're ever doing is incrementing the third version number of the package. Should we switch to just using two versions; in other words, make the next version 1.24, the version after that 1.25, and so forth? Then we can do major version bumps for backward-incompatible changes or for major changes (such as, hopefully, the summer work on tag classification). What do people think? Yeah, I have nothing against bumping the 2nd version number. But I still think that the 3 part version number has its merits, so I'm currently against dropping the third part. Actually why not drop the 1? we really seem not intend to increase it any time ;) Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian::Collect, version numbering
On Sat, Jun 07, 2008 at 01:21:36AM -0700, Russ Allbery wrote: and then memory accesses. However, down the road, this opens the possibility of doing away with the collect scripts if we want to and just using this object to hold the same data. Hey, no touching the lab :) Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian::Collect, version numbering
Frank Lichtenheld [EMAIL PROTECTED] writes: Yeah, I have nothing against bumping the 2nd version number. But I still think that the 3 part version number has its merits, so I'm currently against dropping the third part. Actually why not drop the 1? we really seem not intend to increase it any time ;) *laugh*. Okay, I'll keep the third part. My theory was that we'd bump the 1 to 2 when we incorporate a finer-grained tag classification system, since that's about the biggest change that I can imagine us doing for the forseeable future. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian::Collect, version numbering
Frank Lichtenheld [EMAIL PROTECTED] writes: On Sat, Jun 07, 2008 at 01:21:36AM -0700, Russ Allbery wrote: and then memory accesses. However, down the road, this opens the possibility of doing away with the collect scripts if we want to and just using this object to hold the same data. Hey, no touching the lab :) Only if we want! I'm currently planning on leaving that all the same. I'm hoping that I can find ways to make Lintian faster via this, though. Just reading all field values through a module that caches should help a lot. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
