Re: [oi-dev] Release engineering // planing

[ken mays]

Hi Udo,

Jon Tibble takes care of the release.

The oi-userland is nearing update completion to the s12-23 upstream specs. I've 
mapped out the s12-26 update specs on the Wiki.

Give it some time... a few important bugs need ironing out as well.

~ Ken






 From: Udo Grabowski (IMK) 
To: OpenIndiana Developer mailing list  
Sent: Monday, July 15, 2013 12:29 PM
Subject: Re: [oi-dev] Release engineering // planing
 

On 15/07/2013 16:14, Andrzej Szeszo wrote:
> Hi All
>
> At least for now, /hipster contribution process should stay as it is:
> pull requests/direct commits to the github repo. The team is too small
> to consider any other options at the moment in my opinion.
>
> I reckon /dev can stay as it is now as well. Jon Tibble is working on
> getting the repo updated. When he's done, the update should not break
> thousands of existing OI installations. There is a risk of making many
> users unhappy if we were to use /hipster repo to replace /dev.
>
> People who are interested in stable release are generally using OI on
> the servers. I think future formal hipster-based OI releases could
> have packages split into two sets. The "core" one and the "all the
> rest" one. Let's learn from the mistakes made in the past and
> successes of the other distros and make supported "core" package set
> small (additional packages supported on best effort basis).
>
> Also, it would make a lot of sense to have per-release repositories,
> like pkg.openindiana.org//<"core"> and
> pkg.openindiana.org//<"all the rest">. "something" could be
> release codename, date tag, some version number, etc. It would make it
> easier to manage things that way. Repos would update quicker, mirrors
> would be easier to create and be smaller. It would prevent users from
> accidentally replacing all of their system files each time new release
> is made (in case of publishing each release to /stable, we have BEs,
> but still...). It would be easier to get rid of old unsupported
> releases going forward. Also, pkg5 solver would have less metadata to
> deal with and would work faster!

This is totally confusing. Is there a release, and when and where
will it happen ? Sounds like hipster is sometimes doing a release,
but dev/ (aka Ken) does this also. Or is hipster a ever changing
sandbox without release ? For what ? Sounds like alll responsibility
for making something stable should be laid on Ken's shoulders
picking the right pieces from hipster to put it into /dev to ever
get someting useful from hipster.

And no, there are indeed people outside who regularily use more
than "core" (whatever that means, there are more than enough "cores"
outside, we don't need another)...
-- 
Dr.Udo Grabowski    Inst.f.Meteorology a.Climate Research IMK-ASF-SAT
www.imk-asf.kit.edu/english/sat.php
KIT - Karlsruhe Institute of Technology            http://www.kit.edu
Postfach 3640,76021 Karlsruhe,Germany  T:(+49)721 608-26026 F:-926026

___
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

[Udo Grabowski (IMK)]

On 15/07/2013 16:14, Andrzej Szeszo wrote:

Hi All

At least for now, /hipster contribution process should stay as it is:
pull requests/direct commits to the github repo. The team is too small
to consider any other options at the moment in my opinion.

I reckon /dev can stay as it is now as well. Jon Tibble is working on
getting the repo updated. When he's done, the update should not break
thousands of existing OI installations. There is a risk of making many
users unhappy if we were to use /hipster repo to replace /dev.

People who are interested in stable release are generally using OI on
the servers. I think future formal hipster-based OI releases could
have packages split into two sets. The "core" one and the "all the
rest" one. Let's learn from the mistakes made in the past and
successes of the other distros and make supported "core" package set
small (additional packages supported on best effort basis).

Also, it would make a lot of sense to have per-release repositories,
like pkg.openindiana.org//<"core"> and
pkg.openindiana.org//<"all the rest">. "something" could be
release codename, date tag, some version number, etc. It would make it
easier to manage things that way. Repos would update quicker, mirrors
would be easier to create and be smaller. It would prevent users from
accidentally replacing all of their system files each time new release
is made (in case of publishing each release to /stable, we have BEs,
but still...). It would be easier to get rid of old unsupported
releases going forward. Also, pkg5 solver would have less metadata to
deal with and would work faster!


This is totally confusing. Is there a release, and when and where
will it happen ? Sounds like hipster is sometimes doing a release,
but dev/ (aka Ken) does this also. Or is hipster a ever changing
sandbox without release ? For what ? Sounds like alll responsibility
for making something stable should be laid on Ken's shoulders
picking the right pieces from hipster to put it into /dev to ever
get someting useful from hipster.

And no, there are indeed people outside who regularily use more
than "core" (whatever that means, there are more than enough "cores"
outside, we don't need another)...
--
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

[Andrzej Szeszo]

Hi All

At least for now, /hipster contribution process should stay as it is:
pull requests/direct commits to the github repo. The team is too small
to consider any other options at the moment in my opinion.

I reckon /dev can stay as it is now as well. Jon Tibble is working on
getting the repo updated. When he's done, the update should not break
thousands of existing OI installations. There is a risk of making many
users unhappy if we were to use /hipster repo to replace /dev.

People who are interested in stable release are generally using OI on
the servers. I think future formal hipster-based OI releases could
have packages split into two sets. The "core" one and the "all the
rest" one. Let's learn from the mistakes made in the past and
successes of the other distros and make supported "core" package set
small (additional packages supported on best effort basis).

Also, it would make a lot of sense to have per-release repositories,
like pkg.openindiana.org//<"core"> and
pkg.openindiana.org//<"all the rest">. "something" could be
release codename, date tag, some version number, etc. It would make it
easier to manage things that way. Repos would update quicker, mirrors
would be easier to create and be smaller. It would prevent users from
accidentally replacing all of their system files each time new release
is made (in case of publishing each release to /stable, we have BEs,
but still...). It would be easier to get rid of old unsupported
releases going forward. Also, pkg5 solver would have less metadata to
deal with and would work faster!

Again, we are too small and it is too early to consider formal
releases in my opinion. Unless there are any volunteers to take on the
responsibility? :)

I am very happy to see oi-userland/hipster ball rolling by the way.
Big thanks to everyone who contributed to oi-userland github repo so
far!

Andrzej



On 14 July 2013 16:51, Jim Klimov  wrote:
> On 2013-07-14 15:15, G B wrote:
>>
>> I wouldn't see a problem for this aforementioned because as I mentioned,
>> there won't likely be any new technologies added to OI, such as, ZFS
>> encryption that would say "bump me to a 152 release."
>
>
> I wonder if it is practical to complicate things with
> numbering in such manner, by the way? While it is true
> that illumos kernel was forked from Solaris codebase at
> the time that it reached a specific numbered milestone,
> they evolve in separate universes now. For the development
> numbering we might as well retain this, to simplify updates
> into newer builds for one thing, and for the odd chance
> that the owner of Solaris IP at some time in the future
> would go open-source again and merge code - so we'd bump
> the repo name to their milestone number at that time...
>
> But was there a release, "The Release", of OpenIndiana?
>
> Maybe the first one should be numbered "1"? Or "11" to
> match Oracle's marketing scheme and some similarities
> between the products (somewhere in that string of version
> minor numbers they too have the repo level like 175, BTW)?
>
> I believe it won't be a problem for packaged builds - the
> release/stable packages come from a different repository
> and can have their own version history, I think...
>
> What do you think?
>
> //Jim
>
>
>
> ___
> 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

[Jim Klimov]

On 2013-07-14 15:15, G B wrote:

I wouldn't see a problem for this aforementioned because as I mentioned,
there won't likely be any new technologies added to OI, such as, ZFS
encryption that would say "bump me to a 152 release."


I wonder if it is practical to complicate things with
numbering in such manner, by the way? While it is true
that illumos kernel was forked from Solaris codebase at
the time that it reached a specific numbered milestone,
they evolve in separate universes now. For the development
numbering we might as well retain this, to simplify updates
into newer builds for one thing, and for the odd chance
that the owner of Solaris IP at some time in the future
would go open-source again and merge code - so we'd bump
the repo name to their milestone number at that time...

But was there a release, "The Release", of OpenIndiana?

Maybe the first one should be numbered "1"? Or "11" to
match Oracle's marketing scheme and some similarities
between the products (somewhere in that string of version
minor numbers they too have the repo level like 175, BTW)?

I believe it won't be a problem for packaged builds - the
release/stable packages come from a different repository
and can have their own version history, I think...

What do you think?

//Jim


___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Release engineering // planing

[G B]

If OI is to follow FreeBSD's engineering releases, which I think is optimal, 
then for example:

OI 152a1 would be qualified as a -current because it is experimental and will 
be the next major branch.  Or this could be 160a1, but I'm not sure there is 
any new development in OI that would qualify for such a large change.

OI 151a8 would be qualified as the next -stable (/dev repo) because it is in 
the 151 branch of releases.  What goes into here is for the next minor release. 
 FreeBSD 9.x branch gets 9.1, 9.2, etc.


OI 151r1 would be the first -release of the 151a7 -stable.

But is there enough of a development staff to maintain something like this?  
Apparently, /experimental, /dev, and the never released foreverware was 
supposed to be this model, but it fell through.  If there isn't staff 
available, then maybe /dev should stay that way "forever" and just keep getting 
bumped to a8, a9, a10, etc., and /hipster can stay out there for those who 
prefer to track that repo. 


I wouldn't see a problem for this aforementioned because as I mentioned, there 
won't likely be any new technologies added to OI, such as, ZFS encryption that 
would say "bump me to a 152 release."






 From: Christopher Chan 
To: oi-dev@openindiana.org 
Sent: Saturday, July 13, 2013 5:51 PM
Subject: Re: [oi-dev] Release engineering // planing
 


samba needs to be updated from 3.5.8 before it can be considered good enough 
for /release.


On Friday, July 12, 2013 09: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?
>~ Ken Mays 
>
>
>
>
> From:  G B ; 
>To:  OpenIndiana Developer mailing list ; 
>Subject:  Re: [oi-dev] Release engineering // planing 
>Sent:  Fri, Jul 12, 2013 11:49:21 AM 
>
>
>/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)  
wr

Re: [oi-dev] Release engineering // planing

[Christopher Chan]

samba needs to be updated from 3.5.8 before it can be considered good 
enough for /release.



On Friday, July 12, 2013 09: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?

~ Ken Mays



*From: * G B ;
*To: * OpenIndiana Developer mailing list ;
*Subject: * Re: [oi-dev] Release engineering // planing
*Sent: * Fri, Jul 12, 2013 11:49:21 AM

/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


___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Release engineering // planing

[Adam Števko]

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] Release engineering // planing

[G B]

/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

Re: [oi-dev] Release engineering // planing

[Udo Grabowski (IMK)]

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

Re: [oi-dev] Release engineering // planing

[Jim Klimov]

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

[Alexander Pyhalov]

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

Re: [oi-dev] Release engineering // planing

[Jim Klimov]

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

[Jim Klimov]

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

[Erol Zavidic]

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

[Erol Zavidic]

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

[Udo Grabowski (IMK)]

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

[Piotr Jasiukajtis]

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

[Jim Klimov]

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

[ken mays]

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

[G B]

/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

[ken mays]

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

Re: [oi-dev] Release engineering // planing

[Udo Grabowski (IMK)]

On 11/07/2013 20:33, Piotr Jasiukajtis wrote:

I think an updated illumos-gate packages should go into oi_151a7 first, because 
of NFS related BUG fix #2986.


Agreed, most NFS fixes up to now are also very interesting to us,
and illumos gate has a good peer review to trust it to be stable.



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).


On 11/07/2013 22:06, Jonathan Adams wrote:
> a separate dev where anything goes however allows development
> to happen at a
> much greater pace for initial testing, without disturbing
> the long term future "stable"s.

At least before a stable release is in sight, a /dev repository
is a good temporary testbed before rolling out, it can select
only the more stable stuff to test, and can rest for a while
after the actual release.




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

[Jonathan Adams]

I still believe that a 3 repository system would be best, a release/stable
which will start with a7, a dev which will have the bits from bleeding that
check out with enough LGTM's and a bleeding edge which is closer to a "wild
frontier" where almost anything goes.

give the keys to stable to someone who will guard it well, and trusts nobody
let dev be the place where good/stable _looking_ code goes
leave the gate wide open and trust that the build errors will be fixed some
time in bleeding edge.

the great trouble with the LGTM system is that you cannot easily prove that
something is stable until it has been tested by a lot of users, having a
well used dev allows for this.

a separate dev where anything goes however allows development to happen at
a much greater pace for initial testing, without disturbing the long term
future "stable"s.

Just my 2 cents.

Jon


On 11 July 2013 19:33, Piotr Jasiukajtis  wrote:

> 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

Re: [oi-dev] Release engineering // planing

[Piotr Jasiukajtis]

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

Re: [oi-dev] Release engineering // planing

[Udo Grabowski (IMK)]

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).





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

[Geoff Nordli]

As I have a few servers deployed in production with OI I am happy to see 
the ball rolling again.   I use OI as a virtualization host with VBox.


How do we get it so there are "checkpoints" in the release cycle that 
you can target a specific point in time?  Something that doesn't cause 
too much burden to manage from a developer point of view.  When I am 
deploying an OI server I can target that date/version.


thanks,

Geoff


On 13-07-11 09:58 AM, h...@myhomeemail.co.uk wrote:

Strongly agree on all notes Alisdair has made.
Furthermore, if people are using OI in production, they should have 
their own suitable testing procedures in place to avoid the majority 
of (if not all) upsets.

Regards

On 11 July 2013 at 17:53 Alasdair Lumsden  wrote:

Hi All,
Back in the days of oi-build, we tried to have a process, and enforce 
quality, and it just resulted in super slow progress followed by 
near-death. Andrzej didn't contribute at all as he didn't like 
the bureaucracy, he just wants to hack-and-go.
So after all that, I basically think Andrzej is completely right with 
his current approach - breaking things should be allowed. You can't 
make an omelette quickly and easily without breaking a few eggs.
Hipster is an experimental development branch for making rapid 
progress. If you break something, you can fix it after, no big deal.
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.
And on an unrelated note, someone motivated enough should do 
something about www.openindiana.org  - 
it's ugly and out of date :-)

Regards,
Alasdair



___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Release engineering // planing

[h...@myhomeemail.co.uk]

Strongly agree on all notes Alisdair has made.

Furthermore, if people are using OI in production, they should have their own
suitable testing procedures in place to avoid the majority of (if not all)
upsets.

Regards


> On 11 July 2013 at 17:53 Alasdair Lumsden  wrote:
> 
>  Hi All,
> 
>  Back in the days of oi-build, we tried to have a process, and enforce
> quality, and it just resulted in super slow progress followed by near-death.
> Andrzej didn't contribute at all as he didn't like the bureaucracy, he just
> wants to hack-and-go.
> 
>  So after all that, I basically think Andrzej is completely right with his
> current approach - breaking things should be allowed. You can't make an
> omelette quickly and easily without breaking a few eggs.
> 
>  Hipster is an experimental development branch for making rapid progress. If
> you break something, you can fix it after, no big deal.
> 
>  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.
> 
>  And on an unrelated note, someone motivated enough should do something
> about - it's ugly and out of date :-)
> 
>  Regards,
> 
>  Alasdair
> 
> 
> 
>  On Thu, Jul 11, 2013 at 3:19 PM, Ken Gunderson   > wrote:
>> > At Thu, 11 Jul 2013 01:12:50 +0200,
> >Adam Števko wrote:
> >>
> >> Hi Erol,
> >>
> >> On Jul 10, 2013, at 11:50 PM, Erol Zavidic < ero...@gmail.com
> >>  > wrote:
> >>
> >> Good evening folks,
> >>
> >> thanks for your feedbacks so far, here's the summary clustered in
> >> some way:
> >>
> >> 1.0 - Release Engineering:
> >> 1.1- should not be bureaucratic, i.e. rather an internal
> >> agreement (Alex)
> >>
> >> I support this type for now.
> >>
> >> 1.2- the process of pushing updates to /dev or /stable repos is
> >> undefined
> >> (Alex)
> >>
> >> 1.3- safeguarding /stable repo (Jon)
> >> 1.4- streamline code review and integration process LGTMs
> >> (Adam)
> >> 1.5- build of many desktop packages impossible due to missing
> >> Manifests
> >> (David)
> >> 1.6- creation of development, release and stable branches
> >> within hipster
> >> repository (Erol)
> >I don't code and been away from OI for a while visiting other
> >interesting lands.  It's good to see OI getting some traction.  I have
> >used platforms developed on the release, stable, and testing model for
> >many years, e.g. FreeBSD.  It worked.  But I question whether this may
> >have become rather outdated with the advancement of more modern, agile
> >like models.  For example, on the desktop I have been using Archlinux,
> >wh/uses a rolling release model, and it has been working out quite
> >nicely.  This model eliminates the extra manpower required to maintain
> >separate branches.  Of course not many that I know of are using Arch
> >server side and I think a /stable branch may be beneficial and
> >justifiable on OI.  OTOH, OI was intended as continuation of OS, so
> >maybe desktop is it's niches, especially in light of SmartOS and
> >OmniOS offerings for server side use.  What compelling features does
> >OI offer to compete with these?  Hence, maybe best not to and focus on
> >desktop niche.  Maybe not...
> > 
> >In any case, I have been doing some "DevOps" Engineering as of late
> >and moving more towards a rolling release model would facilitate
> >"Continuous Delivery" < >.  Frequent
> >smaller changes make breakages easier to track than "vetting" big
> >releases and keep things fresher on the desktop.
> > 
> >Just a few thoughts.  We now return you to your regularly scheduled
> >programming...
> > 
> >Peace-- Ken
> > 
> >___
> >oi-dev mailing list
> >oi-dev@openindiana.org 
> >
> >  > 
> 
> 
>  --
>  Alasdair Lumsden
> 
>  
> 
> 
>  EveryCity Managed Hosting
>  Studio 18 Bluelion Place
>  237 Long Lane, London, SE1 4PU
> 
>  general: 020 7183 2800
>  support: 020 7183 2801
>  email: a...@everycity.co.uk 
> 
>  Every City Limited
>  Registered in England and Wales, No. 5689474 Registered Office: Roper
>  Yard, Roper Road, Canterbury, CT2 7EX
> 

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Release engineering // planing

[Alasdair Lumsden]

Hi All,

Back in the days of oi-build, we tried to have a process, and enforce
quality, and it just resulted in super slow progress followed by
near-death. Andrzej didn't contribute at all as he didn't like
the bureaucracy, he just wants to hack-and-go.

So after all that, I basically think Andrzej is completely right with his
current approach - breaking things should be allowed. You can't make
an omelette quickly and easily without breaking a few eggs.

Hipster is an experimental development branch for making rapid progress. If
you break something, you can fix it after, no big deal.

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.

And on an unrelated note, someone motivated enough should do something
about www.openindiana.org - it's ugly and out of date :-)

Regards,

Alasdair



On Thu, Jul 11, 2013 at 3:19 PM, Ken Gunderson wrote:

> At Thu, 11 Jul 2013 01:12:50 +0200,
> Adam Števko wrote:
> >
> > Hi Erol,
> >
> > On Jul 10, 2013, at 11:50 PM, Erol Zavidic  wrote:
> >
> > Good evening folks,
> >
> > thanks for your feedbacks so far, here's the summary clustered in
> some way:
> >
> > 1.0 - Release Engineering:
> > 1.1- should not be bureaucratic, i.e. rather an internal
> agreement (Alex)
> >
> > I support this type for now.
> >
> > 1.2- the process of pushing updates to /dev or /stable repos is
> undefined
> > (Alex)
> >
> > 1.3- safeguarding /stable repo (Jon)
> > 1.4- streamline code review and integration process LGTMs (Adam)
> > 1.5- build of many desktop packages impossible due to missing
> Manifests
> > (David)
> > 1.6- creation of development, release and stable branches within
> hipster
> > repository (Erol)
>
> I don't code and been away from OI for a while visiting other
> interesting lands.  It's good to see OI getting some traction.  I have
> used platforms developed on the release, stable, and testing model for
> many years, e.g. FreeBSD.  It worked.  But I question whether this may
> have become rather outdated with the advancement of more modern, agile
> like models.  For example, on the desktop I have been using Archlinux,
> wh/uses a rolling release model, and it has been working out quite
> nicely.  This model eliminates the extra manpower required to maintain
> separate branches.  Of course not many that I know of are using Arch
> server side and I think a /stable branch may be beneficial and
> justifiable on OI.  OTOH, OI was intended as continuation of OS, so
> maybe desktop is it's niches, especially in light of SmartOS and
> OmniOS offerings for server side use.  What compelling features does
> OI offer to compete with these?  Hence, maybe best not to and focus on
> desktop niche.  Maybe not...
>
> In any case, I have been doing some "DevOps" Engineering as of late
> and moving more towards a rolling release model would facilitate
> "Continuous Delivery" .  Frequent
> smaller changes make breakages easier to track than "vetting" big
> releases and keep things fresher on the desktop.
>
> Just a few thoughts.  We now return you to your regularly scheduled
> programming...
>
> Peace-- Ken
>
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev
>



-- 
Alasdair Lumsden

http://www.everycity.co.uk

EveryCity Managed Hosting
Studio 18 Bluelion Place
237 Long Lane, London, SE1 4PU

general: 020 7183 2800
support: 020 7183 2801
email: a...@everycity.co.uk

Every City Limited
Registered in England and Wales, No. 5689474 Registered Office: Roper
Yard, Roper Road, Canterbury, CT2 7EX
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Release engineering // planing

[Ken Gunderson]

At Thu, 11 Jul 2013 01:12:50 +0200,
Adam Števko wrote:
> 
> Hi Erol,
> 
> On Jul 10, 2013, at 11:50 PM, Erol Zavidic  wrote:
> 
> Good evening folks,
>
> thanks for your feedbacks so far, here's the summary clustered in some 
> way:
>
> 1.0 - Release Engineering:
> 1.1- should not be bureaucratic, i.e. rather an internal agreement 
> (Alex)
> 
> I support this type for now.
> 
> 1.2- the process of pushing updates to /dev or /stable repos is 
> undefined
> (Alex)
> 
> 1.3- safeguarding /stable repo (Jon)
> 1.4- streamline code review and integration process LGTMs (Adam)
> 1.5- build of many desktop packages impossible due to missing 
> Manifests
> (David)
> 1.6- creation of development, release and stable branches within 
> hipster
> repository (Erol)

I don't code and been away from OI for a while visiting other
interesting lands.  It's good to see OI getting some traction.  I have
used platforms developed on the release, stable, and testing model for
many years, e.g. FreeBSD.  It worked.  But I question whether this may
have become rather outdated with the advancement of more modern, agile
like models.  For example, on the desktop I have been using Archlinux,
wh/uses a rolling release model, and it has been working out quite
nicely.  This model eliminates the extra manpower required to maintain
separate branches.  Of course not many that I know of are using Arch
server side and I think a /stable branch may be beneficial and
justifiable on OI.  OTOH, OI was intended as continuation of OS, so
maybe desktop is it's niches, especially in light of SmartOS and
OmniOS offerings for server side use.  What compelling features does
OI offer to compete with these?  Hence, maybe best not to and focus on
desktop niche.  Maybe not...

In any case, I have been doing some "DevOps" Engineering as of late
and moving more towards a rolling release model would facilitate
"Continuous Delivery" .  Frequent
smaller changes make breakages easier to track than "vetting" big
releases and keep things fresher on the desktop.

Just a few thoughts.  We now return you to your regularly scheduled
programming...

Peace-- Ken

___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Release engineering // planing

[Adam Števko]

Hi Erol,

On Jul 10, 2013, at 11:50 PM, Erol Zavidic  wrote:

> Good evening folks,
> 
> thanks for your feedbacks so far, here's the summary clustered in some way:
> 
> 1.0 - Release Engineering:
> 1.1- should not be bureaucratic, i.e. rather an internal agreement (Alex)
I support this type for now.
> 1.2- the process of pushing updates to /dev or /stable repos is undefined 
> (Alex)
> 1.3- safeguarding /stable repo (Jon)
> 1.4- streamline code review and integration process LGTMs (Adam)
> 1.5- build of many desktop packages impossible due to missing Manifests 
> (David)
> 1.6- creation of development, release and stable branches within hipster 
> repository (Erol)
> 1.7- implementing feature requests (as Ken did), assigning tasks to 
> available developers (Erol)
> 
> 2.0 - Build toolset / infrastructure
> 2.1- package dependencies influencing build/installation of other 
> packages (Alex)
> 2.2- build tools outdated and need refresh (David)
> 
> 3.0 - General topics
> 3.1- decide on direction of /hipster effort (David)
> 
> Here some my thoughts about the topics above, please share your opinion.
> 
> ad 3.1: hipster is in my opinion a bleeding edge / unstable type of repo. It 
> should not be limited to core or server packages, ideally a source of all 
> packages for stable/dev repos. Building a server or desktop ISO should be 
> left then for the people creating these. I personally use desktop version of 
> OI, but that was my choice to use it.
I am interested in server aspects of OI and will work towards that direction 
(simple illumos-based server with available security fixes and packages in the 
repository, similar to the common linux model). I am not sure that it is the 
best to concentrate on all development branches. OpenIndiana hasn't made any 
stable release so far (at least none I am aware off) and this kills it. People 
are afraid of everything that is called /dev, /experimental or /prestable.  I 
and others have been using prestable builds of OpenIndiana for some time now 
and I declared that it is rock-solid and suitable for /stable release. 
Therefore, if we want to create some branches, I would definitely go for 
bleeding edge (/hipster) and make /stable out of current /dev. The questionn 
here is if we have enough man power to support /stable.

> ad 1.1, 1.4: agree here; LGTMs process failed and caused people to stop 
> contributing. Using branches in git we can easily setup quick review process 
> and contributors can send their pull requests towards hipster repository. 
> Integration is then easily done by people having rights to do this (Alex, 
> David, Adam, etc).
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. 

> 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).

> ad 1.5: it is an issue and I would label it with prio 2 at this very moment. 
> Can we exactly identify which packages are missing?
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!). 

> ad 1.6: would it make sense to create stable, dev, release and edge branches 
> within hipster repository to stabilize releases a bit? Propagation from edge 
> to dev and stable would be easy-peasy with git. As a rough Idea how it could 
> look alike have a look at Vincent Driessen blog entry.
> 
> ad 1.7: consider Ken's email with request for LibreOffice as a good example 
> where we could impl

Re: [oi-dev] Release engineering // planing

[Erol Zavidic]

Good evening folks,

thanks for your feedbacks so far, here's the summary clustered in some way:

1.0 - Release Engineering:
1.1- should not be bureaucratic, i.e. rather an internal agreement
(Alex)
1.2- the process of pushing updates to /dev or /stable repos is
undefined (Alex)
1.3- safeguarding /stable repo (Jon)
1.4- streamline code review and integration process LGTMs (Adam)
1.5- build of many desktop packages impossible due to missing Manifests
(David)
1.6- creation of development, release and stable branches within
hipster repository (Erol)
1.7- implementing feature requests (as Ken did), assigning tasks to
available developers (Erol)

2.0 - Build toolset / infrastructure
2.1- package dependencies influencing build/installation of other
packages (Alex)
2.2- build tools outdated and need refresh (David)

3.0 - General topics
3.1- decide on direction of /hipster effort (David)

Here some my thoughts about the topics above, please share your opinion.

ad 3.1: hipster is in my opinion a bleeding edge / unstable type of repo.
It should not be limited to core or server packages, ideally a source of
all packages for stable/dev repos. Building a server or desktop ISO should
be left then for the people creating these. I personally use desktop
version of OI, but that was my choice to use it.

ad 1.1, 1.4: agree here; LGTMs process failed and caused people to stop
contributing. Using branches in git we can easily setup quick review
process and contributors can send their pull requests towards hipster
repository. Integration is then easily done by people having rights to do
this (Alex, David, Adam, etc).

ad 1.3: clever release engineering is definitely required. It requires
integration testing. Do we have resources and/or testing environments for
this?

ad 1.5: it is an issue and I would label it with prio 2 at this very
moment. Can we exactly identify which packages are missing?

ad 1.6: would it make sense to create stable, dev, release and edge
branches within hipster repository to stabilize releases a bit? Propagation
from edge to dev and stable would be easy-peasy with git. As a rough Idea
how it could look alike have a look at Vincent Driessen blog
entry
.

ad 1.7: consider Ken's email with request for LibreOffice as a good example
where we could implement scrum method, delivering sprints and assigning
tasks to available volunteers. Which tool to use I cannot tell. JIRA is
obviously very common. Using milestones and issues in github one could
mimic the behaviour.

ad 2.1: package dependencies is indeed a prio 1 issue. I like the Alex's
idea of having BUILD and INSTALL dependencies listed. Would be manual
effort unless we can automate this. Any scripts to do this?

ad 2.2: prio 1* - needs immediate attention. David, you listed a few, can
we get a full list and split amongst us who is taking which tool to update?

Looking forward to your feedbacks and discussions.

Cheers, Erol



On 10 July 2013 11:52, Jonathan Adams  wrote:

> While not a contributor of code atm :(, I suggested something a system
> when OI started, which was sort of agreed to by some people at the time ...
>
> 1) stable repository, guarded rigorously by people who do not allow
> anything in unless it's been signed and sealed as core and stable,
> seriously if this was surrounded by the river styx and you had to pay with
> your soul to cross, that'd be sensible.
>
> 2) dev/apps repository where apps that are considered not core, and mostly
> stable go, and changes to core that need testing before going stable.
>
> 3) bleeding edge dev repository where apps and code that are basically
> considered volatile, latest releases and all core code changes go, for
> those who are happy with a suck-it-and-see approach.
>
> this would allow risk-averse server admin to pick "stable", less
> risk-averse server admin (or risk-averse laptop/desktop users) to pick
> "dev", and those who like sky-diving on the way to work to pick
> "unstable"/"bleeding edge" ...
>
> I would imagine /hipster to be in the latter, and the current /dev to be
> in "dev", but then, I'm an outsider.
>
> Jon
>
>
>
>
> On 10 July 2013 10:34, David Höppner <0xf...@gmail.com> wrote:
>
>> Hi,
>>
>> I can speak only for myself, but I think its too early to try this. In
>> my view hipster is currently
>> only a developer effort. Too many core packages (automake, libtool,
>> glib) still need to be updated
>> to build some newer software. Even that ruby 1.8.7 update is End of
>> Life now. Further many packages (desktop)
>> can't be rebuild, because we have no Manifests in hipster for them yet.
>>
>> We should discuss the general direction of hipster (desktop,
>> core package versions and updated (to build illumos)), but I think
>> there are too many open problems
>> to impose release quality at this stage.
>>
>> -- David
>>
>> On 10 July 2013 03:24, Erol Zavidic  wrote:
>> > Folks,
>> >
>> > I

Re: [oi-dev] Release engineering // planing

[Jonathan Adams]

While not a contributor of code atm :(, I suggested something a system when
OI started, which was sort of agreed to by some people at the time ...

1) stable repository, guarded rigorously by people who do not allow
anything in unless it's been signed and sealed as core and stable,
seriously if this was surrounded by the river styx and you had to pay with
your soul to cross, that'd be sensible.

2) dev/apps repository where apps that are considered not core, and mostly
stable go, and changes to core that need testing before going stable.

3) bleeding edge dev repository where apps and code that are basically
considered volatile, latest releases and all core code changes go, for
those who are happy with a suck-it-and-see approach.

this would allow risk-averse server admin to pick "stable", less
risk-averse server admin (or risk-averse laptop/desktop users) to pick
"dev", and those who like sky-diving on the way to work to pick
"unstable"/"bleeding edge" ...

I would imagine /hipster to be in the latter, and the current /dev to be in
"dev", but then, I'm an outsider.

Jon




On 10 July 2013 10:34, David Höppner <0xf...@gmail.com> wrote:

> Hi,
>
> I can speak only for myself, but I think its too early to try this. In
> my view hipster is currently
> only a developer effort. Too many core packages (automake, libtool,
> glib) still need to be updated
> to build some newer software. Even that ruby 1.8.7 update is End of
> Life now. Further many packages (desktop)
> can't be rebuild, because we have no Manifests in hipster for them yet.
>
> We should discuss the general direction of hipster (desktop,
> core package versions and updated (to build illumos)), but I think
> there are too many open problems
> to impose release quality at this stage.
>
> -- David
>
> On 10 July 2013 03:24, Erol Zavidic  wrote:
> > Folks,
> >
> > I just want to notice a thing or two from my side that might be relevant
> for the OI (hipster).
> >
> > What I've seen and consider really important is to implement a kind of
> release engineering. And here I do not want some complicated process with
> many approvals and stuff - rather a sleek and streamlined (hipster) release
> management.
> >
> > I've seen packages breaking builds because of incompatible versions
> (e.g. libmemcached bump made myself incompatible with php5.4, or ruby
> version breaking other stuff...).
> >
> > Is it feasible to organise a non-bureaucratic release management setting
> the priorities which packages should get updated first and then possibly
> check for defects produced by it?
> >
> > Just a thought - and willing to help with it. Let me know your thoughts.
> >
> > 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 mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Release engineering // planing

[David Höppner]

Hi,

I can speak only for myself, but I think its too early to try this. In
my view hipster is currently
only a developer effort. Too many core packages (automake, libtool,
glib) still need to be updated
to build some newer software. Even that ruby 1.8.7 update is End of
Life now. Further many packages (desktop)
can't be rebuild, because we have no Manifests in hipster for them yet.

We should discuss the general direction of hipster (desktop,
core package versions and updated (to build illumos)), but I think
there are too many open problems
to impose release quality at this stage.

-- David

On 10 July 2013 03:24, Erol Zavidic  wrote:
> Folks,
>
> I just want to notice a thing or two from my side that might be relevant for 
> the OI (hipster).
>
> What I've seen and consider really important is to implement a kind of 
> release engineering. And here I do not want some complicated process with 
> many approvals and stuff - rather a sleek and streamlined (hipster) release 
> management.
>
> I've seen packages breaking builds because of incompatible versions (e.g. 
> libmemcached bump made myself incompatible with php5.4, or ruby version 
> breaking other stuff...).
>
> Is it feasible to organise a non-bureaucratic release management setting the 
> priorities which packages should get updated first and then possibly check 
> for defects produced by it?
>
> Just a thought - and willing to help with it. Let me know your thoughts.
>
> 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] Release engineering // planing

[Adam Števko]

Hi Erol,

the model which was used back in oi-build/illumos-userland times wasn't  that 
bureaucratic. In short, you posted a change set, people reviewed it and 
LGTM-ied it. If your received 3 LGTMs, you package was added to the source 
tree. The only problem with this was that from certain time there weren't 
enough LGTMs and the contributor had to hunt those LGTMs and actually this was 
one of the reasons, which led people away from contributing. Do you think that 
similar model could work with less LGTMs? How long are you willing to wait 
before somebody will give you LGTM and not get a feeling that the process is 
bureaucratic and slows you down?

Cheers,
Adam


On Jul 10, 2013, at 3:24 AM, Erol Zavidic  wrote:

> Folks,
> 
> I just want to notice a thing or two from my side that might be relevant for 
> the OI (hipster). 
> 
> What I've seen and consider really important is to implement a kind of 
> release engineering. And here I do not want some complicated process with 
> many approvals and stuff - rather a sleek and streamlined (hipster) release 
> management. 
> 
> I've seen packages breaking builds because of incompatible versions (e.g. 
> libmemcached bump made myself incompatible with php5.4, or ruby version 
> breaking other stuff...). 
> 
> Is it feasible to organise a non-bureaucratic release management setting the 
> priorities which packages should get updated first and then possibly check 
> for defects produced by it?
> 
> Just a thought - and willing to help with it. Let me know your thoughts. 
> 
> Cheers, Erol
> ___
> 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] Release engineering // planing

[alp]

Hello.
Just several thoughts.
1) I look at /hipster as on FreeBSD-current - there should be no 
specific  "RE", but rather internal settlement (e.g. if you know that 
your changes can break something notify all beforehand, ask feedback and 
see if anyone cares).


BTW, can someone look through 
https://github.com/pyhalov/oi-userland/compare/php54-modules ? :)


2) Another question is real RE - i.e. migrating some stuff to /dev (and 
possibly one day to /stable ...).
3) One more problem is packages which influence build in a specific way 
- e.g., requires other packages to be rebuilt. It would be nice to catch 
(using current dependencies machinery or introducing something like 
"BUILD_DEPENDS/INSTALL_DEPENDS" in userland building scripts).



Erol Zavidic писал 10.07.2013 05:24:

Folks,

I just want to notice a thing or two from my side that might be
relevant for the OI (hipster).

What I've seen and consider really important is to implement a kind of
release engineering. And here I do not want some complicated process
with many approvals and stuff - rather a sleek and streamlined
(hipster) release management.

I've seen packages breaking builds because of incompatible versions
(e.g. libmemcached bump made myself incompatible with php5.4, or ruby
version breaking other stuff...).

Is it feasible to organise a non-bureaucratic release management
setting the priorities which packages should get updated first and
then possibly check for defects produced by it?

Just a thought - and willing to help with it. Let me know your 
thoughts.


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