The OpenBSD project introduced bianual releases with great succes. Since Crux is also a very evolutionary project using a binanual release cycle would be pretty easy. And I bet you can all come up with other advantages. The only disadvantage is that we've got to together more often and decide what to for the next cycle apart from updates and then insert a month of freezetime. What do you think? # Han -- http://www.xs4all.nl/~hanb/software/crux/
Han Boetes wrote:
The OpenBSD project introduced bianual releases with great succes. Since Crux is also a very evolutionary project using a binanual release cycle would be pretty easy.
And I bet you can all come up with other advantages. The only disadvantage is that we've got to together more often and decide what to for the next cycle apart from updates and then insert a month of freezetime.
What do you think?
I'm all for a more defined release policy, and I think knowing the approx. date of the next release would help us keeping things more organized. I'm not sure about having 2 releases per year: as you pointed out this could result a complicated task for our small team. In any case, it sound like a good idea; basically I'm in favour of everything that: - facilitates the task of maintaining CRUX - facilitates the task of upgrading to new releases Regards, Simone
On Thu, Jul 20, 2006 at 11:37:59PM +0200, Simone Rota wrote:
Han Boetes wrote:
The OpenBSD project introduced bianual releases with great succes. Since Crux is also a very evolutionary project using a binanual release cycle would be pretty easy.
And I bet you can all come up with other advantages. The only disadvantage is that we've got to together more often and decide what to for the next cycle apart from updates and then insert a month of freezetime.
What do you think?
I'm all for a more defined release policy, and I think knowing the approx. date of the next release would help us keeping things more organized.
I think it would be a good thing to introduce a clearly defined release schedule. Having one would allow prioritizing new features while evaluating how well potential changes would fit in with the KISS philosophy. I realize the time constraint for CRUX because this is not a big project compared to other Linux distributions, however I find it more organized if releases have a schedule. Just a thought on the topic. :) -- "Damnant quod non intellegunt."
Op Thursday 20 July 2006 23:10 schreef Han Boetes:
What do you think?
Me, as an average user, I dread every single release. It involves work because things apparently needed to change. They are effectively an interruption of what is otherwise a very nice system. I would hope that everything that changes is done as much as possible using the normal and elegant Crux mechanisms (prt-get update) and that new releases are only done when absolutely necessary, even though they may look nice on osnews and distrowatch. Diederick
Diederick de Vries napisał(a):
Me, as an average user, I dread every single release. It involves work because things apparently needed to change. They are effectively an interruption of what is otherwise a very nice system.
I would hope that everything that changes is done as much as possible using the normal and elegant Crux mechanisms (prt-get update) and that new releases are only done when absolutely necessary, even though they may look nice on osnews and distrowatch.
As opposed to your post Diederick, I really like the idea to have new releases more often. I would rather like to prt-get update mechanism to be as stable as possible and not change anything important - to give as much stability and security as possible. New features, new major versions of big applications/frameworks/desktop environments should go into new distribution release. Of course some people would like to have security updates for older crux versions to be published longer then for a half of year. But that would require some extra work to do... Anyway I would love to see new crux every winter and summer for example. Greetings, -me. -- --==--==---------------------- Witold Bołt :: ja@houp.info gsm#660316053 :: www.houp.info
Diederick de Vries wrote:
Me, as an average user, I dread every single release. It involves work because things apparently needed to change. They are effectively an interruption of what is otherwise a very nice system.
If you have crux installed and keep tracking the updates regularly it should be a mild transition. And the longer you postpone upgrades the harder it will be to fix changes. So regular upgrades keep the admin task doable. And I dread for the servers which were installed long ago and never updated, with the admin attitude of `don't fix it if it ain't broken,' which is a sure recipe for trouble.
I would hope that everything that changes is done as much as possible using the normal and elegant Crux mechanisms (prt-get update) and that new releases are only done when absolutely necessary, even though they may look nice on osnews and distrowatch.
If install crux and then have to rebuild every package that's installed you'll also not be happy. regular releases are better for installers so they are quite up to date to start with. And for people who keep tracking updates they are not necessary, all they have to do is change the release tag and rebuild some ports and run rejmerge. # Han -- http://www.xs4all.nl/~hanb/software/crux/
Hello, Han. On Fri, 21 Jul 2006 01:10:18 +0200 Han Boetes <han@mijncomputer.nl> wrote:
Diederick de Vries wrote:
Me, as an average user, I dread every single release. It involves work because things apparently needed to change. They are effectively an interruption of what is otherwise a very nice system.
If you have crux installed and keep tracking the updates regularly it should be a mild transition.
And the longer you postpone upgrades the harder it will be to fix changes. So regular upgrades keep the admin task doable. Sure.
regular releases are better for installers so they are quite up to date to start with. And for people who keep tracking updates they are not necessary, all they have to do is change the release tag and rebuild some ports and run rejmerge. Once again something inside tells me it's a way towards some troubles after 2-3 such updates. Double rebuild of the whole system in chrooted environment sounds like an overkill, but what is the safe and sane way?
Such way a crux-current would be even nicer and simpler to follow, but not shure how toolchain changes are implemented, for example, in OpenBSD-current. Also, they are kernel developers too, while crux only implements userspace. There are ~80 active developers working on OpenBSD and very few here. So the cycle period is not a trivial thing to choose. -- Mikhail Kolesnik ICQ: 260259143 IRC: mike_k at freenode/#crux, rusnet/#yalta Jabber: mike_k@jabber.lafox.net NIC handle: MKK83-UANIC
Mikhail Kolesnik wrote:
Han Boetes <han@mijncomputer.nl> wrote:
regular releases are better for installers so they are quite up to date to start with. And for people who keep tracking updates they are not necessary, all they have to do is change the release tag and rebuild some ports and run rejmerge.
Once again something inside tells me it's a way towards some troubles after 2-3 such updates. Double rebuild of the whole system in chrooted environment sounds like an overkill, but what is the safe and sane way?
Download the iso and update all the packages the binary way. They're already build for you.
Such way a crux-current would be even nicer and simpler to follow, but not shure how toolchain changes are implemented, for example, in OpenBSD-current.
Also, they are kernel developers too, while crux only implements userspace. There are ~80 active developers working on OpenBSD and very few here. So the cycle period is not a trivial thing to choose.
You can think up a lot of nonexisting problems. :-) CRUX is much simpler than OpenBSD, keeping it up to date and working while testing new stuff is just a hobby of mine, and I bet it's the same for the other maintainers. What you get in the meanwhile as an enduser is a linux distro that's easy to build and maintain. # Han -- http://www.xs4all.nl/~hanb/software/crux/
Hello, Han. On Fri, 21 Jul 2006 10:00:40 +0159 Han Boetes <han@mijncomputer.nl> wrote:
Mikhail Kolesnik wrote:
Han Boetes <han@mijncomputer.nl> wrote:
regular releases are better for installers so they are quite up to date to start with. And for people who keep tracking updates they are not necessary, all they have to do is change the release tag and rebuild some ports and run rejmerge.
Once again something inside tells me it's a way towards some troubles after 2-3 such updates. Double rebuild of the whole system in chrooted environment sounds like an overkill, but what is the safe and sane way?
Download the iso and update all the packages the binary way. They're already build for you. An obvious solution is not my first choice, sadly... After all, I am not so crazy on rebuilding/optimizing personal workstation. Just want to be sure this wont brake some server system =(
Such way a crux-current would be even nicer and simpler to follow, but not shure how toolchain changes are implemented, for example, in OpenBSD-current.
Also, they are kernel developers too, while crux only implements userspace. There are ~80 active developers working on OpenBSD and very few here. So the cycle period is not a trivial thing to choose.
You can think up a lot of nonexisting problems. :-) Yes, that is my well-known vulnerability.
CRUX is much simpler than OpenBSD, keeping it up to date and working while testing new stuff is just a hobby of mine, and I bet it's the same for the other maintainers.
What you get in the meanwhile as an enduser is a linux distro that's easy to build and maintain. Have to agree here.
-- Mikhail Kolesnik ICQ: 260259143у IRC: mike_k at freenode/#crux, rusnet/#yalta Jabber: mike_k@jabber.lafox.net NIC handle: MKK83-UANIC
participants (6)
-
Diederick de Vries -
Han Boetes -
Jesse Kokkarinen -
Mikhail Kolesnik -
Simone Rota -
Witold Bołt