[oi-dev] Release engineering // planing

[Erol Zavidic]

On 11 July 2013 01:12, Adam Števko <adam.stevko at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20130712/174880f3/attachment-0005.html>