With ado's retirement now almost upon us, I'd like to volunteer for the role of TZ Coordinator. Although I've only been directly involved, on the mailing list, for half a year, I've been peripherally involved for much longer. I'm very comfortable working in this space, and I believe I have the right personal qualities for the job. Firstly, I have a strong and unshakeable inclination to attend to detail, a determination to be thorough, and a decisive concern for correctness. (The former, at least, is an autistic trait, one of several that turn out to be useful to engineers.) I believe these qualities have been apparent in my contributions to the mailing list in recent months. For further substantiation, see my published code and contributions to other mailing lists (links below). I have a calm temperament, which kre rightly identified (on 2009-09-04) as a vital quality for this role. This can be seen in action on the various other mailing lists that I have inhabited in recent years. Particularly see the leap seconds mailing list, where in the past couple of years many discussions have regrettably become much more heated than befits the calibre of participant, and perl5-porters, where I've occasionally dealt with a prickly CPAN author. I'm at the right point in my career to take on this sort of role, potentially for as long as ado has served. I'm mature enough to take on a long-term commitment, while still young enough to have a long term. I was born in 1977, and so am some thirty years away from pensionable age. I can't promise to actually serve for that long, but there isn't anything standing in the way of me doing so. I have, and use, network access nearly every day, so I can respond promptly to urgent issues. I read email, as it comes in, during most of my waking hours, and I'm similarly available on IRC. I tend to spend my weekends and holidays (from paid work) programming. I don't make a habit of travelling, though I presently attend an annual conference that occupies me for five consecutive days. (I haven't so far attempted to access the net while at a conference, but it is available at these conferences, and I ought to get with the times.) Although it's not strictly necessary in a TZ Coordinator, I'm technically well qualified to look after the timezone code. C was my main programming language for about ten years, 1988 to 1998. Since then my main language has been Perl, but I still regularly work in C. About half of the Perl modules that I've published are largely implemented in C, for one reason or another, and I'm a contributor to the Perl core, which is written in C. The quality of my code can be discerned by perusal of my published Perl modules. I have a deep and abiding interest in horology, and particularly in computer implementation of it. I've been on the leap seconds mailing list for some years, actively involved in many discussions there. In the Perl world much of my published code is concerned with time, and last year I gave a well-received talk about time (but not timezones) at two Perl conferences (video link below). Looking more specifically at timezones, some of my Perl code is about timezones, much of that specifically about using the TZ database. I've become intimately familiar with the database through my work on this code. As a bonus, I have some plans for how the database should develop from where it is now. Chief among them, I'd like to see it become more historically comprehensive, but there are obvious problems for users that would come from multiplying up the number of timezones on the present infrastructure. I've got some clear ideas about how to solve these problems, principally some concepts for a new tzfile format that would let zones share representation. I'm confident of the feasibility, and I'd like to develop in this direction with a view to supplanting the present implementation, applying all due caution for stability issues. It's not necessary for me to be the TZ Coordinator in order to proceed with such a project, and I hope to do so anyway, but there's some level of convenience in the roles being colocated. In the spirit of openness, I'll now also list potential downsides of me as TZ Coordinator. Most obviously, I haven't been on the TZ mailing list very long. I tend to pick things up quickly, but this is a defect in the experience I'd bring to the role. Secondly, I have a bit of a concern that my existing role as a consumer of the TZ database (via authorship of relevant Perl modules) might compromise objectivity in developing the API (loosely speaking) that the database provides to the world. (On the other hand, it certainly provides a useful perspective.) Thirdly, I'm of the firm opinion that timezones ought to be abolished, in favour of universal use of Universal Time. Here are links to relevant resources. Other mailing lists that I'm on: http://six.pairlist.net/pipermail/leapsecs/ (leap seconds) http://www.nntp.perl.org/group/perl.datetime/ (time data in Perl) http://www.nntp.perl.org/group/perl.perl5.porters/ (Perl core) Published Perl modules: https://metacpan.org/author/ZEFRAM Video of talk about time: http://www.presentingperl.org/lpw2011/why-time-is-difficult/ Miscellaneous other bits on my web page: http://www.fysh.org/~zefram/ -zefram
On Sat, Mar 10, 2012 at 08:38:53AM +0000, Zefram <zefram@fysh.org> wrote:
With ado's retirement now almost upon us, I'd like to volunteer for the role of TZ Coordinator. Although I've only been directly involved, on the mailing list, for half a year, I've been peripherally involved for much longer. I'm very comfortable working in this space, and I believe I have the right personal qualities for the job.
If this was a vote, I would vote against you. The reason is that you are far from being calm or helpful - you often make broad claims, but when asked to explain them, you never do. Later they turn out to be evidence-less. As a TZ maintainer, you should reason things out (at least once), and not insist on you being right based on authority, but based on evidence.
From previous threads on this list it also looks as if you often have a non-technical agenda, which is probably bad for a technical project which requires objective and impartial decisions ("calm").
As a TZ maintainer, you should not get influenced by your personal goals, at least not too much.
I have a calm temperament, which kre rightly identified (on 2009-09-04) as a vital quality for this role.
Just to clear any misunderstandings that your statement might (or might not) cause, kre did _NOT_ identify your calm temperament as a vital quantity.
Particularly see the leap seconds mailing list, where in the past couple of years many discussions have regrettably become much more heated than befits the calibre of participant, and perl5-porters, where I've occasionally dealt with a prickly CPAN author.
So in the recent years when you joined discussions got more heated, and you take part. That's not good advertising. Also, being member of a perl mailinglist is hardly in any way relevant. The job of a TZ maintainer is quite different from that of a perl module author. Also, while I don't know what prickly cpan author you dealt with, this hardly belongs here, and the fact that you send thinly veiled insults about other people (despite being anonymous) on unrelated lists is hardly evidence for a "calm temperament". A TZ maintainer should not bring his personal fights on other mailinglists to his job as TZ maintainer.
Although it's not strictly necessary in a TZ Coordinator, I'm technically well qualified to look after the timezone code. C was my main programming language for about ten years, 1988 to 1998.
Ten years is hardly a long time - but I agree that's not vital, as others on this list have, in the past, shown exceptionally competence in this area and the willingness to help out if needed.
has been Perl, but I still regularly work in C. About half of the Perl modules that I've published are largely implemented in C, for one reason or another, and I'm a contributor to the Perl core, which is written in C. The quality of my code can be discerned by perusal of my published Perl modules.
Again, perl module author is hardly relevant for the job at hand. It would be much more interesting to hear about your qualities as a TZ maintainer.
As a bonus, I have some plans for how the database should develop from where it is now.
That sounds rather scary to me. I am sure I am not the only one who'd rather not see any "developments", but merely the enourmous stability that we have seen and appreciated in the past.
as TZ Coordinator. Most obviously, I haven't been on the TZ mailing list very long. I tend to pick things up quickly, but this is a defect in the experience I'd bring to the role.
Right. To be honest, the thought of you becoming maintainer and changing things a lot, as is clear form this and your previous mails, makes me outright scared. The greatest thing about the olson database and associated code is stability, the strive for portability while keeping things simple. The impression you give me is that the next thing you'll do is add autoconf support, integrate it into your perl module etc. - I am exaggerating, but change is so extraordinarily negative in this area that proposing to "develop" into new directions instantly disqualifies somebody from the role. Just my ¢2.
On 3/10/2012 2:07 AM, pcg@goof.com ( Marc) (A.) (Lehmann ) wrote:
On Sat, Mar 10, 2012 at 08:38:53AM +0000, Zefram<zefram@fysh.org> wrote:
With ado's retirement now almost upon us, I'd like to volunteer for the role of TZ Coordinator. Although I've only been directly involved, on the mailing list, for half a year, I've been peripherally involved for much longer. I'm very comfortable working in this space, and I believe I have the right personal qualities for the job.
If this was a vote, I would vote against you.
The reason is that you are far from being calm or helpful - you often make broad claims, but when asked to explain them, you never do. Later they turn out to be evidence-less.
As a TZ maintainer, you should reason things out (at least once), and not insist on you being right based on authority, but based on evidence.
From previous threads on this list it also looks as if you often have a non-technical agenda, which is probably bad for a technical project which requires objective and impartial decisions ("calm").
As a TZ maintainer, you should not get influenced by your personal goals, at least not too much.
Actually this is way way too soft language (IMH but often rabid O :-). As the List Maintainer you are A-Political period. The point of the list maintainers role is to provide an arms length from anything going through the List's TZ services.
I have a calm temperament, which kre rightly identified (on 2009-09-04) as a vital quality for this role.
Just to clear any misunderstandings that your statement might (or might not) cause, kre did _NOT_ identify your calm temperament as a vital quantity.
Particularly see the leap seconds mailing list, where in the past couple of years many discussions have regrettably become much more heated than befits the calibre of participant, and perl5-porters, where I've occasionally dealt with a prickly CPAN author.
So in the recent years when you joined discussions got more heated, and you take part. That's not good advertising. Also, being member of a perl mailinglist is hardly in any way relevant.
The job of a TZ maintainer is quite different from that of a perl module author.
Yes it is - it also is unlike many other IETF initiatives in that pertains to a continuously evolving service infrastructure, somewhat as DNS does, but without multiple authoritative roots. The TZ Database is as important for many systems as the master roots are in that context as well so its stability and transparency are key whoever runs the WG.
Also, while I don't know what prickly cpan author you dealt with, this hardly belongs here, and the fact that you send thinly veiled insults about other people (despite being anonymous) on unrelated lists is hardly evidence for a "calm temperament".
A TZ maintainer should not bring his personal fights on other mailinglists to his job as TZ maintainer.
Although it's not strictly necessary in a TZ Coordinator, I'm technically well qualified to look after the timezone code. C was my main programming language for about ten years, 1988 to 1998.
So coding isnt really needed for managing the mailing list and the TZ mirror practice per se one would think. What specifically would you do to make the processes more stable and bring more reporting entities into the practice of noticing the list when they change their time zones?
Ten years is hardly a long time - but I agree that's not vital, as others on this list have, in the past, shown exceptionally competence in this area and the willingness to help out if needed.
Again, programming is good but its not what this list is about and I don't see any Release Engineering experience or Build-Master experience in that description. Both of those are strong requirements in my opinion for whoever runs this as well if you want a stable process. Again - CPAN isn't enough of this in my opinion but hey it is what it is.
has been Perl, but I still regularly work in C. About half of the Perl modules that I've published are largely implemented in C, for one reason or another, and I'm a contributor to the Perl core, which is written in C. The quality of my code can be discerned by perusal of my published Perl modules.
Again, perl module author is hardly relevant for the job at hand.
It would be much more interesting to hear about your qualities as a TZ maintainer.
I.e. how you managed to collect TZ information, your relationships with the Master Timing Laboratories and the like.
As a bonus, I have some plans for how the database should develop from where it is now.
That sounds rather scary to me.
I am sure I am not the only one who'd rather not see any "developments", but merely the enourmous stability that we have seen and appreciated in the past.
as TZ Coordinator. Most obviously, I haven't been on the TZ mailing list very long. I tend to pick things up quickly, but this is a defect in the experience I'd bring to the role.
Right.
To be honest, the thought of you becoming maintainer and changing things a lot, as is clear form this and your previous mails, makes me outright scared.
The greatest thing about the olson database and associated code is stability, the strive for portability while keeping things simple.
You mean so code already in place to use is doesnt break? I agree. The legacy use and access models must remain stable no matter what. If new additions are to be added to the use models those should go through the WG and probably an IETF filing as the first place to start.
The impression you give me is that the next thing you'll do is add autoconf support, integrate it into your perl module etc. - I am exaggerating, but change is so extraordinarily negative in this area that proposing to "develop" into new directions instantly disqualifies somebody from the role.
Again - the key is autonomy in the role - no allegiances to anything including self-initiated efforts.
Just my ¢2.
-- Todd S. Glassey - CISM CIFI CTO Certichron Inc This message contains information which may be confidential and/or privileged. Unless you are the intended recipient (or authorized to receive for the intended recipient), you may not read, use, copy or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail and delete the message and any attachment(s) thereto without retaining any copies. Further we have a formal OPT OUT Policy posted on our website pertaining to the use of any Email Addresses gleaned or taken from any source, web, mailing lists, previous customer lists etc. In all instances we choose to formally OPT OUT and this notice constitutes formal disclosure that you may not collect, buy or sell or provide access to this email address or any pertaining to our DNS MX Record Publication License posted on the web at http://www-wp.certichron.com/?page_id=3947.
Hi All, Firstly I'd like to say I completely concur with Marc about this person. I have been a subscriber to this list for a couple of years, as I use the database. This is the first time I have actually felt that I should contribute to this discussion. I do not believe that this person is even closely appropriate for the role. zefram said : 'It's not necessary for me to be the TZ Coordinator in order to proceed with such a project, and I hope to do so anyway, but there's some level of convenience in the roles being colocated.' Convenient for who? Does this mean that you would find it easier to circumvent people who do not agree with your thinking. if this is the case then your next point : zefram said : 'I'm of the firm opinion that timezones ought to be abolished, in favour of universal use of Universal Time.' scares me quite a bit. it also shows just how much this person needs to spend some time in the real world. I have spend over 25 years using timezones (in the aviation industry - where UTC is quite well know) and anyone who thinks that abolishing them is a good idea, hasn't spent time using them around the world. It would be like mandating that English is now the Universal Language, and all other languages are abolished; completely impractical. And the fact that they have mentioned it just shows again how much this person is not suitable for the responsibility of such a position. My 5 Cents - NZ did away with 2 cents a few years ago... :) Regards. daff SOFTWARE ENGINEER andrew 'daff' niles | spidertracks | 117A The Square po box 5203 | palmerston north 4441 | new zealand P: +64-6-353-3395 | M: +64-21-515-548 E: daff@spidertracks.com www.spidertracks.com On 03/10/2012 11:07 PM, pcg@goof.com ( Marc) (A.) (Lehmann ) wrote:
On Sat, Mar 10, 2012 at 08:38:53AM +0000, Zefram<zefram@fysh.org> wrote:
With ado's retirement now almost upon us, I'd like to volunteer for the role of TZ Coordinator. Although I've only been directly involved, on the mailing list, for half a year, I've been peripherally involved for much longer. I'm very comfortable working in this space, and I believe I have the right personal qualities for the job. If this was a vote, I would vote against you.
The reason is that you are far from being calm or helpful - you often make broad claims, but when asked to explain them, you never do. Later they turn out to be evidence-less.
As a TZ maintainer, you should reason things out (at least once), and not insist on you being right based on authority, but based on evidence.
From previous threads on this list it also looks as if you often have a non-technical agenda, which is probably bad for a technical project which requires objective and impartial decisions ("calm").
As a TZ maintainer, you should not get influenced by your personal goals, at least not too much.
I have a calm temperament, which kre rightly identified (on 2009-09-04) as a vital quality for this role. Just to clear any misunderstandings that your statement might (or might not) cause, kre did _NOT_ identify your calm temperament as a vital quantity.
Particularly see the leap seconds mailing list, where in the past couple of years many discussions have regrettably become much more heated than befits the calibre of participant, and perl5-porters, where I've occasionally dealt with a prickly CPAN author. So in the recent years when you joined discussions got more heated, and you take part. That's not good advertising. Also, being member of a perl mailinglist is hardly in any way relevant.
The job of a TZ maintainer is quite different from that of a perl module author.
Also, while I don't know what prickly cpan author you dealt with, this hardly belongs here, and the fact that you send thinly veiled insults about other people (despite being anonymous) on unrelated lists is hardly evidence for a "calm temperament".
A TZ maintainer should not bring his personal fights on other mailinglists to his job as TZ maintainer.
Although it's not strictly necessary in a TZ Coordinator, I'm technically well qualified to look after the timezone code. C was my main programming language for about ten years, 1988 to 1998. Ten years is hardly a long time - but I agree that's not vital, as others on this list have, in the past, shown exceptionally competence in this area and the willingness to help out if needed.
has been Perl, but I still regularly work in C. About half of the Perl modules that I've published are largely implemented in C, for one reason or another, and I'm a contributor to the Perl core, which is written in C. The quality of my code can be discerned by perusal of my published Perl modules. Again, perl module author is hardly relevant for the job at hand.
It would be much more interesting to hear about your qualities as a TZ maintainer.
As a bonus, I have some plans for how the database should develop from where it is now. That sounds rather scary to me.
I am sure I am not the only one who'd rather not see any "developments", but merely the enourmous stability that we have seen and appreciated in the past.
as TZ Coordinator. Most obviously, I haven't been on the TZ mailing list very long. I tend to pick things up quickly, but this is a defect in the experience I'd bring to the role. Right.
To be honest, the thought of you becoming maintainer and changing things a lot, as is clear form this and your previous mails, makes me outright scared.
The greatest thing about the olson database and associated code is stability, the strive for portability while keeping things simple.
The impression you give me is that the next thing you'll do is add autoconf support, integrate it into your perl module etc. - I am exaggerating, but change is so extraordinarily negative in this area that proposing to "develop" into new directions instantly disqualifies somebody from the role.
Just my ¢2.
It is clear that I lack the vital quality of being respected by the mailing list participants. I have not yet earned it, and evidently it is not transferable or shortcuttable. My candidacy is untenable. I hope a better-qualified candidate emerges. (I was prepared for a substantive debate on policies of complete stasis versus careful development, in the context of the TZ database's unusually high requirement for stability. But the seriously distorted interpretation of my statements, bordering on a presumption of bad faith, make it difficult to meaningfully discuss the issue. However, the lack of respect that is presumably behind the distortion, by making me an otherwise unacceptable candidate, also renders the issue moot for the present. Best not flood the list with a debate that would be both heated and irrelevant.) -zefram
participants (4)
-
Daff -
pcg＠goof.com -
Todd Glassey -
Zefram