~alpine/devel

6 5

[alpine-devel] Alpine 2.2

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<1289383750.18266.23.camel@ncopa-desktop.nor.wtbts.net>
Sender timestamp
1289383750
DKIM signature
missing
Download raw message
Hi,

So Alpine 2.1 is out and its time to start plan for alpine-2.2. Here are
some of the things I would like to do for the 2.2 release, scheduled to
May 2011.

* x86_64 alpine port
* java support (openjdk)
* Go Lang support
* llvm/clang support (maybe we can base alpine-3 completely on clang)
* improve admin tools, setup-alpine, ACF, unattended installer etc
* apk-tools: "install_if" (or "conditional groups")
* lua binding to apk-tools
* improve abuild (move dependency handling to lua code, build in empty
chroot)
* support for cross compiling in abuild?
* autobuilding of edge snapshot iso images
* improve testing / quality assurance
* python3?
* new version of uclibc, linux kernel, and lots of other new apps
* Qt support
* GNOME?

Anything else?

If there are some of the above (or something else) you would like to
work on, please fell free to let me know. I have various of the above
stuff partially done already.

If you have some ideas please feel free to send feedback. I'm specially
interested in ideas what we can do to improve the admin tools,
setup-alpine, setup-disk and quality assurance.

Thanks!

-nc



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Cameron Banta <cbanta@gmail.com>
Details
Message ID
<4CDAA9ED.5040200@gmail.com>
In-Reply-To
<1289383750.18266.23.camel@ncopa-desktop.nor.wtbts.net> (view parent)
Sender timestamp
1289398765
DKIM signature
missing
Download raw message
On 11/10/2010 04:09 AM, Natanael Copa wrote:
> Hi,
>
> So Alpine 2.1 is out and its time to start plan for alpine-2.2. Here are
> some of the things I would like to do for the 2.2 release, scheduled to
> May 2011.
>
> * x86_64 alpine port
> * java support (openjdk)
> * Go Lang support
> * llvm/clang support (maybe we can base alpine-3 completely on clang)
> * improve admin tools, setup-alpine, ACF, unattended installer etc
> * apk-tools: "install_if" (or "conditional groups")
> * lua binding to apk-tools
> * improve abuild (move dependency handling to lua code, build in empty
> chroot)
> * support for cross compiling in abuild?
> * autobuilding of edge snapshot iso images
> * improve testing / quality assurance
> * python3?
> * new version of uclibc, linux kernel, and lots of other new apps
> * Qt support
> * GNOME?
>
> Anything else?

Are there any thoughts on whether or not we need a tool to choose 
default versions? For example, if we were to maintain and both Python2.6 
and Python3, it would be nice to be able to choose which one is the 
default.

We could probably port eselect or update-alternatives.

Or, to keep it simple, do we just support one version, or only allow one 
of those packages to be installed at one time?

> If there are some of the above (or something else) you would like to
> work on, please fell free to let me know. I have various of the above
> stuff partially done already.
>
> If you have some ideas please feel free to send feedback. I'm specially
> interested in ideas what we can do to improve the admin tools,
> setup-alpine, setup-disk and quality assurance.
>
> Thanks!
>
> -nc

-Cameron


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Nathan Angelacos <nangel@alpinelinux.org>
Details
Message ID
<20101111103230.492caad9@thx.my.domain>
In-Reply-To
<1289383750.18266.23.camel@ncopa-desktop.nor.wtbts.net> (view parent)
Sender timestamp
1289471550
DKIM signature
missing
Download raw message
On Wed, 10 Nov 2010 11:09:10 +0100
Natanael Copa <ncopa@alpinelinux.org> wrote:

> 
> * improve admin tools, setup-alpine, ACF, unattended installer etc

From http://www.linuxbsdos.com/2010/08/23/alpine-linux-2-review/

Like a default installation of Alpine Linux, the Browser-based
management interface is very basic, lacking features needed to
configure aspects of some of the services and applications. Most of
what you will accomplish on Alpine will be from the command line
(console or remote access via ssh).
...

If you are a power user, or want to be one, the browser-based
management interface, while intuitive to use, will be a secondary
management tool. Most of the serious stuff you will be doing will be
from the command line.


ACF is now several years old, and still described as "Basic". 

There are two basic types of ACFs:

Configuration (setting up networking, dnsmasq, etc)
Application (OpenSSL Certificate Authority)

Personally, like the author of the review, I use ssh for
configuration. But but use ACF for the applications. 

I wonder if we go for a "less is more" approach on ACF, and provide the
something like the current "Expert" tab for all configuration.
Basically, give a web interface to the config files.

And then focus on ACF Applications (e.g. setup-alpine, setup-disk)












---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Harry Lachanas <grharry@freemail.gr>
Details
Message ID
<4CDBB395.4040603@freemail.gr>
In-Reply-To
<1289383750.18266.23.camel@ncopa-desktop.nor.wtbts.net> (view parent)
Sender timestamp
1289466773
DKIM signature
missing
Download raw message
> Hi,
>
> So Alpine 2.1 is out and its time to start plan for alpine-2.2. Here are
> some of the things I would like to do for the 2.2 release, scheduled to
> May 2011.
>
> * x86_64 alpine port
I suppose that there will be also an x86_32 version of them all right?

Regards
Harry
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<1289479753.18266.103.camel@ncopa-desktop.nor.wtbts.net>
In-Reply-To
<4CDBB395.4040603@freemail.gr> (view parent)
Sender timestamp
1289479753
DKIM signature
missing
Download raw message
On Thu, 2010-11-11 at 11:12 +0200, Harry Lachanas wrote:
> > Hi,
> >
> > So Alpine 2.1 is out and its time to start plan for alpine-2.2. Here are
> > some of the things I would like to do for the 2.2 release, scheduled to
> > May 2011.
> >
> > * x86_64 alpine port
> I suppose that there will be also an x86_32 version of them all right?

we will not stop pushing out 32 bit releases.

-nc



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Jeff Bilyk <jbilyk@gmail.com>
Details
Message ID
<AANLkTimyzPyuy=_-=zJSHo_VKu60zNSY5qsUhME6jhcY@mail.gmail.com>
In-Reply-To
<1289383750.18266.23.camel@ncopa-desktop.nor.wtbts.net> (view parent)
Sender timestamp
1290049725
DKIM signature
missing
Download raw message
Re: testing and QA, I took a look at APTS (thanks to ncopa pointing it
out...).  Taking the initial idea but simplifying a bit, I figured
taking the following approach might work:

Take the .mk files from svn://svn.alpinelinux.org/apts, strip the
first line and sed apk_delete for apk_del.
Run the following script (a gutted version of run-tests from APTS):
----------
#!/bin/sh -e

# Get file to output to
OUTFILE="$@"
if [ -z "$OUTFILE" ];
 then echo "Usage: $0 outfile" && exit 0;
fi

# Clear file if text
echo "" > $OUTFILE

# Add package, run basic test then remove package
for package in `ls ./packages`;
do sh -e ./packages/$package >> $OUTFILE 2>&1 && echo "$package passed
tests" >> $OUTFILE;
done
----------

A sample of a .mk file that's in SVN that we could adapt: sed.mk:

----------
sed:
	apk_add $@
	echo "hello" | sed 's/hello/world/g' | grep 'world'
	apk_delete $@
	[ `readlink /bin/sed` = /bin/busybox ]
----------

The output can be redirected and parsed (or maybe just take stderr?)
so that once edge ISOs are autobuilt, they can have some basic tests
done on most packages (or just the important ones?).  Assuming the ISO
passes this basic QA upload the ISO to the mirrors.  If it fails, add
the output from the script to sircbot's output on alpine-devel so that
the package can be fixed.

Thoughts?

Jeff

On Wed, Nov 10, 2010 at 5:09 AM, Natanael Copa <ncopa@alpinelinux.org> wrote:
> Hi,
>
> So Alpine 2.1 is out and its time to start plan for alpine-2.2. Here are
> some of the things I would like to do for the 2.2 release, scheduled to
> May 2011.
>
> * x86_64 alpine port
> * java support (openjdk)
> * Go Lang support
> * llvm/clang support (maybe we can base alpine-3 completely on clang)
> * improve admin tools, setup-alpine, ACF, unattended installer etc
> * apk-tools: "install_if" (or "conditional groups")
> * lua binding to apk-tools
> * improve abuild (move dependency handling to lua code, build in empty
> chroot)
> * support for cross compiling in abuild?
> * autobuilding of edge snapshot iso images
> * improve testing / quality assurance
> * python3?
> * new version of uclibc, linux kernel, and lots of other new apps
> * Qt support
> * GNOME?
>
> Anything else?
>
> If there are some of the above (or something else) you would like to
> work on, please fell free to let me know. I have various of the above
> stuff partially done already.
>
> If you have some ideas please feel free to send feedback. I'm specially
> interested in ideas what we can do to improve the admin tools,
> setup-alpine, setup-disk and quality assurance.
>
> Thanks!
>
> -nc
>
>
>
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
>
>



-- 
Jeff


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<1290589208.6958.30.camel@ncopa-desktop.nor.wtbts.net>
In-Reply-To
<AANLkTimyzPyuy=_-=zJSHo_VKu60zNSY5qsUhME6jhcY@mail.gmail.com> (view parent)
Sender timestamp
1290589208
DKIM signature
missing
Download raw message
sorry for late reply.

On Wed, 2010-11-17 at 22:08 -0500, Jeff Bilyk wrote:
> Re: testing and QA, I took a look at APTS (thanks to ncopa pointing it
> out...).  Taking the initial idea but simplifying a bit, I figured
> taking the following approach might work:
> 
> Take the .mk files from svn://svn.alpinelinux.org/apts, strip the
> first line and sed apk_delete for apk_del.
> Run the following script (a gutted version of run-tests from APTS):
> ----------
> #!/bin/sh -e
> 
> # Get file to output to
> OUTFILE="$@"
> if [ -z "$OUTFILE" ];
>  then echo "Usage: $0 outfile" && exit 0;
> fi
> 
> # Clear file if text
> echo "" > $OUTFILE
> 
> # Add package, run basic test then remove package
> for package in `ls ./packages`;
> do sh -e ./packages/$package >> $OUTFILE 2>&1 && echo "$package passed
> tests" >> $OUTFILE;
> done
> ----------
> 
> A sample of a .mk file that's in SVN that we could adapt: sed.mk:
> 
> ----------
> sed:
> 	apk_add $@
> 	echo "hello" | sed 's/hello/world/g' | grep 'world'
> 	apk_delete $@
> 	[ `readlink /bin/sed` = /bin/busybox ]
> ----------
> 
> The output can be redirected and parsed (or maybe just take stderr?)
> so that once edge ISOs are autobuilt, they can have some basic tests
> done on most packages (or just the important ones?).  Assuming the ISO
> passes this basic QA upload the ISO to the mirrors.  If it fails, add
> the output from the script to sircbot's output on alpine-devel so that
> the package can be fixed.
> 
> Thoughts?

sounds good. But i think we should split the testing in 2 parts:
1. testing packages
2. testing iso images

Packages needs to be tested before the releases. We should test the
packages while they are in edge. (and we should make edge snapshots)

I also think that we should try make some regression tests. For example,
when we upgraded kamailio to 3.1 there was a problem with config files
ending up in /usr. I didnt detect that since kamailio started just fine
anyways. So we could have a test that verifies that config is in correct
place.

Ideally, when there is a problem with a package, we should make a test
script that triggers the error so we can make sure the same problem
never comes back again.

When it comes to testing iso images, I think some (half)automated way to
test the installer would be good, verify that lbu commit works, verify
that encrypted apkovls work etc. Edge snapshots should be tested too.


Now, we need to start some place, so I think what you do is good.

-nc



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Reply to thread Export thread (mbox)