Salixmeetfeb2012

From Salix OS
Jump to: navigation, search

1st Salix Online Meeting (29 Jan 2012)

Proposed agenda

* 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, ISO tester, greek translations, salix-codecs-installer maintainer
  • 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, translations of the start up guide in Greek
  • kerd + ax : Salix Fluxbox edition
  • akuna : live cd, live tools, server, salixos.org email maintainer
  • jrd : live cd, packages, maintaining salix.enialis.net mirror. translations, helping on live tools
  • pwatk : not much at the moment
  • tsuren : documentations
  • 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
  • Maintain documentation in Wikipedia about the distro.

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 election 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.
  • Recommend packagers to use VM for packaging (only advice, no mandatory).

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, a simple script could do it if necessary
  5. Build-time deps: no interest, already done (normally) for packages in slapt-src
  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 partitioning, help having a crypt setup and the like…: of interest (pwatk worked on cryptsetup and guth wants to do it too, see bellow)

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 updates/patches 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?
  • Possibility to migrate from Subversion to a DVCS, like git, mercurial or bazaar?