Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Tue, 2005-08-16 at 18:18 -0400, Mike Frysinger wrote: suggestion: stop keeping ChangeLog files in CVS and instead, let them be generated automagically by the cvs server using the last arbitrary number of commit messages. if you really want to keep a commit message out of the changelog, then we come up with a simple policy of prefixing the message with a period (to keep it hidden :P). This would remove the possibility of correcting an entry in the ChangeLog in case of a typo or wrong assumption etc. logic: - i'm lazy That's not a valid argument - you can use a bash function for calling echangelog and repoman as shown numerous times on this list. - i hate typing the samething twice (yes, bash scripting with echangelog can kind of take care of this) ... it doesnt handle if you want to use different commit messages for different files Can you give an example of why you would want to use different commit messages in a single commit? - shrinks ChangeLog size for packages which have been around a very long time This is the only real advantage I see from the above proposal - but I don't think that warrants the change. I doubt the saved space would be that significant. - forces cvs log messages to actually be worthwhile to read and makes browsing cvs history much nicer (it's very easy to look at the differences between two files and match up a good commit message rather than trying to figure out what message in the ChangeLog goes with it, assuming there is one) See my first answer (bash function). - easily standardize ChangeLog format wrt to header, copyrights, licensing, message formatting, name/date format Already done by echangelog. - generate dates in UTC down to the second rather than having devs hand type them in their local timezone for just the current day I thought echangelog already did this based on TZ? - maybe some other things i havent thought of - i'm lazy See my first answer (bash function). Sincerely, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] eselect modules
Jeremy Huddleston wrote: I've recently updated opengl-update to use the eselect framework. I think the team has done a great job as it was extremely easy to port the bash script to an eselect module. However, when I placed it in the portage tree, it sparked a little bit of a policy discussion between myself and the core eselect devs on how to best include modules in the tree, so I'd like to let other devs chime in as well. Firstly if you don't know what eselect is, check out: http://www.gentoo.org/proj/en/eselect/index.xml The eselect developers want to keep all eselect modules in their svn repository and distributed through a single package (app-admin/eselect). Their main reasons for this are better QA and less overhead for releases and merging. QA is my main concern. I have a problem with this policy because: 1) Stability of the modules should not be tied to stability of the core package. Basically, I'd like to determine when my modules get pushed into stable without considering how it'll effect the eselect modules of other developers. Similarly, I don't want bugs in another module holding up my module from going into stable. agreed. 2) Not all users will want all modules. The goal of the eselect project is to provide a framework to replace java-config, motif-config, gcc-config, binutils-config, opengl-update, etc, but not all users will need all modules. 3) Some modules require extra files (opengl-update installs header files, gcc-config installs a wrapper, etc), and the app-admin/eselect package is not the correct place to provide these files. agreed. Also, what should the correct way to introduce these modules into portage? Should we keep them in the packages they're replacing (x11-base/opengl-update)? Should we place them in a new package in the same category as the script they're replacing (x11-base/eselect-opengl)? Should we place them in app-admin/eselect-module name or perhaps app-eselect/module name? Good question. I don't really have a preference. Note that for backwards compatibility in all cases, x11-base/opengl-update will RDEPEND on this eselect module and install a backwards-compatible frontend to the eselect module until all packages in portage have been updated to use the eselect module instead. It's been my opinion from the beginning that not allowing modules to be distributed outside of eselect limits its flexibility. However, I've kept my foot down to this point soley for QA reasons. It'd be a nightmare to keep track of the modules if they were all over the tree in various packages' files/ directories. After thinking about this a bit and reading the other responses you've gotten so far, I think we should keep all the modules in the main subversion repository and allow the modules to be distributed separately (once we have a stable API of course). Yay or nay on this? -- Summer is butter on your chin and corn mush between every tooth. -Calvin Aaron Walker [EMAIL PROTECTED] [ BSD | commonbox | cron | cvs-utils | mips | netmon | shell-tools | vim ] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
Extracted from what Henrik Brix Andersen wrote: That's not a valid argument - you can use a bash function for calling echangelog and repoman as shown numerous times on this list. See my first answer (bash function). See my first answer (bash function). From a database point of view, it is evil to duplicate values in an automated manner, just use a foreign key for such purposes. In other words, avoid duplication. If such bash function is a common tool then -- apart from wondering why it isn't part of the default suite -- this anti-duplication constraint is being broken massively. I like Mike's idea, because it deals with data redundancy and basically uses this 'foreign key' for the changelog. In other words: centralise the administration, don't make yourself having to keep multiple copies up-to-date, you're doomed to make errors with that. Just my two cents. -- Fabian Groffen eBuild Porting Gentoo for Mac OS X -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Wednesday 17 August 2005 15:14, Grobian wrote: The whole point was that I like avoiding storing data double (redundant), if that can be done easily. It has its own pro and cons as quite everything. You can avoid storing data double but makes more difficult to access it by the priority end users (devs; while users use changelogs, too, devs are the ones who really need to access them). As for the forum example: it wouldn't be a foreign key if there wasn't a left outer join to look up the respective value for the column. And so that left outer join is here to generate the Changelog to be backwards compatible The problem is where this is going to be generated. If this is going to be generated in the staging box before going in rsync, every dev that doesn't use rsync should use cvs log command to get the data, and this is quite unpractical (and requires bandwidth and adds load to the cvs server). So we should balance redundancy and load... I still think that a little redundancy of the changelogs saves us from having to add load to the staging or cvs box... -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpmkOpYnGABO.pgp Description: PGP signature
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Wednesday 17 August 2005 08:16 am, Henrik Brix Andersen wrote: On Tue, 2005-08-16 at 18:18 -0400, Mike Frysinger wrote: logic: - i'm lazy That's not a valid argument - you can use a bash function for calling echangelog and repoman as shown numerous times on this list. it was part joke and part seriousness ... i already have my commits scripted with echangelog/repoman, but that isnt the point - i hate typing the samething twice (yes, bash scripting with echangelog can kind of take care of this) ... it doesnt handle if you want to use different commit messages for different files Can you give an example of why you would want to use different commit messages in a single commit? i delete one version for being old, stabilize another ebuild, and add yet another ebuild as a rev bump - forces cvs log messages to actually be worthwhile to read and makes browsing cvs history much nicer (it's very easy to look at the differences between two files and match up a good commit message rather than trying to figure out what message in the ChangeLog goes with it, assuming there is one) See my first answer (bash function). which does not matter if you commit individual files firest with different messages before running your bash funcs it also pollutes the cvs log history for files ... if i make different fixes to different files but only commit with one message, you easily get a lot of noise - easily standardize ChangeLog format wrt to header, copyrights, licensing, message formatting, name/date format Already done by echangelog. not everyone uses echangelog - generate dates in UTC down to the second rather than having devs hand type them in their local timezone for just the current day I thought echangelog already did this based on TZ? it does, but not everyone uses echangelog - maybe some other things i havent thought of - i'm lazy See my first answer (bash function). heaven forbid you get a joke and laugh once in a while -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Devconference archives
On Tue, 2005-08-16 at 22:43 -0400, Nathan L. Adams wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: That being said, thanks to IU for doing the webcast... now everybody gets to see what we look like... *grin* If you're like me, you have a perfect face... for email. :P Are you kidding? I'm so pretty that now I'm worried about stalkers. *grin* Anyway, to get back on-topic... Corey, any idea when we'll have the individual talks linked from the page? -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Looking for developers for a new 'Planet' web-app
Rob Cakebread wrote: I patched the Planet source to add all the entries to an sql database then wrote a quick CherryPy demo [1] that uses the existing Planet's template system. The example just has the entries for a few random developers. You can search the titles or full text. Source code available [2] for the curious. You'll need dev-python/cherrypy and USE='sqlite' dev-python/sqlobject. If I can get ahold of the config.ini and template for the actual Planet Gentoo I'll be able to get the herd info from usernames (and make it look like the real deal). [1] http://gentooexperimental.org:9898/ [2] http://dev.gentoo.org/~pythonhead/planetdb.tbz2 This looks really good. You can get the gentoo-specific stuff by checking out the planet module from Gentoo SVN. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
Jon Portnoy wrote: On Wed, Aug 17, 2005 at 03:45:49PM +0200, Henrik Brix Andersen wrote: not everyone uses echangelog [snip] it does, but not everyone uses echangelog Why not? Because I don't want to. :) badjokeYou are the weakest link, goodbye!/badjoke -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Portnoy wrote: On Wed, Aug 17, 2005 at 03:45:49PM +0200, Henrik Brix Andersen wrote: not everyone uses echangelog [snip] it does, but not everyone uses echangelog Why not? Because I don't want to. :) I have no problem with people not using echangelog as long they write correctly formatted entries. It annoys the hell out of me when I come upon someone's hand-edited ChangeLog entry that lies (a missing '+' is the most common error). - -- QOTD: You want me to put *holes* in my ears and hang things from them? How... tribal. Aaron Walker [EMAIL PROTECTED] [ BSD | commonbox | cron | cvs-utils | mips | netmon | shell-tools | vim ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDA7cDC3poscuANHARAsV0AKDa+KehsJAk4J8C3UoDLUXq1FBbYQCfcdWL 8Q5Q8ZfmGsHWC6n56lfkXnw= =HfbF -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Thursday 18 August 2005 08:39, Aron Griffis wrote: Jason Stubbs wrote: [Tue Aug 16 2005, 09:46:23PM EDT] Repoman could check the commit message for being valid UTF-8 and simply not allow the commit if it isn't. :) Be careful, this steps over the line of creating policy by way of tools. This is similar to when I changed ekeyword to sort KEYWORDS. I don't quite get you here. GLEP 31 has been approved, no? That would make it seem to me that the above suggestion is just making the QA tool help enforce existing policy. If there's a flaw in that line of thinking, please point it out in case I fall into the same trap in some other instance. -- Jason Stubbs pgpna04UTQlmE.pgp Description: PGP signature
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Stubbs wrote: | I don't quite get you here. GLEP 31 has been approved, no? That would make | it seem to me that the above suggestion is just making the QA tool help | enforce existing policy. If there's a flaw in that line of thinking, please | point it out in case I fall into the same trap in some other instance. OK, here's your flaw. glep.gentoo.org says it's withdrawn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDA9K6XVaO67S1rtsRAgr/AJ9rcYfnNs+2Lq1R15+YCVKmpV6bZwCgsWK0 cGOBwYM7LW/Owfu10CmqErA= =cWiz -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Wednesday 17 August 2005 08:13 pm, Donnie Berkholz wrote: Jason Stubbs wrote: | I don't quite get you here. GLEP 31 has been approved, no? That would make | it seem to me that the above suggestion is just making the QA tool help | enforce existing policy. If there's a flaw in that line of thinking, please | point it out in case I fall into the same trap in some other instance. OK, here's your flaw. glep.gentoo.org says it's withdrawn. it was withdrawn for the time being because it was felt that there isnt any real way to enforce it atm -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] dts useflag
Hi, I'm here to annoy everyone just because I'm unable to sleep.. erm no well not exactly... Anyway, I just completed to prepare a new patch for xine-lib that makes libdts support optional (for the series the less, the best), so this is going to be the 5th dts useflag in portage: media-video/ffmpeg:dts - Enables libdts (5.1 surround sound audio) support media-video/mplayer:dts - Enables libdts (5.1 surround sound audio) support media-video/thoggen:dts - Enables libdts support media-video/vlc:dts - Enables DTS audio support I'll commit this tomorrow, when I'll be sure it's ok after an awake check. If nobody is against this, I'll also make dts useflag global (using ffmpeg/mplayer's description). -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpyTrMHeFyU4.pgp Description: PGP signature
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
Jason Stubbs wrote: [Wed Aug 17 2005, 08:09:39PM EDT] I don't quite get you here. GLEP 31 has been approved, no? That would make it seem to me that the above suggestion is just making the QA tool help enforce existing policy. If there's a flaw in that line of thinking, please point it out in case I fall into the same trap in some other instance. You might be right. I wasn't aware that GLEP 31 was approved before it was withdrawn. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgp2qJCbzyyD7.pgp Description: PGP signature
[gentoo-dev] MySQL ebuild removal selection
These ebuilds are scheduled for removal in the next 24 hours: - mysql-3.23.58 mysql-4.0.22-r1 mysql-4.0.23 mysql-4.0.23-r1 mysql-4.0.23-r2 mysql-4.0.24-r1 mysql-4.0.24-r2 mysql-4.0.25-r1 mysql-4.1.8 mysql-4.1.8-r1 These will survive: --- mysql-3.23.58-r1 mysql-4.0.22 mysql-4.0.22-r2 mysql-4.0.24 mysql-4.0.25-r2 mysql-4.1.13-r1 (masked) mysql-5.0.9_beta-r2 (masked) mysql-5.0.10_beta (masked) If you have some particular reason for keeping any of them drop me a note on/off list. Best regards Francesco R. -- . These pages are best viewed by coming to my house and looking at . . my monitor. [S. Lucas Bergman (on his website)]. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] MySQL ebuild removal selection
On Thu, 18 Aug 2005 03:59:42 +0200 Francesco R [EMAIL PROTECTED] wrote: If you have some particular reason for keeping any of them drop me a note on/off list. I'm sure you've done your due diligence, but please double check that you are not removing the latest stable or testing keywords for any architectures when you do this cleanup. Thanks, -- Jason Wever Gentoo/Sparc Team Co-Lead pgpj72TsQGbdV.pgp Description: PGP signature
Re: [gentoo-dev] dts useflag
maillog: 18/08/2005-03:03:40(+0200): Diego 'Flameeyes' Pettenò types Hi, I'm here to annoy everyone just because I'm unable to sleep.. erm no well not exactly... Anyway, I just completed to prepare a new patch for xine-lib that makes libdts support optional (for the series the less, the best), so this is going to be the 5th dts useflag in portage: media-video/ffmpeg:dts - Enables libdts (5.1 surround sound audio) support media-video/mplayer:dts - Enables libdts (5.1 surround sound audio) support media-video/thoggen:dts - Enables libdts support media-video/vlc:dts - Enables DTS audio support I am certain that I have watched DVDs that had DTS audio with 7 channels. I'll commit this tomorrow, when I'll be sure it's ok after an awake check. If nobody is against this, I'll also make dts useflag global (using ffmpeg/mplayer's description). -- () Georgi Georgiev () Young men think old men are fools; but old () ()[EMAIL PROTECTED]() men know young men are fools. -- George () () +81(90)2877-8845 () Chapman () pgp5im0eOQ2Fc.pgp Description: PGP signature
