Difference between revisions of "Salixmeetfeb2012"
Line 38: | Line 38: | ||
=== Meeting minutes === | === Meeting minutes === | ||
− | + | '''the need of a salix-dev mailing list: private or not ?''' | |
− | + | ||
− | + | * There is no need as the ML does not have so many people, and there is nothing to hide in Salix... | |
− | + | ||
− | + | '''what are you working on ?''' | |
+ | * gapan : project leader, working on almost everything : e.g. packages, promoting Salix OS, creation of special Salix edition for a Greek magazine, standard Salix xfce ISO, care taker of Salix repository | ||
− | + | * christian : maintaining packages, no work on lxde at the moment | |
− | + | * fredg : working on packages.salixos.org -> http://packages.salixos.org/ | |
− | + | * djemos : salix kde edition and salix kde live (beta 1 is out), some packages for current, and testing new kde, translation of the start up guide in Greek | |
− | + | * kerd + ax : Salix fluxbox edition | |
− | + | * akuna : live cd, live tools, server, | |
− | + | * jrd : live cd, packages, maintaining sali.enialis.net mirror. translations, helping on live tools | |
− | + | * pwatk : not much at the moment | |
− | + | * tsuren : docs | |
− | Shifting the branding of akuna's live tools from simplyNux to Salix, so that others from Salix will be able to work on them freely in the future. | + | * shador : Currently, nothing actively, but some ideas (some still very vague and unsure about): |
− | Recommended for packagers to use VM for packaging. | + | |
+ | |||
+ | '''how can we work better with the slackware team ? how to best get in touch with them when there's a upstream problem?''' | ||
+ | * We contact them as needed. | ||
+ | |||
+ | '''our strategy for the future (what do we want to achieve? by which means?)''' | ||
+ | |||
+ | *polishing things up. i.e. good doc, more functionality on the livetools | ||
+ | *Improving existing tools we have in Salix | ||
+ | |||
+ | ''' when do we drop support for older Salix versions?''' | ||
+ | *When Slackware does. But, packages for older versions will get less support. | ||
+ | *When support is out, we make an announcement on the Salix OS front page | ||
+ | |||
+ | '''elections''' | ||
+ | *To elect the project leader for Salix. This is to foster the team spirit, and to prevent the continuation of the project without a hiccup. | ||
+ | *for the new election, after all the livecds are out and before the new upcoming release | ||
+ | *akuna will take care of the process | ||
+ | |||
+ | |||
+ | |||
+ | '''Future project ideas and recommendations''' | ||
+ | * Shifting the branding of akuna's live tools from simplyNux to Salix, so that others from Salix will be able to work on them freely in the future. | ||
+ | * Recommended for packagers to use VM for packaging. | ||
− | |||
Shador: | Shador: | ||
− | + | 1) (U)EFI support (grub2-efi, efibootmgr and if necessary an efi kernel) : of interest | |
− | + | 2) a grub2 (+ syslinux chainloading) based easy-to-use solution to install multiple live cds to one usb (primarily Salix, but possibly others for which it could be 3) less straigtforward) : of interest | |
− | + | 3) improvements to SLKBUILD (early arch (usable in source array then), : yes, it would be a good idea | |
− | + | 4) multi packages?, : no interest by the team | |
− | + | 5) build time deps?, : no interest | |
− | + | 6) improvements to metagen.sh (-> speed) : optional, would be of interest | |
− | + | 7) simplify/ speed-up repository management (upgrade, addition, upload...), while keeping control with the admin : no interest | |
JRD | JRD | ||
Line 90: | Line 111: | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | The following topics were postponed for the next meeting. | + | '''The following topics were postponed for the next meeting.''' |
* upgrade package in stable: when ? which one can bypass the rules ? | * upgrade package in stable: when ? which one can bypass the rules ? |
Revision as of 21:57, 29 January 2012
1st Salix Online Meeting (29 Jan 2012)
What do you want to discuss ?
* the need of a salix-dev mailing list: private or not ? * what are you working on ? * upgrade package in stable: when ? which one can bypass the rules ? * posibility to migrate from svn to a DVCS like git or mercurial or bazaar ? * http://www.pocock.com.au/migrating-a-sourceforge-project-from-subversion-to-git * http://www.infoq.com/articles/dvcs-guide * http://sourceforge.net/apps/trac/sourceforge/wiki/Git * http://alx.github.com/gitbook/index.html * http://wiki.bazaar.canonical.com/ForeignBranches/Subversion?action=show&redirect=BzrForeignBranches%2FSubversion#id50 * http://wiki.bazaar.canonical.com/BzrMigration * how can we work better with the slackware team ? how to best get in touch with them when there's a upstream problem? * our strategy for the future (what do we want to achieve? by which means?) * when do we drop support for older Salix versions? * elections * How to attract new contributors? For documentation, flavors and translation it seems to work fine. But for packages more would be useful. Mentoring? Announcement? 102 ab 1 ax 14 cd 22 cp 57 dj 2 fb 29 fg 543 gv 25 lm 13 mb 1 plb 46 pw 10 rl 1 ro 76 tm 10 tt 14 vc 17
Meeting minutes
the need of a salix-dev mailing list: private or not ?
- There is no need as the ML does not have so many people, and there is nothing to hide in Salix...
what are you working on ?
- gapan : project leader, working on almost everything : e.g. packages, promoting Salix OS, creation of special Salix edition for a Greek magazine, standard Salix xfce ISO, care taker of Salix repository
- christian : maintaining packages, no work on lxde at the moment
- fredg : working on packages.salixos.org -> http://packages.salixos.org/
- djemos : salix kde edition and salix kde live (beta 1 is out), some packages for current, and testing new kde, translation of the start up guide in Greek
- kerd + ax : Salix fluxbox edition
- akuna : live cd, live tools, server,
- jrd : live cd, packages, maintaining sali.enialis.net mirror. translations, helping on live tools
- pwatk : not much at the moment
- tsuren : docs
- shador : Currently, nothing actively, but some ideas (some still very vague and unsure about):
how can we work better with the slackware team ? how to best get in touch with them when there's a upstream problem?
- We contact them as needed.
our strategy for the future (what do we want to achieve? by which means?)
- polishing things up. i.e. good doc, more functionality on the livetools
- Improving existing tools we have in Salix
when do we drop support for older Salix versions?
- When Slackware does. But, packages for older versions will get less support.
- When support is out, we make an announcement on the Salix OS front page
elections
- To elect the project leader for Salix. This is to foster the team spirit, and to prevent the continuation of the project without a hiccup.
- for the new election, after all the livecds are out and before the new upcoming release
- akuna will take care of the process
Future project ideas and recommendations
- Shifting the branding of akuna's live tools from simplyNux to Salix, so that others from Salix will be able to work on them freely in the future.
- Recommended for packagers to use VM for packaging.
Shador: 1) (U)EFI support (grub2-efi, efibootmgr and if necessary an efi kernel) : of interest 2) a grub2 (+ syslinux chainloading) based easy-to-use solution to install multiple live cds to one usb (primarily Salix, but possibly others for which it could be 3) less straigtforward) : of interest 3) improvements to SLKBUILD (early arch (usable in source array then), : yes, it would be a good idea 4) multi packages?, : no interest by the team 5) build time deps?, : no interest 6) improvements to metagen.sh (-> speed) : optional, would be of interest 7) simplify/ speed-up repository management (upgrade, addition, upload...), while keeping control with the admin : no interest
JRD
1) a theme manager: A real Theme manager. Something to help anyone to install a theme (GTK, icon, font, xfwm4, kwin, ...). Now, it's really complicated to install some for a non-technical guy, and it's the clue to success : if possible, but may be very difficult to do
2) A Salix upgrade manager. A soft to check if a new version is available and help to migrate if wanted : not supported in general
3) LiveClone and LiveInstaller improvements. LiveClone is not finished right now. LiveInstaller should simplify more partitionning, help having a crypt setup and the like.. : of interest
guth: 1) cryptsetup/luks/... support (full disk encryption), it's more and more "common" : supported and patches welcome.
2) having some way to provide quick update/patchs for standard packages on security issues : Salix update notifier does this already
3) think about arm release (more and more tablets/phone/laptops) : depends on what are available for compiling packages, and available resources
The following topics were postponed for the next meeting.
* upgrade package in stable: when ? which one can bypass the rules ?
* How to attract new contributors? For documentation, flavors and translation it seems to work fine. But for packages more would be useful. Mentoring? Announcement?
* posibility to migrate from svn to a DVCS like git or mercurial or bazaar ?