[OpenIndiana-discuss] New OI /dev release, release structure
On 09/28/14 04:40 PM, Bob Friesenhahn wrote: Hopefully some kind person with necessary knowlege and access will push an updated bash package which works on 151a8/9 so that servers based on OpenIndiana are no longer a disaster situation. It would imply that OI servers have automatic updates turned on and that is not exactly the case I think. It would imply that we need reviving producing /dev releases, because updating to Hipster and rolling-release model is not for production ready quality, and/or not working/not caring about updating from /dev. (Manpower, manpower manpower) Maybe on one hand OI need a funding place where anyone wanting something could chop in some cash so it could be spent on something important, infrastructure, etc. And we need SOME release structure for /dev , made of people willing to do that, *starting with people who last time produced /dev and under their guidance* (and using latest updates in Hipster, that could be used, without breaking dependencies and production process and intoducing new bugs). ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] New OI /dev release, release structure
And we need SOME release structure for /dev , made of people willing to do that, *starting with people who last time produced /dev and under their guidance* (and using latest updates in Hipster, that could be used, without breaking dependencies and production process and intoducing new bugs) For /dev, that was JT-EC and the many contributers to OI_151a that either built consolidations or tested the distro. If new /dev (hipster), the hopefully it gets tested as 'good enough' to replace /dev. Really, there is mainly the testing of userland. SFE is based on backward compatibility so is tested and updates are done on things that may not work. Are major upstream core consolidations are compiled on hipster as the base distro. So, hipster is about as 'production-ready' as oi_151a9. If not, time to focus on providing feedback. On Thursday, October 2, 2014 12:39 AM, Nikola M. wrote: On 09/28/14 04:40 PM, Bob Friesenhahn wrote: > Hopefully some kind person with necessary knowlege and access will > push an updated bash package which works on 151a8/9 so that servers > based on OpenIndiana are no longer a disaster situation. It would imply that OI servers have automatic updates turned on and that is not exactly the case I think. It would imply that we need reviving producing /dev releases, because updating to Hipster and rolling-release model is not for production ready quality, and/or not working/not caring about updating from /dev. (Manpower, manpower manpower) Maybe on one hand OI need a funding place where anyone wanting something could chop in some cash so it could be spent on something important, infrastructure, etc. And we need SOME release structure for /dev , made of people willing to do that, *starting with people who last time produced /dev and under their guidance* (and using latest updates in Hipster, that could be used, without breaking dependencies and production process and intoducing new bugs). ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] New OI /dev release, release structure
On Thu, 2 Oct 2014, Nikola M. wrote: On 09/28/14 04:40 PM, Bob Friesenhahn wrote: Hopefully some kind person with necessary knowlege and access will push an updated bash package which works on 151a8/9 so that servers based on OpenIndiana are no longer a disaster situation. It would imply that OI servers have automatic updates turned on and that is not exactly the case I think. The system administrator would have to request the package update. First, the package update needs to be available. As an OI user, I am unable to tell who is/has produced OI and who is still able to produce new packages and prepare releases. I continue to hear about hipster but then I also hear that there is no longer a useful path from 'dev' to 'hipster' and that 'hipster' is more unstable. I get the impression that 'hipster' mostly focuses on X11 desktop and multimedia software. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] New OI /dev release, release structure
Hipster provided the recent kernel builds and updates from the upstream consolidations. We had discussed hipster as being oi-151a10. /dev is just a timestamp on a snapshot. A Hipster snapshot can replace /dev once the major consolidations are successfully built and tested. Hipster is like upgrading from Win98 to Win7. You'd want a clean install to test and use. Migrate your apps over to the new install. Usually takes about 1-2 hours rather than fighting over upgrade issues. Sent from Yahoo Mail on Android ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] New OI /dev release, release structure
Hello. Bob Friesenhahn писал 02.10.2014 23:43: On Thu, 2 Oct 2014, Nikola M. wrote: On 09/28/14 04:40 PM, Bob Friesenhahn wrote: Hopefully some kind person with necessary knowlege and access will push an updated bash package which works on 151a8/9 so that servers based on OpenIndiana are no longer a disaster situation. It would imply that OI servers have automatic updates turned on and that is not exactly the case I think. The system administrator would have to request the package update. First, the package update needs to be available. As an OI user, I am unable to tell who is/has produced OI and who is still able to produce new packages and prepare releases. I continue to hear about hipster but then I also hear that there is no longer a useful path from 'dev' to 'hipster' and that 'hipster' is more unstable. I get the impression that 'hipster' mostly focuses on X11 desktop and multimedia software. First statement is unfortunately true. To make /dev => /hipster update possible we need 1) to republish packages which were not rebuilt since /dev a8 with higher numbers (2014.x) 2) republish incorporations so that they either are empty or depend on actual packages 3) publish neccessary obsoletion / renaming packages 4) test that at least typical text / GUI install can be updated from latest /dev to /hipster. Noone volunteered to do it yet. Second statement is not accurate enough. There is a lot of activity on desktop software, because it should be adapted to new build system. Also, desktop support is one of OI differentiating features among illumos distributions. So we (at least I) care about both server and desktop software. However, I understand that with current development model installing Hipster on production server is some kind of insanity, as we sometimes update software in incompatible ways (major versions update) and sometimes testing is insufficient. It doesn't mean that I forget or don't think about testing, it means that there are no enough users to thoroughly test system (for example today I had to fix python because after last update recompilation with gcc4.8 triggerred specific bug which was found out only when I tried to build python-dependent software in illumos-gate, however, tests, shipped with python were successfully passed (at least, no difference with previous python version)). As for multimedia software, I think SFE deals with this much better now. At least they shouldn't avoid shipping programs which are illegal in US (different codecs, video/audio players, even wine). --- System Administrator of Southern Federal University Computer Center ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] New OI /dev release, release structure
It would also be nice to see a split between home-usage and (partial) professional usage. For the way I use OpenIndiana I don't need a GUI, nor firefox nor codecs or movie players. I just need a good, stable and secure platform with zones and ZFS. And capable of being patchable to the latest available secure versions of BASH, SSH, SSL, JAVA and other common Unix OS belongings. Who is now managing the code? Is there a way to organise a roadmap? What if some students are put on the project? -Oorspronkelijk bericht- Van: Alexander Pyhalov [mailto:a...@rsu.ru] Verzonden: donderdag 2 oktober 2014 22:41 Aan: Discussion list for OpenIndiana Onderwerp: Re: [OpenIndiana-discuss] New OI /dev release, release structure Hello. Bob Friesenhahn писал 02.10.2014 23:43: > On Thu, 2 Oct 2014, Nikola M. wrote: > >> On 09/28/14 04:40 PM, Bob Friesenhahn wrote: >>> Hopefully some kind person with necessary knowlege and access will >>> push an updated bash package which works on 151a8/9 so that servers >>> based on OpenIndiana are no longer a disaster situation. >> It would imply that OI servers have automatic updates turned on and >> that is not exactly the case I think. > > The system administrator would have to request the package update. > First, the package update needs to be available. > > As an OI user, I am unable to tell who is/has produced OI and who is > still able to produce new packages and prepare releases. > > I continue to hear about hipster but then I also hear that there is no > longer a useful path from 'dev' to 'hipster' and that 'hipster' is > more unstable. I get the impression that 'hipster' mostly focuses on > X11 desktop and multimedia software. First statement is unfortunately true. To make /dev => /hipster update possible we need 1) to republish packages which were not rebuilt since /dev a8 with higher numbers (2014.x) 2) republish incorporations so that they either are empty or depend on actual packages 3) publish neccessary obsoletion / renaming packages 4) test that at least typical text / GUI install can be updated from latest /dev to /hipster. Noone volunteered to do it yet. Second statement is not accurate enough. There is a lot of activity on desktop software, because it should be adapted to new build system. Also, desktop support is one of OI differentiating features among illumos distributions. So we (at least I) care about both server and desktop software. However, I understand that with current development model installing Hipster on production server is some kind of insanity, as we sometimes update software in incompatible ways (major versions update) and sometimes testing is insufficient. It doesn't mean that I forget or don't think about testing, it means that there are no enough users to thoroughly test system (for example today I had to fix python because after last update recompilation with gcc4.8 triggerred specific bug which was found out only when I tried to build python-dependent software in illumos-gate, however, tests, shipped with python were successfully passed (at least, no difference with previous python version)). As for multimedia software, I think SFE deals with this much better now. At least they shouldn't avoid shipping programs which are illegal in US (different codecs, video/audio players, even wine). --- System Administrator of Southern Federal University Computer Center ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] New OI /dev release, release structure
Hello. outsider писал 03.10.2014 01:26: It would also be nice to see a split between home-usage and (partial) professional usage. What do you mean by "split"? We are aimed to support both server and desktop installations. If you want server-focused distribution, you can look at DilOS (uses apt-get/dpkg) or OmniOS (uses IPS). For the way I use OpenIndiana I don't need a GUI, nor firefox nor codecs or movie players. I just need a good, stable and secure platform with zones and ZFS. And capable of being patchable to the latest available secure versions of BASH, SSH, SSL, JAVA and other common Unix OS belongings. If you need just zones/ssh/bash/ssl/zfs, Hipster can suite you. At least we rarely break these components :) However, we are more sensitive to illumos-gate changes. Hipster uses upstream illumos-gate. It has its own benefits (new fixes are almost immediately available here) and drawbacks (for example, we expect removing of Sun DHCP server from illumos-gate soon, and our users will suffer from it when it happens). As for Java - we can't redistribute latest Oracle Java versions. However, older one is available. Also Hipster ships OpenJDK 1.7. Who is now managing the code? Is there a way to organise a roadmap? What if some students are put on the project? If we speak about /dev, it is supported by Jon Tibble. As for /hipster, it is currently supported by Adam Stevko, Andrzjei Szeszo, Ken Mays and me. You can find TODO list for OI /hipster here: http://wiki.openindiana.org/oi/TODO+list As for students - we always welcome new developers. If they need some advice, they can ask their questions at oi-dev ML or in #oi-dev freenode.net IRC channel. --- System Administrator of Southern Federal University Computer Center ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] New OI /dev release, release structure
It would also be nice to see a split between home-usage and (partial) professional usage. For the way I use OpenIndiana I don't need a GUI, nor firefox nor codecs or movie players. I just need a good, stable and secure platform with zones and ZFS. You just use text install or you disable gdm service from starting, after regular install and that's it. You benefit with OI with better compatibility with Solaris applications and you can also use S10 branded zones I think. And capable of being patchable to the latest available secure versions of BASH, SSH, SSL, JAVA and other common Unix OS belongings. Who is now managing the code? Is there a way to organise a roadmap? What if some students are put on the project? -Oorspronkelijk bericht- Van: Alexander Pyhalov [mailto:a...@rsu.ru] Verzonden: donderdag 2 oktober 2014 22:41 Aan: Discussion list for OpenIndiana Onderwerp: Re: [OpenIndiana-discuss] New OI /dev release, release structure First statement is unfortunately true. To make /dev => /hipster update possible we need 1) to republish packages which were not rebuilt since /dev a8 with higher numbers (2014.x) 2) republish incorporations so that they either are empty or depend on actual packages I still do not understand this one. Why killing incorporations is so important, it seems that incorporations definitions could be updated to reflect version changes and then go through the testing to make sure everything under updated incorporation works together. That is what incorporations are for, to make sure things work together and they are tested before updating it as a whole. Why there would be any benefit of removing incorporations, but almost certain that it would not benefit testing. I am all for doing testing and keeping incorporations where they are, to make system consistent. Is it truly hard to update a package and update incorporation at the same time, while building testing releases, like Hipster's? 3) publish neccessary obsoletion / renaming packages This also needs to be checked and documented, both for recommendations what to use instead if some package is removed, how to move current configuration to a new one etc. Packages can not just be removed with no documentation about what to use instead in next release. (And there should be releases and not only package updates) From that basic documentation, later before publishing new /dev release, documentation for change could be made wider before release, telling people what to do administering it. 4) test that at least typical text / GUI install can be updated from latest /dev to /hipster. Noone volunteered to do it yet. It was possible before and updating from a8 was almost smooth. And I think I reported the moment I figured it is not possible. Response was not to fix it but to ignore it. Problem with updating from /dev to Hipster started somewhere before releasing Hipster's ISO and 2014.1 That was the best moment to work things out and to make sure that is the moment when everyone can update to /hipster. But that moment was not used to work things out with smooth update, and instead we got recommendations to reinstall to Hipster from ISO (?) when we all know that Hipster development model is unstable to be considered something worth for clean install. I had system that was updating all from Opensolaris 2009.06 with all /dev versions, up to Openindiana 151a8 and a9 and now someone will say to me update is not possible? Hipster with it's always changing contents of packages and no revisions to jump between different states (versions, like entire etc) makes quality control and testing almost impossible (figuring out WHEN and after what change what problem arise) I would like to do something with that but there are also just too many problems with how Hipster now functions in every way. It would need to have numbered revisions between updates, so tester can jump to specific state of packages to recreate testing environment before and after packages are changed. (entire) Hipster proved as not suitable for any use but testing and using on one's laptop or separate test server. Problem with Hipster is that it is not meant to be productiion quality from the ground up and all philosophy of "let's update a package and see will someone compain and report a bug" works quite well for internal releases/strictly "in between" working updates before next /dev release. Hipster spent too much time going away from Openindiana /dev and it has to stop doing so. However, I understand that with current development model installing Hipster on production server is some kind of insanity, as we sometimes update software in incompatible ways (major versions update) and sometimes testing is insufficient. It doesn't mean that I forget or don't think about testing, it means that there are no enough users to thoroughly test system (for exampl
Re: [OpenIndiana-discuss] New OI /dev release, release structure
Hello. On 10/03/2014 16:26, Nikola M. wrote: First statement is unfortunately true. To make /dev => /hipster update possible we need 1) to republish packages which were not rebuilt since /dev a8 with higher numbers (2014.x) 2) republish incorporations so that they either are empty or depend on actual packages I still do not understand this one. Why killing incorporations is so important, it seems that incorporations definitions could be updated to reflect version changes and then go through the testing to make sure everything under updated incorporation works together. 1) I haven't said about killing incorporations here. I said making them empty OR dependent on actual packages. 2) But I honestly don't think that incorporations are necessary in Hipster, perhaps, except entire. They were aimed to control version numbers of software from different consolidations. But we want to have only one consolidation . If you want to stick to one package version just do pkg fix entire after Hipster install. We could avoid publishing empty entire after ISO release and so make Hipster behave more like /dev. But I'm inclined to publish empty entire to encourage wider testing. 3) publish neccessary obsoletion / renaming packages This also needs to be checked and documented, both for recommendations what to use instead if some package is removed, how to move current configuration to a new one etc. Packages can not just be removed with no documentation about what to use instead in next release. I don't think so. We have a lot of outdated desktop-related software. It has sometimes strange dependencies, brings in more outdated software and so on. I think that it's good trend to remove something old, unused and unmaintained. If someone wants it back, just fix the package to build in oi-userland and work on Hipster. (And there should be releases and not only package updates) We are publishing snapshots once per several months. From that basic documentation, later before publishing new /dev release, documentation for change could be made wider before release, telling people what to do administering it. Agree, documentation can be enhanced. 4) test that at least typical text / GUI install can be updated from latest /dev to /hipster. Noone volunteered to do it yet. It was possible before and updating from a8 was almost smooth. And I think I reported the moment I figured it is not possible. Response was not to fix it but to ignore it. It is not possible now. At least until all our packages has greater versions then /dev. /dev now uses X-0.151.1.9 versions. We have a lot of X-0.151.1.8 versions. IPS can't handle this. Also, a lot of obsoletion packages were removed during migration from /hipster to /hipster-2014.1 repository. Part of them should be republished to allow /dev => /hipster update. Hipster with it's always changing contents of packages and no revisions to jump between different states (versions, like entire etc) makes quality control and testing almost impossible (figuring out WHEN and after what change what problem arise) We have shipped entire with last ISO snapshot. We are going to ship one more with new ISO snapshot. However, I agree, there's issue with testing - you can't update/downgrade to the state of some particular date. But it's true also for other OSes and distributions. Do you propose to update entire on each package update? Hipster proved as not suitable for any use but testing and using on one's laptop or separate test server. I successfully use it for my labs. Using something illumos-based on our servers is impossible due to hardware issues. But I don't think I would persuade my collegues to migrate from Debian to something else even if illumos supported our hardware :) Problem with Hipster is that it is not meant to be productiion quality from the ground up and all philosophy of "let's update a package and see will someone compain and report a bug" works quite well for internal releases/strictly "in between" working updates before next /dev release. Yes, it was created to speed up OI development. I think it partly achieved this goal. Hipster spent too much time going away from Openindiana /dev and it has to stop doing so. It's easy to go away from someone standing ;) Seriously, I think that moving away from legacy consolidations and build systems is a necessary task to ease OI development and to lower barrier for new devs. -- Best regards, Alexander Pyhalov, system administrator of Southern Federal University IT department ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] New OI /dev release, release structure
On 10/ 3/14 03:23 PM, Alexander Pyhalov wrote: Hello. On 10/03/2014 16:26, Nikola M. wrote: First statement is unfortunately true. To make /dev => /hipster update possible we need 1) to republish packages which were not rebuilt since /dev a8 with higher numbers (2014.x) 2) republish incorporations so that they either are empty or depend on actual packages I still do not understand this one. Why killing incorporations is so important, it seems that incorporations definitions could be updated to reflect version changes and then go through the testing to make sure everything under updated incorporation works together. 1) I haven't said about killing incorporations here. I said making them empty OR dependent on actual packages. OK, That's non issue then. I think they should depend on current versions of actual packages in Hipster, providing one that update a package that is part of incorporation says that updated package actually works with other packages inside incorporation. That way incorporation serves its purpose even during Hipster lifetime, before next /dev, when incorporations could be fully and thoughtfully tested. Updating package have sense only when it does not break incorporation as a whole and that HAVE sense. I don't know what would be use case of empty incorporations... 2) But I honestly don't think that incorporations are necessary in Hipster, perhaps, except entire. I just provided answer for this. No updated package server it's purpose if it breaks other packages in incorporation. Can't update package X because of other dependencies locked by incorporation that needs other parts to make them work. They were aimed to control version numbers of software from different consolidations. But we want to have only one consolidation . And why is that? Why would we want to have just one consolidation? That makes separate testing and working on parts of the system hard and not possible to enforce teams work for parts of the distribution. When I focus on testing and building only one consolidation of packages, I can focus on it, instead of building _everything_ every time. Building everything is terrible waste of time, too. If you want to stick to one package version just do pkg fix entire after Hipster install. We could avoid publishing empty entire after ISO release and so make Hipster behave more like /dev. But I'm inclined to publish empty entire to encourage wider testing. 3) publish neccessary obsoletion / renaming packages This also needs to be checked and documented, both for recommendations what to use instead if some package is removed, how to move current configuration to a new one etc. Packages can not just be removed with no documentation about what to use instead in next release. I don't think so. We have a lot of outdated desktop-related software. It has sometimes strange dependencies, brings in more outdated software and so on. I think that it's good trend to remove something old, unused and unmaintained. You generally remove something when you consider other people thoughts on it and how that affects them and distribution usability. (That is what choosing what is inside incorporation is also about) You can't just destroy packages without having a RELEASE that people could go to check them when packages were last time available (or inside branded zone for previous release. It might look like from Hipster's perspective (in between /dev's) that it is OK, But some DOCUMENTATION must be written describing what and why and how is removed in Hipster and what people using or depending on those packages till now should do to compatible things. That is what is called distribution mantaining, as I see it. You also need to have documentation of what you do, (So that also WIKIs and MANUALS and DOCUMENTATION should be updated accordingly). If one person just go around deleting packages, without trace and explanation and consulting it leads to unmaintainable, undocumented, unstable, unusable (no docs) MESS. So maintaining LOG with explanations of the actions, especially in Hipster is a MUST to have other in-distribution people specializations possible to get their job done. From hat LOG, someone doing TESTING before releasing next /dev out of it, could make checking list testing plans according to freeze dates and together with Hipster's entire and incorporation version changes, makes good environment for effective testing that produce high quality bug reports (and fixes). If someone wants it back, just fix the package to build in oi-userland and work on Hipster. Firstly removing something randomly and then requiring extra effort to get it back sounds like very bad practice to me. Things don't get removed "just because" without explanation , that is how I see it. Such practice could lead to tons of bug reports before releasing /dev. (And there should be releases and not only package updates) We are publishing snapshots once per
