Print

[sridharb]

Admins,

Why don't you create a svn/git repository with these releases (not zip files, but the ones contained in the zip) and have labels like 2_4_12 or more importantly STABLE, LATEST, DEV etc. so that updating from your site is merely asking TortoiseSVN/Git to pull the latest STABLE (which I am interested in).

This way, you are only maintaining a binary folder structure along with appropriate check-ins, tags and of course branches when there are major changes.

What do you think?

Regards,
Sridhar

[Gregg]

What do I think?

Let's look at the situation here for a better view of the big picture.

[We do]

• Download the source for all the different pieces from all the different places when new releases come out
• Compile all the pieces for a number of different Apache/VC Versions and Architectures,
• Package it all up with readme files and make it available to download so that most anyone can install/upgrade

[/We do]

and now you also want

[We do]

• Set up an svn or git repository and all that entails

[/We do]

All so the only thing you have to do to stay current is;

[You do]

• snv up

[/You do]

I'll have to think about that and discuss it with Mario. Please do be careful not to strain yourself on the next update if we have not gotten the repository up live by that time.

[mario]

SVN nor GIT was desinged for binary files. Also you can't patch a running windows .exe or .dll (.so in apache case (just the naming from linux)) file. The Upgrade is just to download our zip file, stop apache, replace the file in the bin and modules folder and start apache.
So your request makes no sense in my eyes.

[sridharb]

Thanks, Mario and Gregg for replying.

Gregg: yes, you have the big picture correct. However, I read some angst in your response. We appreciate the service that is being provided here and this was a request for making things a little more easier for administrators (like me). Ultimately, even if it results in just an "svn up" from our side to stay current, our gratitude towards your services will only increase. Now, if there is an attitude of "I (ApacheHaus) have "suffered (worked)" to give you this - so you should as well to use it!", please make it clearer as it doesn't make sense with what you guys are doing all along. If I am misreading this, then please ignore.

Mario: That SVN/GIT is more designed for storing/patching text-based differences is obvious. That it does well. However, one shouldn't forget that it can store binary files (in some cases, fairly efficiently with compression). Patching would involve (since it knows that it is binaries that are being updated), replacing the entire file. So, what the svn repository would become is essentially a meta-zip file of your current zip-distributions containing the binaries and the information contained in the filenames (which denote the versions) in a much more efficient manner using tags. It is no less efficient, but in my mind, much more useful. This can be used by software like TortoiseSVN to efficiently maintain/upgrade/downgrade to different versions with a single command.

Regards,
Sridhar

[Gregg]

How can a tag (say 2.4.12 like here: http://svn.apache.org/viewvc/httpd/httpd/tags/ ) in svn denote the version any better? The version is 2.4.something or 2.2.something, not much clearer a svn tag of same would be. I suppose we could add the OpenSSL version to the zip file names if this is where you are coming from. I must admit it has been a bad year for OpenSSL! We've gone through five OpenSSL releases in the lifetime of 2.2.29. When it rains it pours! 

As for my first reply, you have it partially right. My thoughts at the time were "Don't we do enough?" and "is it that difficult to upgrade by just replacing the files in the /bin and / modules folder (which is all that is really needed)?" But then I'm not managing 100 servers in a data center either.

If you are however, then you are working for (being paid) or own (making the big bucks) a commercial entity that has deep enough pockets to pay someone to do it and more than likely maintain your own svn. Download and extract the zips and do your own svn thing as you wish. As for updating a slew of servers, sc.exe and a batch file can go a long way here. Update one server manually, run the batch file and sit back and drink coffee.

I would not go as far as saying I've/we've "suffered" but we do not get paid to do this either. We give our free time to do this at our own expense (yes, we have expenses). I'm not saying you or anyone else do not appreciate this fact but we can only give what we have time and energy for.

As for STABLE, LATEST, DEV etc., we only do stable releases, no dev, we're not really prohibited from doing it, it's just frowned upon by the devs at the ASF. The latest is the stable, there just happens to be 2 stable branches. We have in the past had betas available, but the source code for those was released by the ASF as beta. And there in lies one of the key points, we only release when new source is released by the author/organization/etc. If not, you could have had 2.4.11 (for 2 weeks) but it failed during the 72 hour testing stage before being released.

As for downgrading, I cannot speak for Mario but I frown upon it which is why we do not make old versions available. Of course that doesn't mean you cannot hold onto the old zip files you have downloaded already in the past. I still have the original Apache 1.3.0 installer I downloaded from apache.org back in June 1998 and ran on Windows 95 horded away

You do not have a bad idea, but I see no benefit for a majority of our users who seem to do just fine with how things are now. It would also kill any opportunity for us to maintain a reasonably accurate count of how many packages go out the door. Call me crazy, but I like to know these things!  It helps me understand our user base to some degree. It also allows me to see trends in our user base that a free-for-all svn setup would not. At least not as easily as I can get this information currently.

BTW, the biggest request has and I expect will remain to be have an installer.

Cheers

Edit: You'd think I'd have learned proper English by now.

[mario]

With my not always proper english:

I don't see a reason why there is a need for installing an old vulnerable version. The main fact that the ASF does releases a new version are mostly security fixes. Seldom a functional fix.

I also agree with Gregg about the download counting. That is why we don't put our files into some cloud file store.

For the installer: I personally hate them. That was my main reason to come to Apache Lounge and ApacheHaus  With a simple zip file I know what happens. For sure my skills have reached a higher as when I started using apache with 1.3.19, but still I like the zip file. Maybe later a 7z format.

[sridharb]

Lest there be any misunderstanding - let me make it clearer:

1. You guys are doing a fine job.
2. I do not care for any versions that you don't currently provide (i.e. not interested in Apache's DEV tip etc.)
3. What I was proposing was to add a small layer on top of what is being done so that some users would be able to maintain their servers more easily. For e.g. I have been using the svn (and now git) versions of phpMyAdmin for quite a while and I rely on their STABLE tag - just keep "git pull"ing the version that they decide to call stable. Similarly, a handful of other open-source projects. I am comfortable with this method and thought that it might help others if AH rolled it out as well.
4. As I said in my reply, what I am proposing is not really that different from making available a list of your already published binaries - i.e. in terms of space and bandwidth it will not be that different. Most people will usually be interested in the tip, with rare pulls of older versions in special circumstances.
5. I am not saying that the svn tag will be clearer than the filename or that the current filenaming scheme is somehow flawed. What I said was that the svn tag can be constructed with the metadata that is currently in the filename, with maybe openssl's version number (as Gregg mentions).
6. Everyone understands the reasons for upgrading. Let me address downgrades: It is possible that I (temporarily) need to roll back to a version that worked, given that a newer version is not working now. It is as simple as retrieving that zip file and installing it. Or it is as simple as svn update -r TAG.
7. This request comes from me administering my home server and not something that I get paid big bucks to do.
8. I don't care about an installer much. I am happy with the format that you are providing.
9. I don't know how to address your need for download counting through this method - I guess it is possible in a roundabout way through svn logs etc., but probably is more cumbersome.

I guess we have discussed this through well enough and have reached an impasse (at least for now). Thanks for listening.

Sridhar

[Gregg]

#1, Thanks, we try our best to make it as easy for everyone as we can. Now even more since we have picked up a lot of users that used to download the installers from apache.org. The only reason I mentioned installers is because it is hard to break people of what they are used to. But once anyone manually installs Apache and then manually upgrades once, they usually realize "Hey, you know that wasn't so bad after all."

OK onto #6 as I do know that well. Temporary yes, to keep the sever up while you are trying to figure out what the heck just went wrong. Granted, I do not have to download and extract zip files first, but I used to. Now I just push the new builds over to the servers (I have 2) over the LAN, with batch files, but not before those batch files backup the current state of Apache in case I need to undo it right away. I was being serious about batch files and sc.exe going a long way.

I will keep your svn idea in the back of my head tasting it. I've been tasting it the last couple days. There's just a little more to it than setting up svn and going live (not including my download count preference) but I'm not going to get into all that.

Thanks for using Apache Haus,

Gregg