On Tuesday, 11 December 2012 at 13:19:56 UTC, foobar wrote:
> First of all - Yay!
>
> There are still a few open questions that need to be decided
> before a suitable process can be defined.
>
> I'd say we should _at most_
> support _one_ previous stable version with critical bug fixes
> only.

I agree with that as well, although I think that after a new major "stable" release, the previously stable should be supported (at a minimum kept available for download) for some time until the new stable is fully stabilized and most people have been able to adopt it. It may be good enough to just and pick and choose if the previous stable should get certain bug fixes or not until the support period runs out.

> B. should we have public pre-release versions?

A lot of people will want to use the latest available changes for actual development, so the "testing" or "pre-release" branch should be public and kept reasonably stable, although anything can happen, so it's not considered "stable", just "stable enough" given that it may be supporting new features and improvements that have been selected for the next major stable release.

> I think we should release additional "releases" - call them beta,
> pre-release, release candidates, whatever. These are for staging
> changes, allowing to field test new features and language changes
> before they are made final. Also allowing users to adjust their
> code-bases.

I think you'll need at a minimum experimental branches for testing out new ideas, the main development branch witch is considered unstable (the master branch is probably best for this one as was suggested), a pre-release or testing branch that is used for preparing for the next major stable release, and of course the current stable branch which only receives bug fixes up until the next pre-release branch is merged into stable.

One more thing, is that we should adopt a version numbering system that is appropriate to indicate major, minor, and bug fix releases. The method of major.minor.revision can work well for us, but there may be alternatives that will work even better depending on what the process ends up being.

What I'd hate to see continuing, is a major new release going out with no indication in the version number that it is a major new release as opposed to a minor revision change. For example, the current DMD stable is 2.060, and the next release will be 2.061, but it includes brand new poorly tested features, and one of them is still being debated on, therefore it may be subject to change. The next release will be anything but a minor update and it should not even be considered as a stable release, it's more like a pre-release version for testing and for adoption by those who absolutely need the latest "reasonably stable" version for their development work.

--rt

On Tuesday, 11 December 2012 at 19:57:55 UTC, Rob T wrote:
> On Tuesday, 11 December 2012 at 13:19:56 UTC, foobar wrote:
>> First of all - Yay!
>>
>> There are still a few open questions that need to be decided
>> before a suitable process can be defined.
>>
>> I'd say we should _at most_
>> support _one_ previous stable version with critical bug fixes
>> only.
>
> I agree with that as well, although I think that after a new major "stable" release, the previously stable should be supported (at a minimum kept available for download) for some time until the new stable is fully stabilized and most people have been able to adopt it. It may be good enough to just and pick and choose if the previous stable should get certain bug fixes or not until the support period runs out.
>

By support I meant specifically _bug fixes_. You can already download all previous released versions from the website and in no way am I arguing to change that policy.
Even if we ever get to a point where we don't want to keep older releases which I doubt very much (each zip is only a few MBs and therefore insignificant on today's storage) - we could still easily just checkout the specific release tagged in git and just build that.

>> B. should we have public pre-release versions?
>
> A lot of people will want to use the latest available changes for actual development, so the "testing" or "pre-release" branch should be public and kept reasonably stable, although anything can happen, so it's not considered "stable", just "stable enough" given that it may be supporting new features and improvements that have been selected for the next major stable release.

This is precisely what I addressed bellow. we have monthly build of our staging branch - call them monthly betas that include new upcoming features that are already stable enough to be released to the public for field testing and are tentative for the next actual release but until these feature actually get to a release they hold no guaranties and can be further modified based on the wider public testing - including changes in API. Once released, they do hold such guaranties of API stability. So these monthly betas will provide preview of language changes and allow people to prepare for future changes and also provide feedback.

>
>> I think we should release additional "releases" - call them beta,
>> pre-release, release candidates, whatever. These are for staging
>> changes, allowing to field test new features and language changes
>> before they are made final. Also allowing users to adjust their
>> code-bases.
>
> I think you'll need at a minimum experimental branches for testing out new ideas, the main development branch witch is considered unstable (the master branch is probably best for this one as was suggested), a pre-release or testing branch that is used for preparing for the next major stable release, and of course the current stable branch which only receives bug fixes up until the next pre-release branch is merged into stable.

See comment above. the pre-release will contain new features already stable enough to be consumes by the general public _before_ we the developers are ready to a commit finally to their API. E.g. Walter's release of DMD with attributes that was already tested and working but after release people argued about changing its syntax from [attributes] to @(attributes).

developers can have their own experimental branches for their own tests and new ideas, but once a feature reaches pre-release it should already be tested and working and ready for public consumption without commiting to a final API.

>
> One more thing, is that we should adopt a version numbering system that is appropriate to indicate major, minor, and bug fix releases. The method of major.minor.revision can work well for us, but there may be alternatives that will work even better depending on what the process ends up being.

I really don't care about the numbering scheme and this is irrelevant to the topic of this discussion. We are discussing the PROCESS of development. How the releases are tagged is completely beside the point and could be named after sweet delights, cat names, Parks or even digits of PI. I really don't care and it really is _not important_.
This is one of those fundamental things that are required to truly understand git - versions are the _content_ (code) they contain and are identified by a hash of that content.
This is pure bikesheding but why not: Why not extend the astronomical theme to releases as well? What would you say about the latest Pluto release of DMD? ;)
(Yeah, I know this is already used by the eclipse project..)

>
> What I'd hate to see continuing, is a major new release going out with no indication in the version number that it is a major new release as opposed to a minor revision change. For example, the current DMD stable is 2.060, and the next release will be 2.061, but it includes brand new poorly tested features, and one of them is still being debated on, therefore it may be subject to change. The next release will be anything but a minor update and it should not even be considered as a stable release, it's more like a pre-release version for testing and for adoption by those who absolutely need the latest "reasonably stable" version for their development work.
>
> --rt

On Tuesday, 11 December 2012 at 23:15:27 UTC, foobar wrote:
> By support I meant specifically _bug fixes_. You can already download all previous released versions from the website and in no way am I arguing to change that policy.
> Even if we ever get to a point where we don't want to keep older releases which I doubt very much (each zip is only a few MBs and therefore insignificant on today's storage) - we could still easily just checkout the specific release tagged in git and just build that.

That's what I meant too, I agree with you on this point.

> This is precisely what I addressed bellow. we have monthly build of our staging branch - call them monthly betas that include new upcoming features that are already stable enough to be released to the public for field testing and are tentative for the next actual release but until these feature actually get to a release they hold no guaranties and can be further modified based on the wider public testing - including changes in API. Once released, they do hold such guaranties of API stability. So these monthly betas will provide preview of language changes and allow people to prepare for future changes and also provide feedback.

Having a pre-release build that can be downloaded and installed would be very nice to have if that's what you mean. Currently, to get DMD 2.061 "alpha" I have to jump through hoops to get it to a point where it is operational, and that is not so good as it limits severely how many users will be able to test it out.

> See comment above. the pre-release will contain new features already stable enough to be consumes by the general public _before_ we the developers are ready to a commit finally to their API. E.g. Walter's release of DMD with attributes that was already tested and working but after release people argued about changing its syntax from [attributes] to @(attributes).
>
> developers can have their own experimental branches for their own tests and new ideas, but once a feature reaches pre-release it should already be tested and working and ready for public consumption without commiting to a final API.

OK, but who has already tested it and how many people have been able to test it and comment on it? I was thinking more along the lines of how Debian does it, with a 4 staged release process: experimental => unstable => testing (pre-release) => stable.

We could probably do away with a  common "experimental" branch, leaving 3 common branches.

A common "unstable branch" will allow more people to test out newly introduced ideas well before they become merged into pre-release, and that may help avoid problems as we're seeing with the sudden introduction of UDA's.

I am hoping that we can have a pre-release version that will be stable enough to be used on real-world applications, knowing that some things can change but not in a major way. If I don't mind dealing with major changes, then I would instead make use of what's in the "unstable" branch, but I expect mostly compiler devs will be using unstable, and no one will be using it on anything important.

>
> I really don't care about the numbering scheme and this is irrelevant to the topic of this discussion. We are discussing the PROCESS of development. How the releases are tagged is completely beside the point and could be named after sweet delights, cat names, Parks or even digits of PI. I really don't care and it really is _not important_.
> This is one of those fundamental things that are required to truly understand git - versions are the _content_ (code) they contain and are identified by a hash of that content.
> This is pure bikesheding but why not: Why not extend the astronomical theme to releases as well? What would you say about the latest Pluto release of DMD? ;)
> (Yeah, I know this is already used by the eclipse project..)

I'm very surprised by your comment on version numbers and I hope you are a significant minority holder of that view.

How version numbers are assigned and what the number represents has to be made a defined part of the release process otherwise you'll end up with a meaningless random number or symbol (or nothing) for each new release, and the only information it will supply to you is "here's a new release". I don't see that as an improvement to the current situation, it just perpetuates the existing problem where users of the D compiler have no easy way to know if a new release is a major ground breaking one, or a minor one, or just a simple bug fix. In order to find out what a new release means in terms of the magnitude of changes, one has to read through a technical change log, and read through endless forum posts, and possibly even take a look at the commit log. Why not do something better than that when it's so easy to do?

For example, if I see that the stable version has been updated, I want to quickly know if it's a bug fix update or something more significant.

For mission critical applications, I'll jump on bug fix releases quickly, but I'll stay clear of any major releases up until it has had enough time to fully stabilize. I do this kind of filtering for all new releases of software that I use, and it's very easy to do when there's a version number that has meaning to it.

--rt

On Wed, Dec 12, 2012 at 02:03:56AM +0100, Rob T wrote: [...]
> OK, but who has already tested it and how many people have been able to test it and comment on it? I was thinking more along the lines of how Debian does it, with a 4 staged release process: experimental => unstable => testing (pre-release) => stable.

FYI, this is a misrepresentation of how Debian works. The actual process is unstable => testing => stable. I.e., most new packages are uploaded directly to unstable.

The experimental branch is for packages that aren't fully working, may break your packaging system, contain untested code, etc.. Some stuff in experimental is never migrated to unstable, because they're for, um, experimenting with volatile or incomplete projects deemed unsuitable for general use.

To apply the analogy to D development, this would be local git branches where, say, Walter is toying around with incomplete code for a new feature which may not even be compilable yet. The unstable branch would be more-or-less complete, compilable code that haven't been extensively tested yet (it more-or-less works, but may crash horribly, use at your own risk, etc.). After a period of limited use, it gets merged into testing, where a larger audience will begin using it. After it's been proven in the field, then only it gets put into stable.

The experimental branch is really not needed as a formal part of the process, since the developers can just use temporary local git branches for that purpose without needing to push it to a public repository. So really, the Debian process isn't really that different from what you propose below:


> We could probably do away with a  common "experimental" branch, leaving 3 common branches.
[...]


T

-- 
Microsoft is to operating systems & security ... what McDonalds is to gourmet cooking.

On Monday, 10 December 2012 at 23:41:25 UTC, Andrei Alexandrescu wrote:
> In turn, I'll be collecting thoughts and opinions in this thread, distilled from previous discussions. We should develop a few simple git scripts (such as git-start-new-feature or git-start-bugfix etc) supported by an equally simple piece of documentation describing how to start a new release, fix a bug, experiment with a new feature, and such.

There may be some helpful scripts to facilitate a new workflow, but the examples given I feel just translate to learning a D specific git commands. Seriously you'll end up with a layer of abstraction that will make it harder for those familiar with git to understand and limit the ability of newer users to understand the state their working copy is in.

git-start-new-feature:
$ git checkout devbranch
$ git checkout -b newfeaturename

git-start-bugfix:
$ git checkout stablebranch
$ git checkout -b fixbugxxx

How these should be folded back is the harder part. For example the bug fix should then be into stablebranch and devbranch.

There is also the matter of pulling in changes of your stable or dev branch as you work, this is done with the add --rebase switch (and I believe opens the doors for more merge conflicts than a standard merge).

> (One piece that has been brought forward is http://nvie.com/posts/a-successful-git-branching-model/ - something to keep in mind.)

I would like to note that these simple flows do not mimic our world. We have three projects that need to be marked for release in tandem. It doesn't need address now, but it should be noted.

I think it would be cool if the idea behind workbench project someone started was used officially to sync dmd/phobos/dlang.org and provide any of these needed deployment scripts. It would add to the complexity but much of it is already there this would just make it more apparent.

On Wednesday, 12 December 2012 at 01:03:59 UTC, Rob T wrote:
> On Tuesday, 11 December 2012 at 23:15:27 UTC, foobar wrote:
>> By support I meant specifically _bug fixes_. You can already download all previous released versions from the website and in no way am I arguing to change that policy.
>> Even if we ever get to a point where we don't want to keep older releases which I doubt very much (each zip is only a few MBs and therefore insignificant on today's storage) - we could still easily just checkout the specific release tagged in git and just build that.
>
> That's what I meant too, I agree with you on this point.
>
>> This is precisely what I addressed bellow. we have monthly build of our staging branch - call them monthly betas that include new upcoming features that are already stable enough to be released to the public for field testing and are tentative for the next actual release but until these feature actually get to a release they hold no guaranties and can be further modified based on the wider public testing - including changes in API. Once released, they do hold such guaranties of API stability. So these monthly betas will provide preview of language changes and allow people to prepare for future changes and also provide feedback.
>
> Having a pre-release build that can be downloaded and installed would be very nice to have if that's what you mean. Currently, to get DMD 2.061 "alpha" I have to jump through hoops to get it to a point where it is operational, and that is not so good as it limits severely how many users will be able to test it out.
>
>> See comment above. the pre-release will contain new features already stable enough to be consumes by the general public _before_ we the developers are ready to a commit finally to their API. E.g. Walter's release of DMD with attributes that was already tested and working but after release people argued about changing its syntax from [attributes] to @(attributes).
>>
>> developers can have their own experimental branches for their own tests and new ideas, but once a feature reaches pre-release it should already be tested and working and ready for public consumption without commiting to a final API.
>
> OK, but who has already tested it and how many people have been able to test it and comment on it? I was thinking more along the lines of how Debian does it, with a 4 staged release process: experimental => unstable => testing (pre-release) => stable.
>
> We could probably do away with a  common "experimental" branch, leaving 3 common branches.
>
> A common "unstable branch" will allow more people to test out newly introduced ideas well before they become merged into pre-release, and that may help avoid problems as we're seeing with the sudden introduction of UDA's.
>
> I am hoping that we can have a pre-release version that will be stable enough to be used on real-world applications, knowing that some things can change but not in a major way. If I don't mind dealing with major changes, then I would instead make use of what's in the "unstable" branch, but I expect mostly compiler devs will be using unstable, and no one will be using it on anything important.
>
>>
>> I really don't care about the numbering scheme and this is irrelevant to the topic of this discussion. We are discussing the PROCESS of development. How the releases are tagged is completely beside the point and could be named after sweet delights, cat names, Parks or even digits of PI. I really don't care and it really is _not important_.
>> This is one of those fundamental things that are required to truly understand git - versions are the _content_ (code) they contain and are identified by a hash of that content.
>> This is pure bikesheding but why not: Why not extend the astronomical theme to releases as well? What would you say about the latest Pluto release of DMD? ;)
>> (Yeah, I know this is already used by the eclipse project..)
>
> I'm very surprised by your comment on version numbers and I hope you are a significant minority holder of that view.
>
> How version numbers are assigned and what the number represents has to be made a defined part of the release process otherwise you'll end up with a meaningless random number or symbol (or nothing) for each new release, and the only information it will supply to you is "here's a new release". I don't see that as an improvement to the current situation, it just perpetuates the existing problem where users of the D compiler have no easy way to know if a new release is a major ground breaking one, or a minor one, or just a simple bug fix. In order to find out what a new release means in terms of the magnitude of changes, one has to read through a technical change log, and read through endless forum posts, and possibly even take a look at the commit log. Why not do something better than that when it's so easy to do?
>
> For example, if I see that the stable version has been updated, I want to quickly know if it's a bug fix update or something more significant.
>
> For mission critical applications, I'll jump on bug fix releases quickly, but I'll stay clear of any major releases up until it has had enough time to fully stabilize. I do this kind of filtering for all new releases of software that I use, and it's very easy to do when there's a version number that has meaning to it.
>
> --rt

To summarize:
1. Yes, I do suggest that "beta" versions will be available to download and prominently displayed on the download web-page.
2. The version scheme is meaningless. Please check out http://www.mozilla.org/en-US/firefox/channel/#firefox as an example. It's perfectly clear, you can choose what Mozilla calls a channel - i.e "release" or "beta".
We can put both in a two column table with high-level description of changes and links to more-detailed change logs.
3. Debian is a HUGE project with lots of manpower. D is not. I think it is enough to have two _publicly visible download channels_ - release and beta (testing). Those are the only two that should be formally defined. There is no need to define prior stages of development as people can just informally create their own local branches for their own experiments and they could also push them upstream to share with other developers without any requirement to list an executable on the official download page. The source code is available on github - if you wanted to you could pull whatever branch and build it yourself at your own risk.
4. The only official executables on the download page are for two channels - release and beta. You can grab the latest stable "release" that only gets critical bug-fixes or the monthly beta that also contains preview features such as the upcoming user-defined attributes. You can also grab previous versions of both release channels by clicking the "previous versions" link. Anything else has zero guaranties and you are required to build yourself from source.

On 12/12/12 1:37 AM, Jesse Phillips wrote:
> There may be some helpful scripts to facilitate a new workflow, but the
> examples given I feel just translate to learning a D specific git
> commands. Seriously you'll end up with a layer of abstraction that will
> make it harder for those familiar with git to understand and limit the
> ability of newer users to understand the state their working copy is in.

I disagree. I wrote a few git scripts for Facebook-specific workflows and a lot of people (including me) use them.

Beyond that we need to have a wiki page with workflows:

"To initiate a new feature"

"To initiate a bug fix"

"To initiate a library addition without formal review"

"To initiate a library addition with formal review"

...

> git-start-new-feature:
> $ git checkout devbranch
> $ git checkout -b newfeaturename
>
> git-start-bugfix:
> $ git checkout stablebranch
> $ git checkout -b fixbugxxx
>
> How these should be folded back is the harder part. For example the bug
> fix should then be into stablebranch and devbranch.

All of these will be part of the instructions and the macros. The branch names will be standardized.

> There is also the matter of pulling in changes of your stable or dev
> branch as you work, this is done with the add --rebase switch (and I
> believe opens the doors for more merge conflicts than a standard merge).

All of these should be subsections in the documentation.

"If your branch has conflicts"

"If your branch became really messed up"

...

>> (One piece that has been brought forward is
>> http://nvie.com/posts/a-successful-git-branching-model/ - something to
>> keep in mind.)
>
> I would like to note that these simple flows do not mimic our world. We
> have three projects that need to be marked for release in tandem. It
> doesn't need address now, but it should be noted.
>
> I think it would be cool if the idea behind workbench project someone
> started was used officially to sync dmd/phobos/dlang.org and provide any
> of these needed deployment scripts. It would add to the complexity but
> much of it is already there this would just make it more apparent.

What is the workbench project?


Andrei

On Wednesday, 12 December 2012 at 16:14:44 UTC, Andrei Alexandrescu wrote:
> I disagree. I wrote a few git scripts for Facebook-specific workflows and a lot of people (including me) use them.

May have been a knee jerk reaction. Good to hear it has been used.

>> git-start-new-feature:
>> $ git checkout devbranch
>> $ git checkout -b newfeaturename
>>
>> git-start-bugfix:
>> $ git checkout stablebranch
>> $ git checkout -b fixbugxxx

> All of these will be part of the instructions and the macros. The branch names will be standardized.

I'm not sure I follow on the name standardizing. Doesn't that make it so a person can only work on one bugfix and one feature at a time? The name used for the dev and stable branches should be standardized (I don't care much what master is, but I generally like it as the dev branch)

> All of these should be subsections in the documentation.
>
> "If your branch has conflicts"
>
> "If your branch became really messed up"

Yep, just pointing out where I see the difficulty and scripts may be of more use.

> What is the workbench project?
>
>
> Andrei

Found it, by Nathan Swan

http://forum.dlang.org/post/ygwzndxbwzrxzlhuooty@forum.dlang.org

On 12/11/2012 12:41 AM, Andrei Alexandrescu wrote:
> In turn, I'll be collecting thoughts and opinions in this thread, distilled from
> previous discussions. We should develop a few simple git scripts (such as
> git-start-new-feature or git-start-bugfix etc) supported by an equally simple
> piece of documentation describing how to start a new release, fix a bug,
> experiment with a new feature, and such.
>
> (One piece that has been brought forward is
> http://nvie.com/posts/a-successful-git-branching-model/ - something to keep in
> mind.)
>
> Please chime in with ideas and thoughts.

It seems to me that while process is clearly very important, what's maybe necessary first is to identify what the actual results of the process are intended to be.  What should a 'stable version' of D actually mean, in practice?  What should its lifetime be?  Should there be interim releases in-between stable versions which can introduce e.g. breaking features, and should those be treated only as beta versions or as releases in their own right?  How is that coupled (or decoupled) from releases of the library? etc.

I'd personally rather get those issues addressed out before talking about git methods, which to be honest I suspect will be similar no matter what the release model.

So, with that in mind, here are some thoughts/suggestions.

People have talked about Debian's unstable => testing => stable model, but instead, why not consider something more akin to Ubuntu's LTS and interim releases?

   * STABLE/Long-term support releases would be guaranteed to receive bugfixes
     and have no breaking changes for 3 years.

   * A new LTS release would be made every 2 years, so that there would be a
     1-year overlap between the current LTS release and the previous one.

   * Optionally, non-breaking new features could be included in LTS release
     updates during this timeframe, subject to strict testing.  Such new
     feature updates should only go to the latest LTS release (so, during the
     1-year overlap period, the older LTS would continue to receive bugfixes
     but not have new features added).  The process for including new features
     should probably be more liberal for Phobos than for other parts of the D
     toolchain.

   * In between LTS releases, there should be regular (3- or 6-monthly?)
     interim releases that have gone through testing and are considered
     'stable' in a working sense.  These releases _can_ make breaking changes,
     subject to strict conditions, and should be more liberal about new feature
     inclusion in general.  The idea should be that the interim releases
     converge towards the next LTS release, so the conditions for make breaking
     changes and the testing of new features both become more and more
     stringent the closer to the next LTS release you are.

   * For preference, deprecated features to be 'removed' by simply removing
     documentation and support for a feature rather than removing the feature
     itself (thinking here particularly of Phobos and Walter's observations).

The time periods involved could of course be tweaked, e.g. an LTS release might be supported for 5 years and be released every 3 or 4.  There could also be an even larger-scale cadence (10 years?) for really major redesigns.

The above reflects my personal preference that I'd rather have a language which is willing to continue to iron out annoying idiosyncrasies or bad design decisions -- but which can still provide a good stable base for development, making sure that there is a good overlap period between LTS releases so that developers have a substantial amount of time to update their codebases.

On Wed, Dec 12, 2012 at 07:04:17PM +0100, Joseph Rushton Wakeling wrote: [...]
> It seems to me that while process is clearly very important, what's maybe necessary first is to identify what the actual results of the process are intended to be.  What should a 'stable version' of D actually mean, in practice?  What should its lifetime be?  Should there be interim releases in-between stable versions which can introduce e.g. breaking features, and should those be treated only as beta versions or as releases in their own right?  How is that coupled (or decoupled) from releases of the library? etc.
> 
> I'd personally rather get those issues addressed out before talking about git methods, which to be honest I suspect will be similar no matter what the release model.

+1. Thanks for the reminder to not lose sight of the forest for the trees.


> So, with that in mind, here are some thoughts/suggestions.
> 
> People have talked about Debian's unstable => testing => stable model, but instead, why not consider something more akin to Ubuntu's LTS and interim releases?
> 
>    * STABLE/Long-term support releases would be guaranteed to receive
>      bugfixes and have no breaking changes for 3 years.
> 
>    * A new LTS release would be made every 2 years, so that there
>      would be a 1-year overlap between the current LTS release and the
>      previous one.
[...]
> The above reflects my personal preference that I'd rather have a language which is willing to continue to iron out annoying idiosyncrasies or bad design decisions -- but which can still provide a good stable base for development, making sure that there is a good overlap period between LTS releases so that developers have a substantial amount of time to update their codebases.

I like this idea!!

I think this is much better than the current choice of either breaking existing code and annoying existing users or living with bad design decisions forever. One year is a good amount of time to upgrade people's codebases, so we won't be hampered by bad design decisions in the past, but can move forward with breaking changes. Freezing the language along with bad design decisions is what made C++ the monster that it is today.

(Of course, the actual overlap times can be tweaked, but I definitely support the idea of being able to introduce breaking changes *and* not immediately alienate a good proportion of the userbase.)


T

-- 
The peace of mind---from knowing that viruses which exploit Microsoft system vulnerabilities cannot touch Linux---is priceless. -- Frustrated system administrator.