[oi-dev] Release engineering // planing
Andrzej Szeszo
aszeszo at gmail.com
Mon Jul 15 14:14:05 UTC 2013
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/<something>/<"core"> and
pkg.openindiana.org/<something>/<"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 <jimklimov at cos.ru> 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 at openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev
More information about the oi-dev
mailing list