RFC: Tripwire name change

[Mike A. Harris]

On Sun, 22 Feb 2004, Keith G. Robertson-Turner wrote:

>> That would not work because then every single time a new rpm package is
>> built, one would have to edit specspo to update all the version numbers.
>
>Which is exactly why the centralised system, that specspo employs, doesn't
>work.

I never claimed it did.  In fact, the current specspo method does 
/not/ work.  I'm only claiming that replacing one broken method 
of doing description translations that is problematic, with 
another equally broken (or morseo) method, is not a good solution 
at all.


>Packages should contain their own translation (including the
>package summary and description). The translation is done once,
>as it is now, by whoever it is that is responsible for such
>things (i18n.redhat.com?), and merged with the SRPM by the build
>process.

And if a translator breaks something, and your package that took 
6 hours to build fails due to a broken translation, who fixes it?


>> Since the description text is something that rarely if ever changes in
>> most packages
>
>Rare, yes, but should it happen at all ... ever ... if there is
>a better way. This is not the slow, steady release of Red Hat
>boxed sets era, this is the fast and furious, new kernel a week,
>20 new packages a day, apt repo's springing up like mushrooms,
>era. Specspo is based on an assumption ... that, basically,
>package summaries and descriptions never change, and that the
>package base remains static. This is wrong. Specspo is broken,
>and in the worst possible way, in a way that simultaneously
>breaks (or potentially breaks) every other package in a distro
>(in however trivial a manner).

Again, I do not disagree.


>> having to manually update specspo every time would not be very
>> convenient.  It would be annoying to the point that developers would
>> probably refrain from building packages as often, and instead wait much
>> longer between updates to avoid the specspo update penalty.
>
>I think you're putting the cart before the horse. Packagers
>would release as often as they liked. *If* and *when*
>translations became available, then they would be merged in by
>the build process ... until then, the package would remain
>un-translated. Unless the packager him/her-self decided to BLOCK
>while awaiting translation (or seek assistance from elsewhere to
>do the translation).

I'm not putting any cart before the horse.  I'm stating a clear 
fact that replacing one broken way of doing translation with 
another equally if not more broken method does not accomplish 
anything.  It would move the irritation from one place to 
another, and move the burden to fix it from one group of people 
to another.

There would be an additional irritation as well.  If the package 
descriptions did not change at all, and you build a new 
version/release, and that invalidates specspo, but nothing 
actually needs to be done - and that causes translations to be 
disabled until someone edits something and bumps the version 
number, that person will be irritated 200 times a week.

Again, that does not solve the problem.


>The point is, let's get away from monstrous, centralised,
>totalitarian methods, and employ distributed, modular, flexible
>methods instead.

I totally agree with you.  But the method you prescribe is _not_ 
the answer as it solves one ugly problem by making another 
equally ugly problem.

What might work, is having specspo keep just the translations, 
and have package builds automatically trigger a 'test' of some 
sort that tests for any changes in the description or other 
translateable fields in the spec file.  If any actual text 
changes compared to the last build, then some automated process 
invalidates the specspo entries for that translation and notifies 
the translators via bugzilla XMLRPC.

That way, not only is the burden removed from package 
maintainers, but it is also not shoved on to translators to edit 
something rediculously just to bump a version number to say 
"nothing changed, so please keep including translations".  
Instead, the massive amount of computing power we have at our 
disposal is doing something useful and notifying the people who 
need to do any work only when there is work to do.  The added 
bonus, is that it has full bugzilla defect tracking and can be 
flagged as blockers of a string-freeze-date bug, and go through 
normal triage process, etc.

The only thing left to do, is get someone to do the work.  No, 
before anyone asks, I'm not volunteering - I came up with the 
idea, I did my part already.  ;o)

Hmmm...  Sopwith is pretty familiar with the buildsystem code and 
post build test harnesses...  and Adrian and Dave know bugzilla 
XMLRPC pretty good...  hmmm....

;o)


-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat