Re: [oi-dev] Release engineering // planing
/hipster should be the -current like FreeBSD /dev should be -stable like FreeBSD /release or /stable should be -RELEASE like FreeBSD /hipster can keep having its breakage, that is fine. But what I'd see is /dev get illumos-gate updates and tested and when no problems are found and it is stable, then get promoted to /release, and keep this cycle. Thus, /dev and /release will be sunstudio, but I don't know how one can get /hipster promoted to /dev because of gcc. I guess it could be that /hipster always stays out there as a -current while /dev and /release stay with sunstudio because right now /dev is most rock-solid and that should not be taken away. While /hipster has newer packages available, if someone is on /dev or /release there are other options rather than trying to get what is in /hipster. opencsw.org has many current packages available, so anyone using /dev and /release can get them from opencsw.org. From: ken mays To: OpenIndiana Developer mailing list Sent: Thursday, July 11, 2013 4:30 PM Subject: Re: [oi-dev] Release engineering // planing Agreed. I'd suggest the same for the '07/2013 RELEASE' to at least update /dev repo to the current "approved" /hipster Illumos-gate snapshot before pushing to /release. You could respin the oi_151a7 ISO with that recent Illumos_gate snapshot so people can still test the Illumos_gate snapshot for current issues. (oi_151a7.1) The /hipster oi-userland changes should get pushed to /dev from that point with the same snapshot of Illumos_gate from /release. You then update the Illumos builds from that point of reference. Example: /release= /dev Illumos_gate_47f42be153c1 + oi_151a7 (old /dev repo) new /dev = /hipster Illumos_gate_47f42be153c1 + OI-JDS_2b18d0590968 + oi-userland (s12_26) (whatever else) ~ Ken Mays From: Piotr Jasiukajtis To: OpenIndiana Developer mailing list Sent: Thursday, July 11, 2013 2:33 PM Subject: Re: [oi-dev] Release engineering // planing I think an updated illumos-gate packages should go into oi_151a7 first, because of NFS related BUG fix #2986. On Jul 11, 2013, at 8:08 PM, Udo Grabowski (IMK) wrote: > On 11/07/2013 18:53, Alasdair Lumsden wrote: >> >> I do think that /dev should get moved to /release, and /hipster should go to >> /dev. Not many know about hipster beyond the oi-dev list. It would show >> people >> in the outside world that progress is being made on OI.A > > ... > > But at that point, there should be provided a way to switch > current people on /dev to /release, surely most do not want > to be exposed to hipster... > And that seems not to be trivial, probably it needs a bump > to a new release number. > Personally I think this switch should be done now on the > base of a7 (sunstudio compiled, with maybe a few couple of > known stable fixes), as hipster is currently going sidewards > with all the changes to gcc, it will probably not stabilize > within the next two months, and a7 is mostly rock stable > (with a few user visible problems due to the png12 <--> png14 > hassles). > > > > ___ > oi-dev mailing list > oi-dev@openindiana.org > http://openindiana.org/mailman/listinfo/oi-dev -- Piotr Jasiukajtis ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Release engineering // planing
Good points. So, a major question: Is /dev good enough for /release promotion? Any known or reported issues to resolve beforehand? ~ Ken Mays ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Release engineering // planing
On 2013-07-12 15:47, ken mays wrote: Good points. So, a major question: Is /dev good enough for /release promotion? Any known or reported issues to resolve beforehand? I'd say - the kernel should be updated to have the most current features regarding ZFS/NFS and other goodies recently integrated. Also, for desktop-usage people to be content, a working (thus not necessarily most recent and bleedy-flashy) combo of the browser, multimedia plugins and standalone players to be available. I'd also remind about expanding the set of drivers available in the live media and distro, such as my earlier suggestion to try integrating the Free NIC Drivers project so that the system can work out of the box on a wider range of hardware. But maybe this, until integrated and tested, is a goal for /dev and only a future /release, realistically. The ones I tried are good and stable, but those were only a handful of NICs - wider testing of the particular integrated binaries is reasonable to request before promoting into stable release. //Jim ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Release engineering // planing
On Jul 12, 2013, at 3:47 PM, ken mays wrote: > Good points. So, a major question: Is /dev good enough for /release promotion? > > Any known or reported issues to resolve beforehand? #2986, but I think all current illumos-gate changes are safe. -- Piotr Jasiukajtis ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Release engineering // planing
On 12/07/2013 15:47, ken mays wrote: Good points. So, a major question: Is /dev good enough for /release promotion? Any known or reported issues to resolve beforehand? All illumos NFS fixes, at least, probably the last stable can be put in safely (have a short /dev/a8 prelease if in doubt). The cleanup of the png12-png14 hassles would be nice, but I don't know if this can be done, the current workarounds with LD_PRELOAD_32 are working, but problematic for the casual user. /hipster hasn't this clean either, maybe that breaks libflash there. The recent gnome-terminal break (minimize from upper border to generate a crash) shouldn't happen, that would have a major impact on users. And #3275, #3318, #3305, #2805 and relatives , all mostly solved. -- Dr.Udo GrabowskiInst.f.Meteorology a.Climate Research IMK-ASF-SAT www.imk-asf.kit.edu/english/sat.php KIT - Karlsruhe Institute of Technologyhttp://www.kit.edu Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026 smime.p7s Description: S/MIME Cryptographic Signature ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Release engineering // planing
On 11 July 2013 01:12, Adam Števko wrote: > 1.1- should not be bureaucratic, i.e. rather an internal agreement > (Alex) > > I support this type for now. > I believe this is commonly agreed now - we go on without complicated process, hack-on-go basis, sending reviews into the list and merging into repository. Unless there is greater number of contributors, I don't see point in using > branches. I like Andrzej's idea of forking a oi-userland repository and > posting link to a changeset for a review. Do you think that using branches > will help us at the moment somehow? I think that it will complicate some > things at this stage. However, I am open to any ideas, which will bring > simple, non-bureacratic reviews. > Branches could help us later on in the future for staging the code from "I'm hacking at it now" to "It's publishing fine and installs well without breaking anything" to "It's running fine for a while now and it might be a candidate for migration to /dev". This is just a suggestion. > ad 1.3: clever release engineering is definitely required. It requires > integration testing. Do we have resources and/or testing environments for > this? > > hipster jenkins and repository, nothing else I am aware of. I checked OI > boxes and there are old development zones after people, who left. i can > create zones if needed, but keep in mind that dev01 is running 161a7 and > dev02 151a8 from /dev-test (this was needed in order to support MIlan's > work on JDS) and running /hipster zone on older version is not possible due > to libc changes afaik (I had to fully upgrade my 151a7 build server to > /hipster if I wanted to run /hipster build zones). > I'll look at my hosting provider if I can get a box to run OI on it - but initial setup will be problematic with bootp and stuff. Almost every dynamic language, we have in the repository. If we could get > to the point, that the users could install some common tools for every > language (pip, gem, pecl, cpan, npm..) and up-to-date language version > (python 2.7.3, ruby 1.9.x or 2.x for DTrace goodness, perl 5.14 or 5.16, > lua etc), this would simplify porting other stuff. Next thing, I find > important is absorbing as much as possible from ec-userland, because common > server (and even desktop software) is there. ec-userland contains updated > nginx, php, mysql, postgresql, apache and multimedia things like ffmpeg, > vlc and their dependencies (which I am grateful for because I will have to > deal with this in a week or so for my job. Thanks EC guys!). > Alright, let's focus on scripting languages including tools for now. Do we have permission from EC guys doing this? If yes, where can I find their repositoriy? > > I wouldn't complicate things with JIRA and just use Github. It is simple > and we have it already. We have to just start creating issues and somebody > should keep an overview. However, this can be very time consuming and the > best thing we can do at the moment is to try coordination, so we don't > duplicate our efforts and possibly concentrate our work on packages I > mentioned above. For example, if few of us start to deal with one language, > this should be done pretty quickly. > Who has the rights on OI Github repository? Can I be added as a contributor there? I would enable Issues in Repo and start filling in first tasks. Easy coordination and task assignment + reduction of duplicate work. In the second half of 2012, I was working on making oi-build compilable by > gcc. I started by updating the build infrastructure. Those pieces can be > reused. I am aware of autoconf (updated in my WIP repo), binutils, libtool > (update is already in userland-gate, but it is delivering older libltdl) and > automake (updated in my WIP repo). At the moment, I am working on > build-essential meta package, which will be based on ec-userland and > openindiana wiki page. Having this single package will simplify our life. > My old WIP repository can be found at > https://hg.openindiana.org/users/xenol/oi-build/ > I like your build-essential meta package, I'll use it to verify latest versions available and create issues in github for everyone to see. Devs are welcome then to take over the piece and put their name behind the issue. Cheers, Erol ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Release engineering // planing
On 12 July 2013 13:49, G B wrote: > /hipster should be the -current like FreeBSD > /dev should be -stable like FreeBSD > /release or /stable should be -RELEASE like FreeBSD > > /hipster can keep having its breakage, that is fine. But what I'd see is > /dev get illumos-gate updates and tested and when no problems are found and > it is stable, then get promoted to /release, and keep this cycle. > > Thus, /dev and /release will be sunstudio, but I don't know how one can > get /hipster promoted to /dev because of gcc. > > I guess it could be that /hipster always stays out there as a -current > while /dev and /release stay with sunstudio because right now /dev is most > rock-solid and that should not be taken away. While /hipster has newer > packages available, if someone is on /dev or /release there are other > options rather than trying to get what is in /hipster. opencsw.org has > many current packages available, so anyone using /dev and /release can get > them from opencsw.org. > > Important question over here: Are we ever going to promote hipster to /dev or /release then? This is question in particular due to gcc/sunstudio differences. Cheers, Erol ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Release engineering // planing
On 2013-07-12 17:37, Erol Zavidic wrote: contributor there?I would enable Issues in Repo and start filling in first tasks. Easy coordination and task assignment + reduction of duplicate work. Just before you all dive into this, I just wanted a short "sanity check": what are the particular benefits of having a separate issues database (we have OI issues together with issues.illumos.org)? I can believe that GitHub issues are tighter integrated with code commits (maybe, didn't use yet), is this enough of a benefit to either have duplicate issue tracking systems or abandoning an existing one altogether? Maybe "yes", just wanted it to be a conscious decision ;) And on a similar note, why not JIRA for example? It can also hook into code-management systems :) //Jim ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Release engineering // planing
On 2013-07-12 17:42, Erol Zavidic wrote: Important question over here: Are we ever going to promote hipster to /dev or /release then? This is question in particular due to gcc/sunstudio differences. Why not? Code is code. /hipster can be compiled with GCC, which is an easier entry point for assorted contributors who did not get their hands on the one needed proprietary SunStudio version back in the day, and can't legally get it now, at least not for installation onto their PCs (may be it is legal to let them access a compile-farm with SS). Then when code is promoted to /dev and ultimately /release it can be recompiled with SS. On one hand it would give another tool's verification opinion about the code quality, and on another (if SS-built code so far is assumed more stable) - the less adventurous users would have more peace of mind with their non-experimental machines running /dev or /release. Ultimately, when /hipster code experiences no hickups with GCC-built code, maybe the higher-level repos might also switch to GCC-built releases. This might break upgrades of older SS-built systems though, especially if for some reason these are done partially, from what I gather about current hipster (mis-)adventures?.. My 2c, //Jim ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Release engineering // planing
On 07/12/2013 19:52, Jim Klimov wrote: On 2013-07-12 17:42, Erol Zavidic wrote: Important question over here: Are we ever going to promote hipster to /dev or /release then? This is question in particular due to gcc/sunstudio differences. Why not? Code is code. /hipster can be compiled with GCC, which is an easier entry point for assorted contributors who did not get their hands on the one needed proprietary SunStudio version back in the day, and can't legally get it now, at least not for installation onto their PCs (may be it is legal to let them access a compile-farm with SS). Then when code is promoted to /dev and ultimately /release it can be recompiled with SS. On one hand it would give another tool's verification opinion about the code quality, and on another (if SS-built code so far is assumed more stable) - the less adventurous users would have more peace of mind with their non-experimental machines running /dev or /release. Hello. It's almost unreal. We now struggle with two different compilers in base, and the only logic way in my opinion is to just go on with GCC. Code can't be "just recompiled", every Makefile needs its tweaks to support one or another compiler. If it is not tested with Sun Studio in /hipster, it will not work with Sun Studio in /dev and so it will require inadequate amount of energy to be ported. Why do you need Sun Studio? -- Best regards, Alexander Pyhalov, system administrator of Computer Center of Southern Federal University ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] conflicting files, dependencies and moving spec files to oi-userland
Hello. I'm trying to import SUNWxscreensaver.spec to oi-userland. The issue is that it is actually three different packages. I've almost finished with xscreensaver itself, but there are also xscreensaver/hacks, xscreensaver/hacks/hacks-gl and xscreensaver/hacks/rss-glx. The process of determining package boundaries is rather boring and error-prone :) So, I came to the following: now we ship xscreensaver.mo files in gnome/locale/XX packages, which (at least gnome/locale/ru) by the way conflict with gnome/accessibility/gnome-a11y-libs (on usr/share/locale/ru/LC_MESSAGES/at-spi.mo), desktop/gtk2 (on usr/share/locale/ru/LC_MESSAGES/gtk20.mo) and so on The question is following: if we build application on by-component basis, how can we create global package like gnome/locale/XX ? Probably, it can be converted to just meta-package with a lot of dependencies on, e.g. xscreeensaver/locale/XX and so on. The other question is what to do with localization in this particular case... -- Best regards, Alexander Pyhalov, system administrator of Computer Center of Southern Federal University ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] conflicting files, dependencies and moving spec files to oi-userland
On Fri, Jul 12, 2013 at 08:23:45PM +0400, Alexander Pyhalov wrote: > Hello. > I'm trying to import SUNWxscreensaver.spec to oi-userland. > The issue is that it is actually three different packages. I've > almost finished with xscreensaver itself, but there are also > xscreensaver/hacks, xscreensaver/hacks/hacks-gl and > xscreensaver/hacks/rss-glx. > The process of determining package boundaries is rather boring and > error-prone :) > > So, I came to the following: > now we ship xscreensaver.mo files in gnome/locale/XX packages, which > (at least gnome/locale/ru) by the way conflict with > gnome/accessibility/gnome-a11y-libs (on > usr/share/locale/ru/LC_MESSAGES/at-spi.mo), desktop/gtk2 (on > usr/share/locale/ru/LC_MESSAGES/gtk20.mo) and so on > > The question is following: if we build application on by-component > basis, how can we create global package like gnome/locale/XX ? > Probably, it can be converted to just meta-package with a lot of > dependencies on, e.g. xscreeensaver/locale/XX and so on. > > The other question is what to do with localization in this > particular case... We should probably start to use facets for locale files (.mo). As it is done by Solaris 11. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | |jabber: mar...@jabber.sk | +---+ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Release engineering // planing
On 2013-07-12 18:09, Alexander Pyhalov wrote: Hello. It's almost unreal. Well, it was worth trying to offer the idea, good or bad :) > We now struggle with two different compilers in base, and the only logic way in my opinion is to just go on with GCC. Code can't be "just recompiled", every Makefile needs its tweaks to support one or another compiler. If it is not tested with Sun Studio in /hipster, it will not work with Sun Studio in /dev and so it will require inadequate amount of energy to be ported. Why do you need Sun Studio? I, personally, don't. There are others in the community with more practical preference toward the Studio, at least for some of their software. I can not vouch whether, for example, compiler difference would provide for faster and/or more stable code on the same machines. I am also unsure if the GCC stack provides for such features like library versioning (recent PNG example could in theory be avoided by having one binary file with several defined versions, and the programs would state which one they need during dynamic linking). Similarly, I don't know if the GCC stack allows for different binary builds to be imported from a single file (i.e. generic that is capable of working anywhere, and optimized for specific opteron/xeon CPU features that may fail to execute on older processors which lack specific commands or registers). All I can say on this matter is that so far it has served us well, and work with GCC is trodding new ground - you know the problems first-hand ;) On the opposite side, this is a proprietary compiler of a fixed version with limited availability and aging every day, unlike open GCC which can evolve and become better, even if something is lacking today. On the third side, this is somewhat reminiscent of arguments on why we need SPARC support in illumos-gate - it is not only for practical needs of those who own and want to run old SPARC boxes with new OSes (as OpenSXCE now allows them to), but it is also about "honestly keeping a promise" about the code's portability by having at least two platforms that it works on. This may be somewhat moot for compiler stacks, however. Linux is happily limited by GCC-only (at least was, when I dealt with it, with the recommended kernel-compiler being gcc-2.95 while other components could use gcc-3.x.x long present at that time). Also, such "promise" (if at all desired, and anyone decides to do it) can be fulfilled by other compilers - intelcc, clang, whatever - especially if they are more open and available. I did already provide an argument that having the code compiled by another toolchain can also serve to verify that it is good and clean - if there are some things one chain checks for and others don't. Maybe this is a benefit (except when making stupid workarounds to fight the uncooperative compiler which IS wrong) :) //Jim ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Release engineering // planing
On 12/07/2013 18:09, Alexander Pyhalov wrote: On 07/12/2013 19:52, Jim Klimov wrote: ... Then when code is promoted to /dev and ultimately /release it can be recompiled with SS. On one hand it would give another tool's verification opinion about the code quality, and on another (if SS-built code so far is assumed more stable) - the less adventurous users would have more peace of mind with their non-experimental machines running /dev or /release. It's almost unreal. We now struggle with two different compilers in base, and the only logic way in my opinion is to just go on with GCC. Code can't be "just recompiled", every Makefile needs its tweaks to support one or another compiler. If it is not tested with Sun Studio in /hipster, it will not work with Sun Studio in /dev and so it will require inadequate amount of energy to be ported. Why do you need Sun Studio? Because of legal reasons, Sun Studio has to vanish finally, gcc is the ultimate target for OI. But since this switch is nontrivial, we will live a while with a mixed system, which is not a big problem except for C++ (where compilers cannot be mixed by Standards © requirement), where we have the /usr/g++/ tree for the new libraries. Switching to gcc will be transparent for users in kernel space, but must be done package by package in userland, since there will be dependences and a couple of heads up for users which use system/distro libraries (just think of all the python and perl packages, I get a headache when I only think about it...). smime.p7s Description: S/MIME Cryptographic Signature ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] bits from JDS to userland: Re: conflicting files, dependencies and moving spec files to oi-userland
Hi, is there any process in place for moving bits from JDS to userland? I was thinking about possibility to update some JDS bits (with specs, of course). And I need to know which bits I could remove from JDS. Could anybody responsible for hipster release engineering talk to me about it? As for conflicting bits - gnome/locale/xxx should be obsoleted in hipster already so I do not know which conflict you see. But I did not try hipster yet so I have no idea what's broken there. Best regards, Milan On pá, 2013-07-12 at 20:23 +0400, Alexander Pyhalov wrote: > Hello. > I'm trying to import SUNWxscreensaver.spec to oi-userland. > The issue is that it is actually three different packages. I've almost > finished with xscreensaver itself, but there are also > xscreensaver/hacks, xscreensaver/hacks/hacks-gl and > xscreensaver/hacks/rss-glx. > The process of determining package boundaries is rather boring and > error-prone :) > > So, I came to the following: > now we ship xscreensaver.mo files in gnome/locale/XX packages, which (at > least gnome/locale/ru) by the way conflict with > gnome/accessibility/gnome-a11y-libs (on > usr/share/locale/ru/LC_MESSAGES/at-spi.mo), desktop/gtk2 (on > usr/share/locale/ru/LC_MESSAGES/gtk20.mo) and so on > > The question is following: if we build application on by-component > basis, how can we create global package like gnome/locale/XX ? Probably, > it can be converted to just meta-package with a lot of dependencies on, > e.g. xscreeensaver/locale/XX and so on. > > The other question is what to do with localization in this particular > case... ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] bits from JDS to userland: Re: conflicting files, dependencies and moving spec files to oi-userland
Hello, Milan and others. On 07/12/2013 22:05, Milan Jurik wrote: Hi, is there any process in place for moving bits from JDS to userland? I was thinking about possibility to update some JDS bits (with specs, of course). And I need to know which bits I could remove from JDS. Could anybody responsible for hipster release engineering talk to me about it? I can't speak for the whole team, but I think there is no such process. I'm just trying to move one package (SUNWxscreensaver), because my recent changes must have broken xscreensaver/hacks/rss-glx . But I think that such migration would make package maintenance easier. As for conflicting bits - gnome/locale/xxx should be obsoleted in hipster already so I do not know which conflict you see. But I did not try hipster yet so I have no idea what's broken there. I forced installation of this package trying to find where xscreensaver.mo should come from. This brought a lot of warnings and I thought that something was broken. BTW, I have the initial prototype of SUNWxscreensaver (parts that come from xscreensaver itself, without xscreensaver/hacks/rss-glx. I'd appreciate if someone could try (evidently, IN SEPARATE BOOT ENVIRONMENT) new xscreensaver (available at http://buildzone.oi-build.r61.net:1000/) and give some comments on https://github.com/pyhalov/oi-userland/compare/xscreensaver. -- Best regards, Alexander Pyhalov, system administrator of Computer Center of Southern Federal University ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Release engineering // planing
/dev is solid, but /hipster is ripe with breaking. The only way to do that is to move /dev to /release and when /hipster is "mostly" stable, then move it to /dev to work out the rest of the problems before moving to /release. This would have to be done on a mostly conservative schedule like NetBSD instead of more quickly so the stability of OI doesn't change. But I do have a question about another branch. What is /experimental for and how often is it updated and how is it updated? From: Erol Zavidic To: OpenIndiana Developer mailing list Sent: Friday, July 12, 2013 10:42 AM Subject: Re: [oi-dev] Release engineering // planing On 12 July 2013 13:49, G B wrote: /hipster should be the -current like FreeBSD >/dev should be -stable like FreeBSD >/release or /stable should be -RELEASE like FreeBSD > >/hipster can keep having its breakage, that is fine. But what I'd see is /dev >get illumos-gate updates and tested and when no problems are found and it is >stable, then get promoted to /release, and keep this cycle. > >Thus, /dev and /release will be sunstudio, but I don't know how one can get >/hipster promoted to /dev because of gcc. > >I guess it could be that /hipster always stays out there as a -current while >/dev and /release stay with sunstudio because right now /dev is most >rock-solid and that should not be taken away. While /hipster has newer >packages available, if someone is on /dev or /release there are other options >rather than trying to get what is in /hipster. opencsw.org has many current packages available, so anyone using /dev and /release can get them from opencsw.org. > > Important question over here: Are we ever going to promote hipster to /dev or /release then? This is question in particular due to gcc/sunstudio differences. Cheers, Erol ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Bumping libxml2 to v2.9.1
Good evening everybody, I managed to bump libxml2 to version 2.9.1. Please have a look at the changeset and review it please. Library built, tested, published and installed correctly. https://github.com/erolms/oi-userland/compare/libxml2 If all OK I can send pull request then for zlib and libxml2. Cheers, Erol ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Bumping libxml2 to v2.9.1
On Fri, Jul 12, 2013 at 9:48 PM, Erol Zavidic wrote: > Good evening everybody, > > I managed to bump libxml2 to version 2.9.1. Please have a look at the > changeset and review it please. Library built, tested, published and > installed correctly. > > https://github.com/erolms/oi-userland/compare/libxml2 > > If all OK I can send pull request then for zlib and libxml2. > Have you done a full build of illumos-gate on a system with the updated libxml2 and zlib? Illumos itself is critically dependent on libxml2, and having updates to libxml2 breaking the whole OS has happened in the past. Thanks, -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Bumping libxml2 to v2.9.1
if it is version from oracle userland-gate - works well for me with DilOS a long time. -- Best regards, Igor Kozhukhov On Jul 13, 2013, at 2:06 AM, Peter Tribble wrote: > On Fri, Jul 12, 2013 at 9:48 PM, Erol Zavidic wrote: > Good evening everybody, > > I managed to bump libxml2 to version 2.9.1. Please have a look at the > changeset and review it please. Library built, tested, published and > installed correctly. > > https://github.com/erolms/oi-userland/compare/libxml2 > > If all OK I can send pull request then for zlib and libxml2. > > Have you done a full build of illumos-gate on a system with the > updated libxml2 and zlib? Illumos itself is critically dependent on > libxml2, and having updates to libxml2 breaking the whole OS > has happened in the past. > > Thanks, > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ > ___ > oi-dev mailing list > oi-dev@openindiana.org > http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Release engineering // planing
Once, there was a plan to implement similar system, which was proposed in this thread. /experimental was supposed to be something /hipster is. Things from /experimental would move to /dev. So, we should be careful and not start doing something, which could have worked, but never did because of confusion about which development branch should be used, lack of man power and interest from developers. Adam On 12 Jul 2013, at 21:18, G B wrote: > /dev is solid, but /hipster is ripe with breaking. The only way to do that > is to move /dev to /release and when /hipster is "mostly" stable, then move > it to /dev to work out the rest of the problems before moving to /release. > > This would have to be done on a mostly conservative schedule like NetBSD > instead of more quickly so the stability of OI doesn't change. > > But I do have a question about another branch. What is /experimental for and > how often is it updated and how is it updated? > > > From: Erol Zavidic > To: OpenIndiana Developer mailing list > Sent: Friday, July 12, 2013 10:42 AM > Subject: Re: [oi-dev] Release engineering // planing > > On 12 July 2013 13:49, G B wrote: > /hipster should be the -current like FreeBSD > /dev should be -stable like FreeBSD > /release or /stable should be -RELEASE like FreeBSD > > /hipster can keep having its breakage, that is fine. But what I'd see is > /dev get illumos-gate updates and tested and when no problems are found and > it is stable, then get promoted to /release, and keep this cycle. > > Thus, /dev and /release will be sunstudio, but I don't know how one can get > /hipster promoted to /dev because of gcc. > > I guess it could be that /hipster always stays out there as a -current while > /dev and /release stay with sunstudio because right now /dev is most > rock-solid and that should not be taken away. While /hipster has newer > packages available, if someone is on /dev or /release there are other options > rather than trying to get what is in /hipster. opencsw.org has many current > packages available, so anyone using /dev and /release can get them from > opencsw.org. > > > Important question over here: > > Are we ever going to promote hipster to /dev or /release then? This is > question in particular due to gcc/sunstudio differences. > > Cheers, > Erol > > ___ > oi-dev mailing list > oi-dev@openindiana.org > http://openindiana.org/mailman/listinfo/oi-dev > > ___ > oi-dev mailing list > oi-dev@openindiana.org > http://openindiana.org/mailman/listinfo/oi-dev smime.p7s Description: S/MIME cryptographic signature ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Bumping libxml2 to v2.9.1
Erol, I went over the spec. Looks very good. Captures the upstream patches. ~ Ken From: Erol Zavidic To: oi-dev Sent: Friday, July 12, 2013 4:48 PM Subject: [oi-dev] Bumping libxml2 to v2.9.1 Good evening everybody, I managed to bump libxml2 to version 2.9.1. Please have a look at the changeset and review it please. Library built, tested, published and installed correctly. https://github.com/erolms/oi-userland/compare/libxml2 If all OK I can send pull request then for zlib and libxml2. Cheers, Erol ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Bumping libxml2 to v2.9.1
Erol, I went over the spec. Looks very good. Captures the upstream patches. ~ Ken From: Erol Zavidic To: oi-dev Sent: Friday, July 12, 2013 4:48 PM Subject: [oi-dev] Bumping libxml2 to v2.9.1 Good evening everybody, I managed to bump libxml2 to version 2.9.1. Please have a look at the changeset and review it please. Library built, tested, published and installed correctly. https://github.com/erolms/oi-userland/compare/libxml2 If all OK I can send pull request then for zlib and libxml2. Cheers, Erol ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Bumping libxml2 to v2.9.1
Erol, I went over the spec. Looks very good. Captures the upstream patches. ~ Ken From: Erol Zavidic To: oi-dev Sent: Friday, July 12, 2013 4:48 PM Subject: [oi-dev] Bumping libxml2 to v2.9.1 Good evening everybody, I managed to bump libxml2 to version 2.9.1. Please have a look at the changeset and review it please. Library built, tested, published and installed correctly. https://github.com/erolms/oi-userland/compare/libxml2 If all OK I can send pull request then for zlib and libxml2. Cheers, Erol ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
