8

Do have a policy on answering questions on unreleased code and if we don't should we?

I've always assumed that we don't answer questions about alpha/beta/RTM etc. code - but that's an assumption, do we have a policy and if not should we, and should it be in the FAQ?

=== edit ===

I guess I'm more interested in whether we should put something in the FAQ about this really

2
  • Not sure you can put something in the FAQ if it can't be decisive which it appears we are not. Maybe we need to come up with a list of the proper way to ask questions regarding pre-release code. Much like the How do I ask a question section.
    – Brent Pabst
    Commented Sep 6, 2012 at 1:43
  • 2
    I'm not sure it's worth putting anything in the FAQ any more, especially now that we've been told we're not supposed to slap people around the ears with it. Quite frankly, it's become about as useful as an appendix - left over from ancient times but no longer serving a useful purpose.
    – John Gardeniers
    Commented Sep 6, 2012 at 10:00

5 Answers 5

Reset to default
16

As long as they are of professional quality, I think we should actively encourage people asking questions about pre-release technology.

For example, if someone is asking about Windows 2012 clustering during its RC phase, and getting answers, it sets up the community to possibly be a go-to place for that technology. Experts tend to be interested in new things. I promise you the foremost experts in Windows 2012 clustering will be experimenting with it before it is officially released.

Slapping people with a FAQ that says "this isn't released yet" would turn off many of the sort people that could grow expertise in the community.

4
  • Definitely this. Just because it doesn't have the "production seal of approval" from Redmond, doesn't mean that it's not being tested, evaluated, and pummeled by professionals looking to put it through its paces.
    – Shane Madden
    Commented Sep 7, 2012 at 5:50
  • Whilst I agree with this the unfortunate thing is we don't attract that kind of professional. The foremost experts who are doing this in their labs will have support contracts and they'll reach for them rather than turning to the internet. How we change that I don't really have any ideas about.
    – user9517 Mod
    Commented Sep 7, 2012 at 7:43
  • 1
    The "danger" in this is that answers to beta software problems might not be correct for the RTM version. This would require a high amount of diligence with tags to show that these questions are for betas or RCs. We already have a hard enough time keeping tags straight.
    – MDMarra
    Commented Sep 7, 2012 at 10:40
  • 2
    @lain: that may be true about software from Redmond or other big software vendors, but when we look at the OSS side of things, the support infrastructure isn't so clear-cut and centralised. Questions about immature technology (like btrfs) should be encouraged.
    – Hubert Kario
    Commented Sep 9, 2012 at 15:22
6

Judge each question on its merits. For many of us testing pre-release versions of whatever is part of our jobs. For some it's nothing more than curiosity or that idiotic desire to always be the first one to run it. More often than not this shows in what is asked and how it is asked. If it appears to be a question regarding a professional situation then treat it as such. If it appears to be someone just playing with technology either ignore it or vote to close (my preferred option).

2
  • I agree. Almost along the lines of being Technology Early Adopters. We used to BETA test new versions of ERP packages all the time, but as Professionals we knew whether or not it was ready for use in production. There isn't a firm line, its very gray.
    – Brent Pabst
    Commented Sep 6, 2012 at 1:42
  • 4
    @Brent, in one role I was tasked with getting pre-release versions of Windows so that the software developers could start working with it as early as possible to ensure the software had computability with it by the time it became a release version.
    – John Gardeniers
    Commented Sep 6, 2012 at 1:51
4

I'm perfectly OK with answering questions regarding RTM code since after all, at least with MSFT products, this means most enterprises, SAs and devs have access to the final release bits. That may not be the case with other vendors but RTM for Windows and Office has always meant that it is available to many people just not on Joe Blow's laptop at home yet.

As for pre-RTM code I'd be hesitant to use it in a large environment. That being said how many of us used Gmail while it was in "beta". So I would go with a one-off. If its software that is well known to still be classified as "beta" then why not, otherwise, nope, off topic.

Then again to make it easy for the FAQ, all beta/alpha stuff is off-topic. Unless the OP has a really good reason for bringing it up.

3

This all seems to come back to the argument of "What is Professional?". My personal view on this is that Professional means using code which has been released/otherwise distributed with the explicit (or at least strong implicit) intent that it be used by the public in production environments.

Using code which has not been released with that intent is, in my opinion Not Professional, and our answer should be "Don't do that" or "We can't help you, you need to talk to the vendor."

To give a real-world example: we take FreeBSD questions on the site, but if someone came to us and said "I just grabbed the latest -CURRENT and it keeps crashing with [insert error here] -- what do I do?" our answer should be "You need to post that to the freebsd-current mailing list so the developers can help you out. You shouldn't be running -CURRENT in production environments."

4
  • What about things such as MSDN versions of say Windows Server, which are made available so that we can work with it to prepare for it in a production environment when it is eventually officially released to the public? The way I see it these are systems we must deal with at the professional level, often having to build entire networks of such systems, yet which don't meet your definition of professional. Sorry but I believe you've taken too narrow a view in regards to what is professional, possibly because you don't work in those environments.
    – John Gardeniers
    Commented Sep 6, 2012 at 9:58
  • 1
    @John the problem with RCs and such is that they have the pesky habit of not working the same after release. If they're in the RC or beta stage and you're seeing odd behavior, you should file a bug report with Microsoft (or whoever), not post about it on SF. That's what the whole Beta and RC phase is for, right? If we take questions on prerelease code, we'll amass a bunch of q&as that are close but may not be accurate or relevant to the finished product.
    – MDMarra
    Commented Sep 6, 2012 at 10:24
  • @JohnGardeniers That's an interesting point (albeit a little Microsoft-specific) -- I would say if an MS Release Candidate is widely distributed enough and generating enough quasi-production interest it should receive a special tag (windows-2008-server-rc1 or something similar) as a general-case exception because MS is special...
    – voretaq7 Mod
    Commented Sep 6, 2012 at 16:07
  • @voretaq7 yeah the difference between a MS RC/CTP/DeveloperPreview or beta and freebsd-current is that the beta is long lived, and with the Windows8/Server2012, many MSFT downloads mentioned support for particular pre-RTM releases, while current is a point in time. As far as what is professional, yes don't install the latest freebsd current or windows RC on the important servers. However, depending on the nature of your job/shop DO install it on a dev/test/qa environment and possible your workstation. Try to port your software to the next OS before its released.
    – Justin Dearing
    Commented Sep 7, 2012 at 17:40
3

If a commercial product is available from a company to a large audience with support, we should take questions on it.

If there are release candidates, release previews, or anything else that a normal company couldn't get support on, then we shouldn't take those questions.

Getting into the terminology is a bit tricky since RTM means different things to different companies. What we should look at is the availability of supported code.

If a free product is available to a large audience, but there is no direct support from a commercial entity available (many *nix pieces of code), then a couple of things should be factored in.

  1. Is this code meant to be a production release. For example, has it been committed to its repository's stable branch or equivalent?

  2. If there is no "stable" branch equivalent, was a particular release intended for production use? Plenty of prerelease code has a disclaimer like this in the manpage or readme.

  3. Have the maintainers made any "official" statement about whether the code is a stable production release for a specific platform?

6
  • What about Linux (the kernel) or other open-source projects with no official "support"? We do as a matter of practice take questions on software for which the only support channel is "Ask the intertubes"...
    – voretaq7 Mod
    Commented Sep 5, 2012 at 16:23
  • 1
    @voretaq7 This isn't meant to address whether or not something already released is valid for the site, but rather when something that is on the cusp of release is valid. In the case of the Linux kernel, for example, it's "released" when Linus commits it to Stable, isn't it? Most "free software" is in unstable or testing one day, and then stable the next. Since there isn't need for marketing fanfare, this is pretty cut and dry.
    – MDMarra
    Commented Sep 5, 2012 at 16:28
  • True, but FreeBSD (as an example) issues Alphas, Betas and Release Candidates prior to cutting an official OS release -- those are "on the cusp" (often there's no change between the last RC and the production release), widely distributed, and "supported" the same way any FreeBSD release is, but I wouldn't run one in production...
    – voretaq7 Mod
    Commented Sep 5, 2012 at 16:32
  • @voretaq7 I use OEL and get kernel support - but I know what you mean ;)
    – Chopper3
    Commented Sep 5, 2012 at 16:36
  • @voretaq7 I don't know a lot about the *BSD community, but surely releases can't be a whole lot different than other *nix ones. Regardless of what the BSD community calls it, I assume that one single set of bits is considered the "production" code for a given release (analogous to Linux stable repos). Is this not the case?
    – MDMarra
    Commented Sep 5, 2012 at 17:02
  • @MDMarra multiple bits in some cases, and "HEAD" (whatever's in CVS) in OpenBSD's case (Canadian FREAKS!) - but yes. Your edit addresses my concern (in many ways better than my answer did) -- it's the intent that something go into production that matters (i.e. "Just because they distributed a CD of Release Candidate 1 doesn't mean we think you should be putting it on mission-critical systems")
    – voretaq7 Mod
    Commented Sep 5, 2012 at 19:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .