On Tue Jun 25, 2002 at 05:41:02PM +0200, Buchan Milne wrote:

> >Well, this was discussed internally. The reason why we're supporting
> >7.1 is because Corporate Server 1.0.1 must be supported. Since the
> >packages for CS1.0.1 are more often than not simple symlinks to 7.1
> >packages. So it's no more work to support 7.1 than it is to support
> >CS1.0.1. Now, when it's decided that CS1.0.1 will no longer be
> >supported, then 7.1 won't be supported either, but a lot of corporate
> >customers use CS1.0.1.
> >
> >As well, a lot of 7.2 users use 7.2 in corporate or ISP environments.
> >I suspect the support life of 7.2 may be a little longer. And, of
> >course, SNF7.2 (also based on 7.2) will likely be supported for quite
> >a while... which means that it is a little more effort to support 7.2
> >along with SNF since SNF has a fraction of the total 7.2 packages.
>
> Hmmm, but probably most of the ones that need to be updated (apache,
> ssh, bind, dhcp etc).

Exactly. The silly thing about SNF is that some of this stuff
shouldn't have been there to begin with (ie. bind and dhcp; those
don't really belong on a firewall), but because they are, they need
to be supported. But you're right, it's the big "server" type stuff
that is mostly duplicated.

> >In other words, with a 6mos release cycle, one has to expect that the
> >support life of a product will be fairly long, and as more
> >distributions come out, more versions will be supported.
>
> Is this an argument for a Debian-style long release cycle, or for a
> fast, safe, minimal-downtime upgrade capability, or for more security staff?

Neither, just a statement of fact (although more security staff
wouldn't hurt). Smoother upgrade paths would mean the life of a
product would be shorter; as it stands with rpm, this isn't so easy,
so one has to expect the life of a product to be longer because the
upgrade path isn't a "point-n-click" operation. To illustrate my
point, we currently support the following distros:

7.1, CS1.0.1, 7.2, SNF7.2, 8.0, 8.0/ppc, 8.1, 8.1/ia64, 8.2, 8.2/ppc

In one year from now, if 7.1/CS1.0.1 isn't removed, you can (and this
is theoretical as I don't know the status of the non-x86 archs)
probably add 9.0, 9.0/ia64, 9.1, 9.1/ppc.

So in a span of one year, we go from supporting 10 platforms to 14.
If you look at a growth of 4/year, even if after this next year we
dropped support for 7.1/CS1.0.1 (keeping SNF because MNF may seem to
some untried/untested, not worth upgrading, etc.), we go from 14
distributions to 16 (actually 17 if we add MNF8.2).

The year after that? Even if we did drop 7.2/SNF7.2, we're still
growing at a rate of 4/yr (provided we don't start doing IA64 and PPC
releases on each x86 release, but every two "rotations"), and dropping
2/yr. So in 3 years we're supporting 19 distributions. Even if each
year we dropped support for the two oldest, we're still growing at a
rate of 2/yr.

In the end, someone has to say enough is enough... =) It would be
absolutely insane to support 19 products three years from now. Heck,
people argue about how slow updates are now (I'm not one of them, but
I don't think the update speed is unreasonable for 10 distributions).
Imagine adding another 9 to the whole build/QA cycle... yikes.

> >With the release of the rpm-macros package, maintenance on older
> >distribs *should* be a little easier, however the compile time
> >involved is also an issue, which makes things longer.
>
> But, reducing compile time due to having to hack spec files would make a
> substantial difference. I had finished building samba-2.2.5 for cooker,
> 8.2 and 8.0 when I found that rpm on 8.1 didn't like nested
> conditionals, so I rebuilt on all of them.

I agree. This is troublesome at first (which resulted in a few extra
openssh builds for me also). But once you get the spec done, and
working on all platforms, the next time around it's easier. For
instance, when upgrading to the next openssh (probably 3.4 next week),
I only have to update one srpm instead of 3-4 like I used to. This
makes it a lot easier (but the first "transition" is always the
hardest).

> >As it stands, now I am actively attempting to use a single srpm for
> >all platforms using build macros. If you look at the apache updates
> >and openssh updates, you'll see the build_7x or build_7? macros. This
> >should make maintenance on these packages a little easier in the long run.
>
> Can there be some agreement on how to use these macros? I use:
>
> %define build_mdk82 %(if [ `awk '{print $4}' /etc/mandrake-release` =
> 8.2 ];then echo 1; else echo 0; fi)
> %define build_mdk81 %(if [ `awk '{print $4}' /etc/mandrake-release` =
> 8.1 ];then echo 1; else echo 0; fi)
> %define build_mdk80 %(if [ `awk '{print $4}' /etc/mandrake-release` =
> 8.0 ];then echo 1; else echo 0; fi)
> %define build_mdk72 %(if [ `awk '{print $4}' /etc/mandrake-release` =
> 7.2 ];then echo 1; else echo 0; fi)
>
> This allows you to just rebuild the SRPM on any release, since rpm
> figures out which release you're building on. But, should macros like
> this not be made standard? Otherwise, in the end, many packages will
> have similar setups, with different macro names (kde packages use
> buildforX_Y, as opposed to here which is build_mdkXY). I would vote for
> something which could be multi-distro, and maybe include an LSB macro.
> Then, maybe we can build Mandrake updates for RH ;-) (would have helped
> Oden!).

Hmmm... I like that... I, personally, always use %build_[ver]. In
some cases, 7.2 and 7.1 don't differ at all, and in that case I use
%build_7x. I try to make it as sane as possible. But I do like this
idea... I like it a lot.

I've got the new rpm-macros already on the FTP site, to be announced
later today. So this will bring 7.1 up to speed with 8.2 macros.
I'll discuss with the other mdksoft developers about using something
like this. If this is used, it really doesn't matter what the name of
the macro is; it should be transparent to the user.

> Btw, the recent change in the release file in cooker means that cooker
> after 9.0 may be version 9.1, but what will the stable release after 9.0
> be? It probably shouldn't be the same as cooker, so 9.2? Are we going to
> an even-numbered stable release number (or has noone considered the
> consequences of this change)?

I, personally, would like to see every .2 release as a stable and
cooker always have a .1 release. Ie. 9.0 comes out, cooker goes to
9.1 (or maybe 9.0.1 or something). Then 9.2 comes out, cooker goes to
9.3 or 9.2.1. This is more of a cosmetic thing than something that
really matters, I think. Calling cooker 9.1 is no biggie... 9.1 is,
after all, based on cooker when it enters it's freeze. I don't think
there are any consequences to this, except perhaps saving a little
confusion to folks who may not be entirely aware of what cooker is.
 
> >>Right now, old versions are plain "loss" for us, and Vincents work often
> >>look like a charity to me. That's sick, if you ask me.
> >
> >
> >Well, trust me, I would like to stop supporting 7.x entirely... =)
> >But that decision isn't up to me and until MNF has been out for at
> >least a year, SNF will probably continue to be supported, perhaps even
> >longer. I can see dropping 7.1/CS1.0.1 perhaps when the next version
> >comes out because the ProSuite is now the successor to Corporate
> >Server.
>
> IMHO, at a point like this, it should be easy for most users to justify
> upgrading to a new release. But, if the new release guaranteed the
> ability to be hot-upgraded (a'la Debians apt-get dist-upgrade), it
> definitely would be.

I agree. This is definately something I think we are striving towards
by making urpmi more flexible and more comprehensive. I think in 9.0,
we will see this ability for a 9.0->9.1 upgrade (at least I hope so).
That would be ideal. The only thing required is a reboot to boot into
the new kernel... that would be a very good thing to have.

> >On the other hand, if at all possible, I'd suggest people upgrade to
> >at least 8.0 or 7.2 if at all possible. I suspect 7.2's "support
> >life" will probably be at least 6mos, if not a year (or more). But I
> >can't say the same for 7.1.
>
> On more box < 8.1 left, but it's our mail server, and I want to migrate
> away from UW-IMAP, possible to courier, but maildrop seems to have
> disappeared from cooker, which I need to have the same functionality we
> get from procmail (which I don't think does Maildir). OT, does someone
> know an easy way of converting mbox to Maildir. Google and freshmeat
> didn't help. Plus, if I upgrade it, it probably means there aren't going
> to be RPMs of samba for 8.0 ;-) (or they will be later, I still have 8.0
> on a partition at home).

=) Well, I can always build those 8.0 rpms if required. One machine
that I use to build rpmhelp.net packages has 8.0 and 8.1 in chroot for
building, and of course there's the updates machine which still has
7.0 in chroot somewhere, I think.

> >>Realistically seen, nobody really likes building packages for old distros,
> >>and folks who for one reason or another run a 2-years old distro should
> >>IMO be prepared to pay for the privilege of having updates built and
> >>tested for them.
> >
> >
> >No, I sure don't like it, but it's part of the job and has to be
> >done. Unfortunately, a lot of people expect instant updates and don't
> >understand that packages have to be built for 8 different
> >distros/platforms, and tested for 10. That's a lot of packages. Now
> >that I think about it, I'm actually amazed I got the apache updates
> >out as quickly as I did. =)
>
> If the incremental cost (ie with 7.1 and CS1.0.1) is not too high, being
> able to boast a support-life approaching that of some big vendor from
> Redmond is an advantage (remember, Windows98 is still supported,
> although not for much longer).

Yes, but you also need to consider MS's release cycle. They put out a
new version of Windows every 2 years? Roughly? We release a lot more
than that... for every one windows version, there are four x86
Mandrakes, and nevermind the other archs.

Also look at company size and resources... if MandrakeSoft was as big
as Microsoft, we could afford to support 6.0 if we wanted to. =)

-- 
MandrakeSoft Security; http://www.mandrakesecure.net/
"lynx -source http://www.freezer-burn.org/bios/vdanen.gpg | gpg --import"
1024D/FE6F2AFD   88D8 0D23 8D4B 3407 5BD7  66F9 2043 D0E5 FE6F 2AFD
Current Linux kernel 2.4.18-6.10mdk uptime: 17 days 13 hours 5 minutes.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9GKNGIEPQ5f5vKv0RAprJAKCouBWl79GgQxhsJiU/k5OpPkgeGwCfZ6Oc PPDfhY6aKaAOVUp1Ab/8+Sk= =gKX7 -----END PGP SIGNATURE-----

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]