new (testing) image
Mirko Vogt
lists at nanl.de
Thu Nov 11 07:24:26 EST 2010
On Wed, 2010-11-10 at 21:55 +0800, Xiangfu Liu wrote:
> Hi Mirko
Hey Xiangfu,
>
> feedback inline :)
same here:
>
> On 11/10/2010 08:02 PM, Mirko Vogt wrote:
> > Hey folks,
> >
> > since restructuring the git repository is now completed (thanks a lot to
> > Xiangfu at this point) and _lot's_ of fixes and updates have been
> > applied into the git repository since the last image got released, we
> > now have - guess what? - a new (testing) image[1]! :)
> >
> > As last time it's marked as "testing" for now.
> >
> > That means, from now on a merge window of 1 week got opened - feedback
> > is highly appreciated!
> >
> > I created a "testing" branch which is based on the commit the testing
> > image was was built from.
> >
> > The idea is to merge over _just_ patches, which fix essential / critical
> > stuff, into the "testing" branch while the merge window is open.
> >
> > That way the "master"-branch will stay open for enhancements and new
> > features, while we can ensure the testing-branch will not get
> > accidentally broken but stabilized for the actual release image.
>
>
> hmm... I think we don't need "testing" branch, since we have the VERSIONS file[1].
> all the commit should goto "master" branch and "master" should always ready for
> release,
>
> AFAIK, it's always create a tag like 2010-11-10-rc1 for testing etc. and some project
> create a "next" branch for gathers all commits to be delayed after release.
> since there is no >30 people commit to openwrt-xburst.git we don't need the -rc1 or "next"
> either.
I still think having the testing branch is a good idea, because
a) I do not want to force people _not_ committing new features, ideas,
packages, etc. because the branch is "freezed" for the actual release.
b) However I also do not want to fix stuff which got committed during
the merge-window which may lead into regressions - I want to concentrate
on fixing critical bugs during this merge-window
I think that's the most elegant way.
>
> so let's just keep using "master" branch and VERSIONS file. what do you think?
I still would like to stick to the idea of having an own branch during
the merge window...
>
>
> BTW:
> we definitely need those two commit in "master" (that's why I advice master branch as release branch :)
> *[linux] support increase/decrease in screen brightness
> *[config.full_system] add gcc-mips, fixed in openwrt package: 8dbf61c, tested in build hosts
I don't get the actual argument :)
Why do we definitely need those 2 commits in this release? They do not
seem to be critical to me - gcc-mips did not build on the buildhost.
It probably got fixed now (I saw the commit which removed the BROKEN
flag), so it'll get most likely into the next release image.
The last image which got released was quite buggy (my fault, change to
uclibc 0.9.32, etc.) - so I do want to have a stable image released this
time, where fixed bugs is more important to me than new
features/packages added (which could be added to the next image release
which may come quite soon, as we have a stable basis now again).
Well, that's just my very own opinion:
If most you think, these are _must have_ commits, merge (cherry-pick)
them over from "master" to "testing", but prepare for blaming if they're
going to break anything ;)
>
>
>
> [1]http://downloads.qi-hardware.com/software/images/NanoNote/Ben/testing/2010-11-07/VERSIONS
>
> >
> >
> > A summarized change log of major improvements / changes:
> >
> > - heavily restructured git repository to make it more easy to track
> > changes with upstream
> > - change rootfs size from 256MB to 512MB
> > - switch back to uclibc 0.9.30.1, since we experienced issues with
> > 0.9.32 which are going to be investigated
> > - all used toolkits (sdl, gtk2, qt4) are working again
> > - lot's of packages - within the openwrt-packages as well as in the
> > qi-packages repository - have been updated to fit more the needs of
> > NanoNote users
>
> new packages and features:
>
> CONFIG_BUSYBOX_CONFIG_FEATURE_ASSUME_UNICODE=y
> CONFIG_BUSYBOX_CONFIG_FEATURE_VI_8BIT=y
> CONFIG_BUSYBOX_CONFIG_STAT=y
> CONFIG_BUSYBOX_CONFIG_HOSTNAME=y
>
> CONFIG_PACKAGE_gforth=y
> CONFIG_PACKAGE_kexec-tools=y (I like this :)
> CONFIG_PACKAGE_picoc=y
> CONFIG_PACKAGE_jbig2dec=y
> CONFIG_PACKAGE_openjpeg=y
> CONFIG_PACKAGE_unifont=y
> CONFIG_PACKAGE_cmdpad=y
> CONFIG_PACKAGE_ghostscript=y
> CONFIG_PACKAGE_hwclock=y
> CONFIG_PACKAGE_io=y
> CONFIG_PACKAGE_mupdf-tools=y
> CONFIG_PACKAGE_binutils=y
> CONFIG_PACKAGE_libbfd=y
> CONFIG_PACKAGE_objdump=y
> CONFIG_PACKAGE_erlang=y
> CONFIG_PACKAGE_jbofihe=y
> CONFIG_PACKAGE_lojban-wordlists=y
> CONFIG_PACKAGE_makfa=y
> CONFIG_PACKAGE_fbgs=y
> CONFIG_PACKAGE_fbi=y
> CONFIG_PACKAGE_ben-cyrillic=m
> (I like this, hope more package like this come out :)
> CONFIG_PACKAGE_nupdf=y
>
> (using ./scripts/feeds search PACKAGE_NAME for get some package info)
>
>
> > - lot's of new and fixed packages have been added to the default config
> > and therewith image
> > - the toolchain and SDK are now built by default to simplify
> > development and cross-compiling / -linking of software
> >
>
> some addition:
> - we have add data/ for keeping NanoNote special files.
>
> conf/
> ├── config.full_system #the .config file for our release
> ├── config.minimal #very very small rootfs, only have base package. no gtk ...
> ├── config.xbboot #this is for create zImage + initramfs image.
> #which is for reflash,testing kernel or for FUN :)
> ├── config.xbboot.README
> └── feeds.conf #NanoNote default feeds.conf, always cp it to openwrt ROOT folder
> scripts/
> ├── build #a scripts build NanoNote images, will keep build log, versions, etc.
> └── reflash_ben.sh #the openwrt release reflash scripts file.
> files/ #additions files in openwrt rootfs.
>
>
> Hi Mirko
> I have create a daily building (every two days) of openwrt:
> http://fidelio.qi-hardware.com/~xiangfu/compile-log/
>
> the next build will trigger at 2010-11-11, if everything compile fine.
> I advice use 2010-11-11 as the next release.
> another thing is I am thinking of should we include the minimal rootfs[2] and zImage[3] to next release.
> the zImage works pretty good now. so maybe it's the time to include the zImage,
> minimal rootfs, I am not sure.
>
> [2]http://fidelio.qi-hardware.com/~xiangfu/compile-log/image-minimal-11092010-2202/openwrt-xburst-qi_lb60-root.ubi
> [3]http://fidelio.qi-hardware.com/~xiangfu/compile-log/image-xbboot-11092010-2252/openwrt-xburst-qi_lb60-zImage.bin
>
>
> > That's just the major points - lot's of (other) fixes have been merged
> > into the image, as well as lot's of new software ports.
> >
> > For more information please review the git log (since the restructuring,
> > to get the full picture, relevant commits are split into the master- as
> > well as in the history-branch).
> >
> > Happy hacking!
> >
> > Cheers
> >
> > mirko
> >
> >
> > [1]
> > http://downloads.qi-hardware.com/software/images/NanoNote/Ben/testing/2010-11-07/
> >
> >
>
Thanks for adding so much more details! :)
Cheers
mirko
>
> --
> Best Regards
> Xiangfu
> -- Qi RSS feed, http://en.qi-hardware.com/feed/rss20.xml --
>
> _______________________________________________
> Qi Hardware Discussion List
> Mail to list (members only): discussion at lists.en.qi-hardware.com
> Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
--
This email address is used for mailinglist purposes only.
Non-mailinglist emails will be dropped automatically.
If you want to get in contact with me personally, please mail to:
mirko.vogt <at> nanl <dot> de
More information about the discussion
mailing list