On Wednesday, 07 April 2010, at 12:27:47 (+0100), Rui Miguel Silva Seabra wrote:
> >> I'm sorry, but that breaks the whole point of having clean software > >> installs. > > > > How, exactly? I notice that you did not answer this question. Did you miss it, or did you intentionally ignore it? > You're already confusing things, please devote some time to think > about the issue because I'm not discussing against the current > method, I like it. > > I'm just pointing out the need to detail it further than per day so > it suits even better. I, too, have encountered this in the past. But the day-level notation is a good compromise between readability/usefulness and rebuild granularity. I told you what I do, but you don't seem willing to use that method for reasons you have yet to articulate. (Calling it "not sane" is a subjective, not logical, argument.) > What is *NOT* sane is using "rpm --force -ivh package.rpm" You'll want to use -Uvh so that the previous NEVR isn't duplicated in the package store. That said, in this particular scenario, it's absolutely sane and reasonable. I've done it hundreds of times. > And what I ask does not change that, but allows the period to be > small enough to allow 1) build, 2) install, 3) test, 4) fix, go to > 1) process by specifying further the hour and the minute. I understand what you're asking, and I offered you a way to do that without having to break the existing nomenclature. > It's not so frequent to make multiple releases of software per day, > so many automatize a daily snapshot. Because some haven't run into > this issue, that does not make it a standard, much less mandatory as > you seem to argue for. Something that most projects are doing is, by definition, a de facto standard. There are two practices out there that cover almost all projects that are doing snapshots according to my research: a YYYYMMDD timestamp or a repository revision. So those would be the de facto standards for snapshot nomenclature. > You accuse me of making up statistics, but argued against them with > made up statistics yourself, that's not fair. I offered evidence to back up my point of view. That doesn't match any reasonable definition of "made up." > I never expected such an emotional opposition. Not once have I gotten emotional. I have an opinion, and I am trying very hard to communicate that opinion and the reasoning behind it in such a way that you will listen to it and understand it. Anyone who's been around the project for awhile can tell you: If I get emotional, you'll know it. :-) > Again: I have no intention of treading on your toes, you're making > it personal and I have more than once pointed out that there is > nothing of the such. As Albin pointed out, I am not making anything personal. I am backing up my opinion with evidence and logic. I have yet to receive a technical, logical reason why the exact solution I use myself for this very same problem is unacceptable to you. Simply writing it off as "insane" is a logical fallacy (Appeal to Ridicule) and does not constitute a valid argument. I would like to point out that the code you primarily work on, elmdentica, is yours to do with as you like. If you want the spec file to have a timestamp with HHMM in it, that's your call. Please feel free. But you said you wanted to change *all* the spec files, and that's what I oppose. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <m...@kainx.org> Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "The future is all around us, waiting in moments of transition to be born in moments of revelation." -- G'Kar, Babylon 5 ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
