On Friday 21 July 2006 14:57, Geert Stappers wrote:
> I understand only the short term message. [2]
> What I don't get is the long term policy. I only have questions about
> it.
>
> * How to tag a bugreport like #378404 with 'fix after string freeze'
You don't. I have it in my post-freeze TODO list. Which is part of my job
as RM for the installation guide.
> * Why leave typos in the original text? Why should translators all see
> (or ignore) the same typo?
Because updating it now would force _all_ translators to update their
translation again. A freeze is exactly to avoid that.
> * Why leave out additions like 'or <userinput>fb=true</userinput> for
> short.' from the original text? Why not allow the improvement in the
> translations.
Same.
> * Why a very very strict string freeze? ( Proposal: allow the Release
> Manager to modify strings during a freeze )
Same.
> * Would a "state flag" help to indicate a status like a freeze?
> So that when a 'update translations' message is skipped/missed/whatever
> there is still the state flag. Perhaps also include that flag in
> /topic?
Do you honestly mean you would really have looked for a "state flag"? Such
things only work if everybody knows where to look for them and I doubt
there is one location that would work for that.
/topic IMO abused enough already and will only get too long and unreadable
when stuff like this is added.
It's much better that _you_ take the responsibility to know what you are
doing before doing it instead of just going ahead because it looks easy.
> * How much "revert work" was/is needed after a "considered harmless"
> "Hey, this patch shouldn't be ignored action"? Telling all the things
> that need to be done for a cleanup, shows how much harm actually was
> done.
Because it is fairly complex and requires a real understanding of the
build system, the way translators work and revision versioning. The only
way to learn about that is to really get involved yourself, not by me
providing simplistic recipes.
> * What about a "Hey, you created this mess, follow the procedure at URL
> to clean it up" approach? Or "Your action harmed this list of people,
> say sorry to them"?
> Or another thing that has much learning in itself.
The problem as I see it is that your involvement with d-i is only on the
sidelines. You are not involved or committed enough to anything so that
you know the status _because_ you are involved. Instead you pick things
that "look" easy and do them without considering the consequences.
Another example is the cloning of Rick's installation report today over
the lspci issue:
- you cloned it without reassigning it, so it is still lost in the
mountain of installation reports
- the reason you did not reassign it is probably because you have no clue
where to reassign it
- just cloning a BR like this does not really help the project; what
_would_ help is doing some research:
- can you reproduce the problem
- it used to be installed in earlier images, so what used to be
responsible for that
This should give you enough information to reassign it properly with
a suggested solution.
Note though that installing lspci in the installed system is not so
necessary anymore as current installation images already save the lspci
info in /var/log/installer as part of the "finish install" step, or
whenever the user selects "save logs".
Attachment:
pgps2dpBuv8vE.pgp
Description: PGP signature