Updated README.md

< consider sping loaded folders
> consider srping loaded folders

Fixed.md

@@ -0,0 +1,51 @@
+Fixed Issues since Linux Mint 19.1 BETA
+
+All editions
+------------
+
+xed menu item not translated
+https://github.com/linuxmint/mint-19.1-beta/issues?q=is%3Aissue+is%3Aclosed
+
+mintsources: Add kabyle support
+update translations
+FF in live repo
+FF support for dark themes
+in lightdm, onboard doesn't work (empty area)
+
+bird in coast wallpaper
+
+Cinnamon Edition
+----------------
+
+wacom rotates with display
+touchscreen doesn't rotate with display
+crash when using kazam.
+After you move the bottom panel to a side, you need to restart Cinnamon because the menu session icons get lost: http://imgur.com/r3gotjal.png
+In System settings, when I click on "Input method", the "Language settings" open instead! When clicking on "Input method" in the start menu, it works. Japanese also works fine.
+calendar text is too small (it's the same size as before, we made the status applets smaller to compensate)
+The notification area icons will look more elegant if is set to 22 px. by default (even so, will be bigger than the defaults on Linux Mint 19.0).
+Start menu doesn't auto-shrink – too much space between the lock and favorites button and unused space under "Places".
+in settings, "window list" applet (when switched to modern) looks as if it's added and broken.
+gwl: Ctrl to launch new instance
+gwl: middle-click on empty pinned group wants to kill something
+mint-y gwl theme broken for top/right/left panels
+gwl:
+  different system settings modules (say colors and date-time) get grouped together, despite having a different icon
+  mint-x + panel on top -> all groups active
+  remove dnd option to pin
+  dnd on pin should be persistent
+  vertical thumbs, restart cinnamon -> wrong number of thumbs
+  add shift click
+
+center-align applet text (test with %n in clock applet)
+The ‘system-shutdown’, ‘ system-log-out’ and ‘system-lock-screen’ icons don’t scale properly on big panels (50+). Instead of 48px icons they are upscaled (blurry) 32px.
+When I right click on the desktop and select ‘Customize’, my icons are automatically resorted.
+
+MATE Edition
+------------
+
+Xfce Edition
+------------
+
+Manual steps for upgraders
+--------------------------

New.md

@@ -0,0 +1,14 @@
+New bug reports in Linux Mint 19.2 BETA
+
+All editions
+------------
+
+Cinnamon Edition
+----------------
+
+MATE Edition
+------------
+
+Xfce Edition
+------------
+

Postponed.md

@@ -0,0 +1,104 @@
+Improvements selected for the future
+=====================================
+
+    internet/network:
+        remove modemmanager?
+
+    mintupdate:
+        creates objects with wrong ownership. See https://github.com/linuxmint/mintupdate/issues/169
+
+    mintupload:
+        ftps support
+
+Cinnamon
+--------
+
+    hidpi and display settings:
+        System Settings > Display won’t let me set the one on the right as primary. The “Set as Primary” button is grayed. It’s connected as DVI. The other monitor’s “Set as Primary” is not grayed. It’s connected as VGA. This is related to a very longstanding issue of Mint always opening dialogs on the left (wrong) monitor
+
+    networking:
+        Network setting does not let me to set Proxy.. The button “set system wide” is not there.
+        network applet https://git.gnome.org/browse/gnome-control-center/commit/panels/network?id=63756458b2de0d730763cc2acbd510659e4d00a5
+
+    nemo:
+        Prefs > Display > Icon Caption > first option SIZE, and Prefs > Preview > Folders > options NEVER ---> results in "–" showing under directories (tested in icon view).
+        if I press ALT+F2 and then enter “nemo ftp://ftp.mydomain.xyz” to access to my personal ftp server trough nemo, I’ll get a request of username and password: it’s OK. The problem is that if I select the option to remember forever the username and password, it will not have effect: if I reboot Linux Mint, the next time I’ll try to access my ftp trough nemo I’ll get the request of username e password. So… nemo doesn’t remember my credentials… it’s frustrating.
+        Entering the folder of long name , the path disappeared screen capture 1) it shows a folder of longname https://dl.dropboxusercontent.com/u/54450962/%EC%8A%A4%ED%81%AC%EB%A6%B0%EC%83%B7%2C%202013-11-18%2002%3A18%3A19.png screen capture 2) entering the long name folder , meeting disappeared folder path of long name folder https://dl.dropboxusercontent.com/u/54450962/%EC%8A%A4%ED%81%AC%EB%A6%B0%EC%83%B7%2C%202013-11-18%2002%3A18%3A34.png screen capture 3) But Actually It was still dsiplayed at max window https://dl.dropboxusercontent.com/u/54450962/%EC%8A%A4%ED%81%AC%EB%A6%B0%EC%83%B7%2C%202013-11-18%2002%3A19%3A13.png
+        Create a thumbnailer in usr/share/thumbnailers for MimeType inode/directory – when you try to run Nemo, it crashes with the error:  (nemo:9078): CinnamonDesktop-WARNING **: Error reading from file:///home/simon/Desktop: Error reading from file descriptor: Is a directory Installing cover-thumbnailer is an easy way to reproduce it.
+        nemo-preview (not installed by default), doesn’t work: http://pastebin.com/Uaci0mzC
+        1. Open nemo (unminimised)  2. Copy some files so that the transfer window is present 3. Open another program (unminimised) and in front of nemo such as firefox 4. If the transfer window is open (maximised) in front of the other program (firefox for example) and you click to minimise the transfer window, nemo will automatically pop up in front of the other program. Not a major bug but annoying from a window management point of view.
+        When trying to connect my ext.hard drive via smb when double clicking on the globe icon (workgroup) nemo closes down
+        If I disable the desktop icons with the first checkbox in cinnamon-settings the right mousebutton does not work on the desktop anymore…
+        right-click Run/Open with blah in nemo, on executable files
+        Feature request: if I create a launcher on my desktop, I can select an icon for it (with preview)… instead, if a modify a launcher in the menu with the “menu editor”, I can select a different icon but without preview. Can you please add the preview feature?
+        if I launch from a bash script nemo to open an ftp server more than one time, with a command such as “nemo ftp://ftp.xxx.xyz“, I can get a duplicate icon on my desktop, see screenshot: https://dl.dropboxusercontent.com/u/573922/Schermata%20del%202013-11-21%2012%3A25%3A31.png
+        If you plug in a USB, it auto mounts in a location on the desktop but if you unplug it, plug in another, and re-insert the first, the desktop icons overlap each other. I've noticed a similar issue in previous Mint releases. It would be great if the icons could auto position.
+        small bug in all Linux Mint Cinnamon editions (maybe with Nemo). When I drag and drop some file(s) on an archive , my expectation is the files being added to it , but instead of that an error message pops out : “An error occurred while adding files to the archive. You can’t add an archive to itself.” . The Mate edition does not have this problem
+        when no panels are present -> right-click the desktop -> Add a panel
+        If Nemo is open with 2 folder-panes the user can switch between both panes with F6, that is fine, if one uses the file-manager with keyboard only. The problem is, that F6 only works at once, if you have set Nemo to open with 2 panes. If Nemo opens with 1 pane (default setting) and the second pane gets opened via F3 (or menu), pressing F6 does at first nothing – no reaction at all. You can either click the second pane with the mouse (what is against a keyboard-only usage) or you have to navigate in the first pane anywhere (e.g. by pressing backspace), only after that F6 is reacting
+        nemo: can no longer handle desktop in root session.
+
+    window management:
+        expo: set overview mode to true by default
+        integrate workspace management in nemo, panel, window-list, applet, muffin, settings
+        Add common tiling options to window list context menu - Show Windows Side by Side, Cascade, Show windows stacked
+
+    settings:
+        Problem with the width of some configuration windows: E. G. with the configuration window for window list applet.
+        cinnamon-settings: The search box in System Settings displays “Search…” next to the magnifier.
+        spices: removing extensions, themes, desklets, applets is only possible using right click (maybe it would be better to have button for that in future relases)
+        spices: If I select the radio box to choose an applet and then I’ll click the button to install it, the applet is installed but it’s not active: maybe a new user expects to have it immediately in the panel after the download… in fact forcing the user to come back in the list of the installed applet to enable the just downloaded applet is not user friendly, in my opinion.
+        keyboard: allow adding duplicate key combination for Cinnamon “Toggle Scale” and “Toggle Expo” (found these, didn’t go through all actions, most of them ok)
+        mouse/touchpad: an option to change the mouse scroll speed for the middle wheel in Mouse and Touchpad preferences
+        cinnamon-settings-users: Creating a user without password (stupid but nothing prevents it): impossible for that user to set one himself in Account Details.
+        cinnamon-settings-users: In the “Users and Groups”, when on “Groups” tab, it could be great to have a way to see the members of a selected group and add new members to the group as well. Currently, we can only edit the group name…
+        backgrounds: get more brackgrounds (find a way to make it easy to install more backgrounds)
+        Is the speed (not acceleration) of the mouse pointer finally changable via the settings? This did not work for years now
+
+    applets:
+        menu: bring back category hover delay option
+        menu: doesn't listen to menu changes outside /usr/share/applications? install shotwell for instance (uses /usr/share/menu)
+        menu: keywords (for searching) aren't l10n'd
+        menu: Even after setting org.cinnamon.desktop.lockdown.disable-lock-screen to true, the lock button still appears on cinnamon menu applet...
+        menu: When creating a new menu item the icon does not appear. It is ok in the menu editor.
+        menu: recent icon is different than in nemo sidebar
+        sound: I have a problem when i start Spotify from the sound icon Cinnamon crash. When i open it in the menu it works. I didnt have that problem with Mint 18.0
+        sound: align close/raise buttons to the right
+        show-desktop: add the ability to DND to desktop by hovering with a file on the applet.
+
+    screensaver:
+        If the display for the time gets disabled, also the absence message does not get shown. I think, both should be independent from each other.
+
+    other:
+        screenshot filenames aren't handy (Screenshot from 2014-02-17 14:46:32.png)
+
+MATE
+----
+    hard to resize window or to grab border
+    When panel is at the top, notifications show on top of it. https://dl.dropboxusercontent.com/u/54450962/%ED%99%94%EB%A9%B4-5.png
+    Add sound effects like in Cinnamon
+    The MATE user admin program (mate-users-admin), when setting a user’s type to “Administrative”, does not add the user to the “sudo” group. The workaround is to explicitly add the user to the sudo group
+    ‘mate-screensaver’ still as flaky as it was in lm15 MATE 64-bit. Set to ‘Lock screen when screensaver is active’ sometimes upon resume after suspend I get a prompt for my password, other times NOT.
+    MPRIS support
+    caja: If you set a black wallpaper, the text below desktop icons becomes unvisible after reboot or logout and login.
+    caja: dng and raw images thumbnails in caja
+    caja: renaming a file produces a black border
+    add context menu support for CSD headerbars in Marco.
+    make MATE screensaver see OnlyShowIn=GNOME xscreensavers (/usr/share/applications/screensavers/*)
+
+LMDE
+----
+    Localization of the installer slideshow
+    caja: it looks like caja briefly dies at session start just before reappearing again
+    missing plymouth-text theme
+    Marco doesn't provide WM context menu options for CSD apps
+    iphones can't be mounted (need more info on how to pull this off and with which versions of iOS?)
+    Set the default debian repository to http.debian.net/debian instead of ftp.us.debian.org, which results in better performance for all users outside of the US
+    missing slovak language pack (something like thunderbird-l10n-sk) for Thunderbird mail client
+    rfkill provides upstart config, but not init.d.. as a result RFKILL state isn't stored/restored
+    integrity check warns about malformed header
+    /.config/pulse present (found on MATE i386 ISO)
+    gnome-power-statistics.desktop doesn't show up in Cinnamon
+    bashrc: # colored GCC warnings and errors --> export GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01' (won't work until gcc 4.9)
+    history and completion in bashrc
+    consider activating http://backports.debian.org/changes/jessie-backports.html

README.md

@@ -1,56 +1,242 @@
-MDM
----
-    
-    - Performance improvements
-    - HTML Greeter: When there's a lot of languages the whole theme itself gets a scrollbar instead of just the language menu
-    - Allow password-only login (for single user) and/or remember last user
+Trello Boards
+=============
 
-Mint 16
--------
+Linux Mint 19.3: https://trello.com/b/5OfcpmZi/linux-mint-193
 
-    - UI Improvements for Software Management
-    - Consider removing splash screen in mintinstall
-    - update ubiquity-slideshow (mentions vlc, giver, pdf printer etc..)
-    - Review mintupdate design
-    - Review mintbackup design
-    - Consider default installation using separate home/root partitions - figure a nice formula, root must be minimum up to xx%, remaining home.  We could possibly offer a pseudo-upgrade path which installs a fresh system, but also reinstalls existing programs and user(s) during installation.
+Maintenance
+===========
 
-Cinnamon 2.0
-------------
+    update mirrors
+    update translations for installation guide
+    advertise community website in get involved page
+    add sum to download page directly
 
-    - Review any remaining GNOME backend components and dependencies
-    - Factorize translations into cinnamon-translations
-    - Implement a non-accelerated fallback GTK panel and session
-    - Consider shipping our own version of gjs (as opposed to using the system one and in an effort to ease backports)    
-    - Convert all system applets, desklets to use settings api
-    - Calendar events - similar to KDE's implementation [lockjs] 
-    - Upgrade Menu applet with mintMenu features (highlight new apps, install/remove apps, search the Web) [clem]
-    - Use bumpmaps, make them optional, make compositing optional if possible
-    - Notifications: try to identify notifications with interactions, and make them stick around longer/until dismissed (i.e. bluetooth pairing)
-    - Notifications: Provide dismiss button when notification click triggers and action other than dismiss
-    - Settings API: Implement object/custom interface
-    
-    NEW APPLETS
-    
-    - email notifier (imap/pop)
-    - Pulse-like RSS reader
-    
-    NEW DESKLETS
-    
-    - System monitor
+Linux Mint 20
+=============
 
-Nemo 2.0
---------
+    selection:
+        open-vm-tools?
+        libinput-gestures?
 
-    - File preview
-    - Add devices to MoveTo/CopyTo context menu
-    - When the breadcrumb is full, and you use the back button to show the start of it.. the forward button doesn't do anything so you can't get back to the end. Also, the last two items on the first page are not clickable.
-    - Windows-like 2-click renaming.  Click a file name.  Click on same file name again (but not double-click) - instigates rename action.
-    - Removable device trash management.
+    artwork:
+        theme LO
+        remove all sound, power, network icons in mint-y-icons/panel/ (needs patches in Xfce and MATE to stop using fullcolor in panel (for MATE power manager) and notifications)
+        mint-y-icons: improve computer icon
 
-MintStick
----------
+    mate:
+        Ctrl+alt+backspace support
 
-    - Make a 'clean' option - dd really hoses up USB sticks for use afterward.  For the uninitiated it's a pain to 'blank' them back out.  Make this a one-click operation
+    xapp:
+        scroll events for xappstatusicon
+        switch rhythmbox icon to xappstatusicon
+
+    cinnamon:
+        cs_info: Show a distro logo
+        remove send-by-email nemo action
 
 
+    mate:
+        theme settings
+            folder icons too big
+            mint-x background too dark
+        hidpi
+            titlebar buttons are blurry
+
+    apturl doesn't refresh
+
+
+    system:
+        add CLI support for foreign packages list/removal/downgrade
+
+    artwork:
+        new website theme
+        use dark-variants for dark apps (xplayer..etc) in Mint-Y (needs fixes in mint-themes and marco: https://github.com/mate-desktop/marco/pull/530)
+        icons
+            grey-on-grey icons (many in cinnamon-settings)
+            review color variations in mint-y
+            add missing yellow icons
+        update MATE metathemes
+        consider manjaro mouse cursor?
+
+    mintupdate:
+        safeguard against package removals (for instance, don't let users perform updates which would remove sensitive packages).
+
+    mintlocale:
+        remove language packs and packages when a language is removed
+
+    software:
+        Replace Hexchat
+        Replace Qt5Settings? (not hidpi compatible)
+
+    drawing:
+        implement zoom
+        simplify rotation, flip..
+
+    timeshift:
+        show a try when a save is ongoing
+        let user cancel save
+
+
+Ideas - Todos
+==============
+
+    https/apt:
+        add https support for packages.linuxmint.com
+        switch to https by default?
+        add feature in mintsources to list https mirrors only?
+
+    favorite/starred documents (nemo, xapps)
+
+    fingerprint reader -> slick-greeter support
+    https://askubuntu.com/questions/46501/why-can-other-users-see-the-files-in-my-home-folder
+
+    artwork:
+        revamp sound theme?
+        cinnamon
+            text-size to be configurable in panel zones?
+            cinnamon/gtk mint-y: tooltips don't match theme
+
+    help
+        rtd security guide
+
+    mate:
+        fix terminal apps not running (gnome-terminal --> mate-terminal)
+
+    mintupdate:
+        remember sorting of updates
+
+    port mintstick to python3
+
+    artwork
+        add dark variant support to Mint-Y (needs fixes in Caja/marco)
+        cursor theme?
+        sound theme?
+        bump resolution of branded backgrounds
+
+    slick
+        would be nice to show release number
+
+    xapps/cinnamon/nemo:
+        don't ship icons with generic names in /usr/share/hicolor. All icons should be prefixed (cs-, xapp-, nemo-..etc..) so they don't conflict with other packages
+        cinnamon-settings should use gsettingswidgets from xapp and retire its own
+
+    cinnamon
+        - spices: Add a button to install a manually downloaded spice
+        gtk windows
+        - When in tablet mode (that is, the screen is rotated and covering the keyboard) the RotateWindows key doesn't work anymore... It just does nothing...
+        - menu-editor: picking a pixmap in /usr/share/pixmaps for a category results in no icon being shown in the menu.
+        - Unable to unlock the screensaver via LDAP with libpam-ldap and nscd packages installed pointing to an openldap server.
+        - csd power: https://github.com/GNOME/gnome-settings-daemon/commit/82af1816f32a26f28027ea7ce8edc79cd833bc76
+        - in HiDPI, keyboard applet, the flags is not the proper size. Hovering it fixes it.
+        - mounted volume applet: no notification when unmounting (as opposed to when it's done in nemo).
+        - gwl: Enable "application name" label. Open FF, open at least two browser tabs. Close FF. The label slides over the icon and doesn't disappear: https://kepkuldes.com/image/UoNHl
+
+    nemo
+        better navbar
+        consider spring loaded folders https://www.youtube.com/watch?v=gdUPrMjlLy8
+
+    xed:
+        option to remember past opened-documents
+
+LMDE 4
+======
+
+remove debian-multimedia
+add backports (priority 100)
+
+Roadmap
+=======
+
+    remove-apps
+        prevent removal of sensitive packets (for instance, removing GOA removes cinnamon)
+
+    main ideas
+        mintsystem apt downgrade
+
+    desktop-search:
+        local files
+        web engines
+        recent
+        apps
+        dictionary
+        translations
+
+    mate:
+        switch mozo for menulibre
+
+    mintreport:
+        dmesg errors
+        foreign packages if pinned by mint
+        wrong lsb info..etc.
+        slow boot sequence
+        slow shutdown sequence
+        systray support
+
+    mintupgrade
+        list/address foreign packages post-upgrade
+
+    implement an alarm clock
+
+    cinnamon:
+        cinnamon slow to start after boot --> delay execution of appsys/docinfo until the DE is loaded
+        CSD: support mouse wheel speed? Evdev scrolling distance?
+        preferences > keyboard > custom shortcuts. Used with a Spanish keyboard layout. Recorded: crtl+number and ctrl+Shift+number (e.g. ctrl+1 and ctrl+shift+1 = ctrl+!) they are recorded correctly. When using the shortcut the command defined in the shift combination is triggered with just ctrl+number (i.e. ctrl+1). The complete combination triggers nothing (i.e. ctrl+shift+1 does nothing) and the comand defined in ctrl+number can never be used. This worked in 17.3.
+        track/troubleshoot shutdown sequence (user should know what is happening when shutdown isn't immediate)
+        track/troubleshoot vsync, compositing, unredirected windows and policy
+        todo list applet/desklet
+        calendar events applet/desklet
+        multiple clocks https://github.com/simonwiles/cinnamon_applets
+        network applet: airplane mode (quick way to rfkill all)
+        nemo: retire computer:/// place (which is completely useless) or revamp it into something better
+        alt-tab and panel use icon provided by appsys, ignoring icon set by the application itself (example: a python window using widow.set_icon_name())
+        actions in panel launchers aren't translated if not present in .desktop file
+        When using Cinnamon bar at top, and secondary monitor with higher height than the main display, some apps like KDE Apps (Krita, Kdenlive) or Wine Based Apps (teamviewer) will display menus from toolbar in the wrong place. Being more specific: The menus will be displayed in the position that they should be displayed at main monitor, however in this case the window is maximized in the secondary monitor.
+        Is there any reason why there are two names for the same item, eg. "Trash" and "Rubbish Bin"? Would it be better to standardise on only one name?
+        add gnome-screenshot to panel, right-click and select "Take screenshot of a selected area". This runs gnome-screenshot -a.. it should work but it doesn't. Is it because of the panel launcher capturing the click event or something?
+
+    xapps
+        implement an app-sharing protocol to quickly move a document from one app to another
+
+        gestures support:
+            pinch:
+                zoom document in pix
+                zoom view in nemo
+
+            swipe:
+                previous/next document in pix
+
+            scroll:
+                sound-volume/seek in xplayer
+
+            click:
+                pause/resume in xplayer
+
+            double-click:
+                full-screen in xplayer
+                full-screen in xviewer
+
+        pix
+            doesn't rotate videos when playing them
+            vignettes should look better, and the same in all themes
+            support prefer-dark-themes
+            treeview in sidebar shows unecessary "(empty)" when dirs have no subdirs
+
+    artwork:
+        Tray icons are black with mint-y themes.
+        mint-x-icons: network status icons have a dark background in panel 33px and bigger (sound icon looks wrong in 41px and bigger).
+        mint-y The maximize/restore window control button doesn’t change visually between in maximized and restored state (default theme and Mint-Y-Dark)
+
+    system:
+        compiler optimization: consider optimizing compiled binaries for Cinnamon/Xapps
+
+    HiDPI support:
+        upstream apps using GTK2: Gimp, Hexchat, Tomboy.
+
+R&D
+===
+
+    system
+        consider enabling recommends
+
+    network discovery:
+        easy out-of-the-box interactions (messaging/presence/file-sharing) over the LAN

Triaged.md

@@ -0,0 +1,26 @@
+Triaged reports
+
+Not a bug
+---------
+
+
+Outside of the scope
+--------------------
+  bash: root prompt should be red -> we don't want to pin bash just for that
+
+Can't reproduce
+---------------
+  xplayer does not adapt to the size of the video being played. In Preferences, Display, there is the option 'Resize the window when opening a new movie'. By removing the check from that, you can resize the window manually. Otherwise on the sides and above or below the video, annoying black bands appear. --> it must depend on the video size and resolution. I can't reproduce it here.
+  Simple System monitor desklet "not working".
+
+lightdm:
+  DM appears briefly in automatic login mode
+
+hplip: I couldn’t do the installation of my HP Laserjet 1132MFP, following the installation of the hplip file from hp, in the final step it says that it requires a binary file, and enters in a loop that never ends.
+
+Booting from USB stick take pause for 10-30 seconds with no USB mouse light and no light on USB stick then light up boot continue. Pause for USB ports reset ?
+
+Upstream
+--------
+    Ubiquity: Wrong default French layout: https://github.com/linuxmint/linuxmint/issues/50
+

meetings/2013.04.15/log

@@ -1,431 +0,0 @@
-<clem> ok, this is the first time we do this so I hope it won't be too chaotic.
-<clem> what I'll do is list the topics first and then use the channel topic to write the topic we're currently talking about
-<clem> I'm also keeping a log of the channel for those who couldn't make it
-<clem> The topics are: 
-<d[-_-]b> will you also publish the results? eg somewhere on the mint page?
-<clem> yes
-<clem> - Triaging issues (new members, tags, how to do it)
-<clem> - 3.8 compatibility and the use of GNOME libs in general (where do we use them, can we replace them?)
-<clem> - Road to 1.8 (what's left, when do we freeze/release)
-<clem> - - Dev blog
-<clem> Before we get into these 4 topics, I'd like to take some time to answer any question people might have that doesn't fall within these topics
-* clem has changed the topic to: Current topic: Questions, non-listed topics
-<Garmine> clem: so.... can I panic now? :D
-<clem> yes :)
-* Garmine has no idea if that's good or not
-<Garmine> gonna check it in the guide... hold on :)
-<mtwebster> clem: this may fall under another category as well, but based on recent events, any plans on making cinnamon its own development entity, ala mate?
-* mtwebster feels like an interviewer
-<clem> mtwebster: no
-<glebihan> I think clem's answer on the "cinnnamon needs some love" thread was relatively clear on the matte
-<glebihan> r
-<clem> mtwebster: when the project was started it was started because it was needed by Mint, so as such it was similar to say mintinstall in scope
-<clem> mtwebster: of course it was likely to be used by other distributions so a certain commitment was made at the time
-<lockjs> clem: could you expand on the reasons why you don't want to do this? woud it be a possibility in the future?
-<clem> mtwebster: that's where we went further than unity for instance by guaranteeing cinnamon would be designed and compatible not only for Mint but for Linux in general
-<mtwebster> ok.. feelings evolve, so i thought i'd follow up one more time.  i'm good with that stance 100%
-<clem> mtwebster: with that said, it is the implementation of the Mint vision, and this is the benefit that comes out of forking Gnome, a huge effort went into it.. not to create something new, but to control our own desktop
-<clem> mtwebster: mintsources is a similar effort
-<clem> mtwebster: it helps to think of mintsources because it's smaller in scale and it wears the name "mint"
-<clem> mtwebster: mintsources is made to solve a problem Mint has, and in recognition of the fact that other distros would benefit from it, it supports Netrunner, SnowLinux, LMDE etc..
-<clem> mtwebster: there's the same commitment there in regards to branding and design, that this tool WILL work outside of Mint
-<d[-_-]b> so let's say someone wanted to use cinnamon for his/her distribution. what would be the recommended way? fork it? or get in contact to see if something has to be changed in the code?
-<clem> d[-_-]b: it really depends on what they wanted
-<clem> d[-_-]b: if they wanted cinnamon itself, we commit to them and consider it a bug if it doesn't work for them
-<clem> d[-_-]b: so they'd simply contact us and we'd work with them
-<clem> d[-_-]b: if they wanted a design that wasn't the same as cinnamon and their need wasn't what we need for Mint, we'd recommend a fork
-<d[-_-]b> maybe this should be stated in a popular place to avoid misunderstandings like with this cinnarch thing
-<clem> d[-_-]b: the reason we forked GNOME was because they were implementing something we didn't want to use, not because they wouldn't fix such or such issue
-<clem> d[-_-]b: with Cinnarch, the misinterpretation is to do with commitment
-<clem> d[-_-]b: I'm committed personally to call any problem Fedora or Arch, or any other distro has, a bug.
-<clem> d[-_-]b: and to consider it seriously and as a valid bug.
-<clem> d[-_-]b: where things are different is when it comes to prioritizing these bugs and the interpretation of how urgent they are.
-<clem> d[-_-]b: Not everyone here is a Mint dev, so I only speak for myself here. We're all busy and we have different priorities.
-<lockjs> clem: as Cinnamon is a part of Mint, will the next LTS or perhaps release of Mint re-introduce the core Linux Mint name, or will MATE continue to be given equal positioning(?)
-<clem> d[-_-]b: 3.8 support, which is a topic we'll talk about in this meeting is something we all want, but we don't all want it as badly.
-<clem> lockjs: MATE will continue to get equal consideration.
-<d[-_-]b> clem I see. so one could wrap it up like this: generally cinnamon should run for everybody, but if there are issues, mint issues will be priorized
-<clem> lockjs: a lot of users are still running GNOME 2, MATE is the DE they'd expect to see when they upgrade.
-<clem> lockjs: also, Cinnamon doesn't yet work as reliably as MATE on all computer specs or as well as MATE within the enterprise.
-<clem> d[-_-]b: no, but you can expect Mint devs to prioritize Mint issues of course.
-<clem> d[-_-]b: the same way leigh is more likely to work on Fedora issues than on the new calendar :)
-<d[-_-]b> sure. that's the way i meant it anyways. thank you
-<clem> d[-_-]b: his interest is with Fedora, mine with Mint, we both work on making Cinnamon better and we both agree on calling an issue an issue whether it affects our own distro or not.
-<lockjs> clem: thats fine, I was just wondering as some of the confusion (probably mine mostly) regarding the position / commitment to Cinnamon may have come from the equal waiting given to to MATE [although from a distribution perspective I can see and understand the reasoning]
-<clem> any other questions?
-<clem> ok, moving on to the first topic then..
-<clem> TOPIC: Triaging issues (new members, tags, how to do it)
-* clem has changed the topic to: Current topic: Triaging issues (new members, tags, how to do it)
-<mtwebster> clem: did you get dalcde's pastebin? he had some good input regarding this
-<clem> yes, I was about to paste it :)
-<mtwebster> ok
-<clem> dalcde couldn't make it to the meeting but he had some thoughts which he pastebin'd here http://pastebin.com/Shy7t7q7
-<clem> before I let everyone react to the topic... I'd like to mention what is and isn't possible with github
-<clem> the last time we checked, it wasn't possible to give somebody triaging rights without giving them merging rights
-<clem> this means we'll need to make it clear to people and trust them not to merge content in the git repositories
-<clem> the current state of things is that we've got a team set up with the following members: https://github.com/organizations/linuxmint/teams/122275
-<lockjs> clem: link 404's for me...
-<clem> oh.. it might be due to permission, I'll list the names here:
-<clem> clem, glebihan, mtwebster, albertP
-<clem> I'd like to include more people into this group personally
-<clem> there's a few people we worked with for a while now and which I think earned our trust when it comes to administrative permissions
-<glebihan> a little on the side, but are we committed to keep using github, or would switching to another tool be a possibility if we found something more adapted to the project's needs (no specific ideas in mind atm) ?
-<clem> I don't know.. personally it's not set in stone, I'd consider alternatives
-<clem> github provides a lot of handyness though :)
-<mtwebster> there are quite a few options if you want to do the hosting yourself
-<d[-_-]b> i think github is quite popular so as long as there is no urgent reason to swith i would prefer to stay there
-<clem> it also has momentum, it might be easier for people to contribute because we're using github
-<d[-_-]b> clem +1
-<mtwebster> i did check gitorious when we discussed the permissions thing a while back, it provided no better granularity
-<clem> we used it initially :)
-* clem tries not to laugh
-<glebihan> bgs :)
-<lockjs> Would it be possible to look at bug tracking systems that interface with GitHub's API's - Id be loath to move away entirely from Github for the reasons Clem mentioned
-<mtwebster> i'd prefer to keep it all together honestly
-<d[-_-]b> mtwebster +1
-<mtwebster> it's not perfect, but it's all in one location
-<clem> we also built our infra around github..
-<clem> silly little things like the IRC bot coming here and telling us about a pull or a commit :)
-<lockjs> that would be my pref, but is an option if the permissions are seen as a large issue
-<clem> or the automate build system
-<d[-_-]b> it will distract new people if there are too many tools they have to use
-<mtwebster> i send feedback to github quite often.  they have yet to enact anything i suggested, but there's hope
-<wrouesnel> urgh. gtk2 could really use a preload library to render with gtk2
-<wrouesnel> *gtk3
-<clem> ok, we're getting off-topic :)
-<clem> within github, we can't distinguish between merging and triaging rights
-<clem> I don't think we want specific issue-git-repos :)
-<clem> so we need to trust the people we work with, and in my opinion we can do so
-<glebihan> agreed
-<clem> I'd like to include autarkper and Lusito personally if that's ok with you glebihan 
-<clem> and assuming they're interested
-<d[-_-]b> agreed if the circle is well organized and not to big
-<glebihan> clem, ok with me
-<clem> I'd also be happy to include larst 
-<clem> he's not as involved in the code, and we had an incident a long time ago but he's been part of this for a long time now and he's eager to help
-<lockjs> ...apologies, I'm going to have to leave
-<d[-_-]b> bye
-<clem> no problem lockjs, I'll send around the log for this
-<clem> glebihan: what do you think?
-<mtwebster> clem: i would recommend dalcde as well
-<glebihan> clem, hmm, did larst ever do any code for cinnamon ?
-<clem> glebihan: peripheral, small fixes, not really
-<clem> glebihan: but he's enough understanding of the project to identify areas and he's experienced with community feedback
-<clem> mtwebster: +1
-<glebihan> clem, as far as cinnamon is concerned, I would consider dalcde a better fit than larst
-<d[-_-]b> this leads to the basic question of who will be considered to join the "inner circle"
-<autarkper> I would vote for rjanja
-<clem> d[-_-]b: the circle of trust? you're referring to "meet the parents"? :))
-<mtwebster> lol
-<d[-_-]b> clem no just didn't know how to call it^^
-<clem> see, there's a lot of good devs out there we've worked with a lot already
-<clem> I looked at the list of people here
-<clem> but if we look at the cinnamon repo, yes there's rjanja, cobinja..
-<autarkper> I was going to mention cobinja too
-<mtwebster> +1 rjanja and cobinja
-<glebihan> maybe we should start by this : how many people do we need/want ?
-<clem> what's important to me when it comes to triaging is trust, first and foremost, understanding of the project and presence
-<d[-_-]b> maybe it would be a way to introduce some kind of proposal system. someone would be proposed and if enough "inner circle guys" vote for him he would be invented to join
-<clem> d[-_-]b: that's decision making delegation, no way :)
-<glebihan> we're not a sorority :)
-<clem> glebihan: well there's 4 of us and it doesn't work
-<d[-_-]b> clem it's nothing other than you're doing it currently. only in an ordered way (i'm not saying everyone should be allowed to vote)
-<clem> d[-_-]b: it's very empirical how this all works
-<clem> d[-_-]b: I can look at autarkper and tell him what I liked and didn't like and how I trust him after a year of us working together
-<clem> d[-_-]b: I couldn't have told him what I expected in advance, the same way right now I seek approval from glebihan, tomorrow I'll probably ask more people as well
-<d[-_-]b> clem yes. i totally understand that. i only wondered how you will do it if you want to introduce someone new. i just think it would be easier if you had a central "team space"
-<clem> we do, but that's off-topic a bit
-<clem> I'd like to go back to the triaging team
-<clem> glebihan: autarkper, lusito, dalcde, rjanja, cobinja and a question mark on larst?
-<glebihan> clem, agreed
-<clem> glebihan: shall we talk about larst or do you want to do it in private?
-<clem> glebihan: to me it doesn't matter that he's not actively developing, it's his motivation and availability which makes him great here I think
-<glebihan> clem, might be better in private
-<clem> glebihan: ok
-* gargamel (gargamel@SpotChat-t3b.1ms.130.177.IP) has joined #linuxmint-dev
-<clem> ok, let's move on to the second question then... "how do we do triaging"
-<clem> dalcde's ideas are sound
-<clem> I'm adding an action on myself to talk to glebihan about larst, and to contact autarkper, lusito, dalcde, rjanja and cobinja about triaging to see if they're interested.
-<clem> as a reminder, dalcde ideas are posted at http://pastebin.com/Shy7t7q7
-<d[-_-]b> i think githab labels to filter would be nice
-<d[-_-]b> the easier the search, the faster you start fixing  
-<glebihan> I personally agree with most of dalcde's ideas, except on closing issues when a pull request is made (as long as it's not in master, I don't think the issue should be closed)
-<clem> d[-_-]b: yes, sometimes it's nice to fix things in bunch too
-<clem> d[-_-]b: or when you refactor something, to close multiple bugs
-<clem> glebihan: same here
-<clem> glebihan: I'd wait for that pull to be dealt with
-<d[-_-]b> agree on pull request. may lead to reopen the bug
-<clem> glebihan: not to mention github makes it easy to see related issues when you work on a merge or refuse a pull
-<clem> there's something missing here though...
-<clem> the state of the bug
-<clem> typical example is a bug report which you can't reproduce... and which you can't close
-<clem> it stays there for a while and no matter how many people look at it :)
-<clem> I'd like for devs to be able to quickly find "easy to fix" bugs
-<clem> as in, "confirmed bugs", that they can reproduce and fix
-<d[-_-]b> clem usually if the description is to low to reproduce it, it should either be closed or put to a low priority
-<clem> when the cause of a bug is known, that this bug is reproducible... any dev with a bit of time can make a difference and close it... so these should be easy to find
-<clem> yes but d[-_-]b, when you do triaging you do a bit of politics... you've got a user in front of you, and you can't tell him the priority is lowered because his bug is hard to work on
-<clem> so what usually happens is that bug slows you down
-<clem> and you can't close it because it's not invalid
-<glebihan> I think launchpad has a relatively approach on this
-<d[-_-]b> clem well not reproducible bugs won't be fixed anyway
-<clem> canonical deals with these on LP by not answering them and using the fact that they've been inactive too long
-<clem> personally I'd like to flag them "non-reproducible"
-<clem> that way they stay open, but out of the way, everyone's happy
-<glebihan> the fact that a bug isn't reproducible at some point doesn't mean noone will ever manage to reproduce it
-<d[-_-]b> ok. as long as this doesn't lead to to many flags, i'm ok with it
-<clem> now, rather than flagging the non-reproducible ones, I'd be in favor of marking "confirmed" the ones that are
-<d[-_-]b> this is even better, agreed
-<clem> take larst for instance, he can quickly find the ones that are valid and fixable
-<clem> you come after him, you work off a list of easy to fix bugs, in a couple of hours you make a big difference
-<d[-_-]b> little bit of topic: is there a way to get notified about bugs labeled with certain tags?
-<clem> no I don't think so
-<clem> if you look at MATE on github, that's what they do..
-<clem> they use two tags.. new features, and bug confirmed
-<clem> everything by default is a bug that isn't yet confirmed
-<clem> should we get started with these two? and eventually see if we need more?
-<clem> what do you guys think?
-<d[-_-]b> yes. but not more than ~5
-<glebihan> ok with me
-<clem> ok, looking at the clock, it's been an hour already...
-<clem> moving on to the next topic
-<clem> TOPIC: 3.8 compatibility and the use of GNOME libs in general (where do we use them, can we replace them?)
-<clem> before we move on to the technical aspect of 3.8 compatibility, does anyone want to talk about the political one?
-<d[-_-]b> maybe we should do that
-<clem> ok
-<clem> I felt like I said everything already but I'm happy to let anyone talk or seek clarification
-<d[-_-]b> dalcde seems to want that cinnarch could have stayed with cinnamon because cinnamon would support 3.8 faster
-<glebihan> well, that's not up to us, it's cinnarch's decision, I don't think there's any going back on this
-<clem> ok
-<clem> as I said before, I consider that incompatibility a valid bug
-<clem> where faidoc and I probably disagree is on me waking up in the morning and working on this before I fix more urgent problems I'm supposed to work on
-<d[-_-]b> so the main question is: how to handle this if there isn't enough man power to do it fast
-<Lusito> hey, I'll need to read a lot of text before I can answer any of the mentions of my name, so please be patient -_-
-<City-busz> it's a requirement by Arch Linux to make Cinnamon compatible with the latest stable GNOME releases
-<glebihan> it's not only a man power issue
-<d[-_-]b> glebihan: why?
-<clem> it's a "make it happen" issue
-<glebihan> because, as long as gnome won't keep backwards compatibility, there will be times when we have to make a choice
-<clem> it doesn't matter who does it, but if nobody does, it doesn't get done
-<d[-_-]b> but the problem is that you need someone to "make it happen" who isn't busy with doing more important stuff
-<clem> indeed, but the reason it wasn't a problem last time around (and remember 3.6 was not compatible either)
-<clem> was because Mint needed it as well
-<glebihan> right
-<clem> so faidoc and my agenda would have been the same here
-<d[-_-]b> i guess that point is clear
-<clem> we see it here with 3.8... leigh wants it for June, I want it for October.. faidoc wants it for yesterday
-<clem> the problem is, you don't see faidoc do it, you see leigh do it partially
-<clem> come close to October, you'll see me all over it if it isn't done by then
-<clem> we all have our own agendas
-<mtwebster> and finite disk space to have vm's of every different linux flavor to develop on
-<d[-_-]b> well we could tell faidoc to do it or shut up. the question is: do we want to do so
-<clem> when we get together and work on Cinnamon, we recognize this and as part of the merging team of course I treat it seriously but there's nobody I pay to fix this, and I'm certainly not paid myself to work on it
-<clem> I was delighted to see some of the guys step up and help out, and if we're lucky we might see 3.8 support in a couple of days
-<clem> but don't take it as given, things don't happen by magic
-<d[-_-]b> so as a matter of fact it's not beeing done by mint devs (at the moment). the thing that isn't clear is how to handle the "pr" concerned with this
-<clem> mint devs work on mint, they're mint devs :)
-<clem> some of the cinnamon devs don't use mint though
-<clem> leigh is a good example of this, he contributes pull requests just the same way as some of the mint devs and his focus is on Fedora
-<d[-_-]b> that doesn't fix the question
-<clem> his concern is to make sure 3.8 is supported by June
-<clem> I know I personally have enough time to make it happen and it won't take too much off my time and it's something I need done as well for myself before November, so I can commit to that and guarantee to him that yes, he will have it.
-<clem> but in the case of Arch, it's different. I can't guarantee to them that I'll be done this time next week.
-<clem> because I've no idea who'll do it.
-<clem> there's a big problem other than 3.8 when it comes to rolling distros..
-<d[-_-]b> ok. this makes the basic policy: "if it fits in hour agenda it will be done, in any other case feel free do do it yourself"
-<clem> say we finish 3.8 support today and release 1.7.4 and it works for them...
-<clem> they upgrade their users from 1.6.4 to 1.7.4..
-<clem> in other words they provide their users with our unstable version of Cinnamon
-<d[-_-]b> clem: we should not do that. because in the end we will be blamed
-<clem> think of that... they won't patch gjs, they won't delay upgrading GNOME, but they're happy to upgrade to an unstable release of Cinnamon
-<d[-_-]b> -> bad pr
-<clem> that's not good
-<clem> we're probably at 90% when it comes to 3.8 support, most of it was merged and it looks like gdbus is the only thing left?
-<City-busz> If the GDBus port would be trivial, I'd do that, but it requires deeper knowledge.
-<City-busz> not only the GDBus port is missing
-<glebihan> honestly, I think that what we're facing here, is that most people working on Arch don't care about Cinnamon, so whether it's removed from the repos or is an unstable version is irrelevant to them
-<clem> ok 5 more minutes about the politics before we move on to the technical side
-<clem> I'll say something quick...
-<clem> in cinnamon 1.6 most parts of the DE aren't forked yet
-<clem> which means cinnamon 1.6 was better in Mint than anywhere else, and Shell was worse than anywhere else (except Ubuntu who break it as well)
-<clem> with 1.8, we fixed most of that
-<clem> we forked screensaver, control center etc..
-<clem> which means shell will be better in Mint and cinnamon better everywhere else
-<clem> with that said, it's very probably that users who care about cinnamon are majoritarily running Mint
-<clem> and people who like Shell are probably gone away from it
-<clem> this is to take into consideration when it comes to the commitment a distro has for a DE glebihan 
-<glebihan> I didn't say otherwise
-<clem> you can't ask every distro out there to care as much as we do
-<clem> to give you an example, we pulled support on Xfce in LMDE
-<clem> when faced with incompatibilities and Debian running 4.8, we stopped supporting it
-<clem> I see a similar situation here and I've no ill feelings towards Arch
-<glebihan> neither do I, I perfectly understand their position
-<clem> they don't feel the same commitment towards Cinnamon, it's not as important to them as GNOME and so the decision to pull it makes sense
-<clem> ok
-<clem> ok that's good
-<clem> I hope they understand ours
-<glebihan> just saying that having an unstable version isn't really an issue for them, given the circumstances
-<City-busz> ideally, Cinnamon release circle would synced with the GNOME release circle...
-<d[-_-]b> not gonna happen though
-<clem> City-busz: in most cases it did...
-<clem> City-busz: ubuntu sync with it, one month later
-<clem> City-busz: Mint is one month later than Ubuntu and we want a month of feedback
-<clem> City-busz: which places Cinnamon a month after GNOME
-<City-busz> but they stay at GNOME 3.6...
-<clem> City-busz: the problem here is that we're on 3.6
-<clem> exactly
-<City-busz> so the latest stable release of GNOME is appear 7 month later in Ubuntu repositories
-<clem> we knew that'd be an issue for Fedora the minute Ubuntu announced that, we didn't think it'd come so fast.. I think we didn't really think about the rolling distros
-<City-busz> that's the problem
-<clem> yes, that's where there's a divide there
-<mtwebster> we're already straddling 3.4 and 3.6 as is
-<clem> now, technically, and long term, I want an independent DE
-<clem> one that doesn't break every 6 months
-<clem> I don't think it's easy to achieve but we will reduce the usage on gnome libs more and more
-<d[-_-]b> independet of gnome in general?
-<d[-_-]b> won't this result into something like: forking needed gnome libs and selling them as cinnamon libs?
-<clem> one of the 3.8 pull requests resulted in deletion of code rather than migration
-<clem> we also communicate with many gnome services over dbus, tomorow these will be cinnamon services which won't conflict with gnome
-<clem> d[-_-]b: there's utility features in the libs, and DE services
-<City-busz> then many gnome libraries would need to be forked, like gnome-desktop, gjs, gnome-menus, gnome-settings-daemon, gnome-session etc., which is not ideal, I think
-<clem> no no no...
-<clem> not all of them
-<d[-_-]b> clem could you explain the plan?
-<clem> d[-_-]b: it's hard because it works whether you fork or not, and so it's a case by case scenario of taking more under the umbrella vs the benefit of doing so
-<clem> d[-_-]b: in 1.8 we added screensaver and control center modules
-<clem> d[-_-]b: because we had the resources to maintain these... and so cinnamon is better as a result and more independent
-<clem> d[-_-]b: we're planning to look at gsd next, but there's no plan to fork everything
-<d[-_-]b> ok. but like City-busz said: if cinnamon should not use gnome libs, the functionality that is needed would have to be forked sometime
-<clem> d[-_-]b: in other words, 2.0 can work with gsd.. or we might decide to use our own services.. it'll depend on whether we think we can do better on our own and we have enough resources to do it.
-<clem> d[-_-]b: for utility libs, sometimes it's as easy as rewriting it yourself.. just the little part you're using
-<clem> d[-_-]b: I'm sure we can trim some of the dependencies without forking anything
-<clem> we need to move on... the meeting is taking too long :)
-<clem> from a technical point of view, I don't have a clear picture of what's left to do for 3.8 support
-<glebihan> ^^
-<d[-_-]b> in the end. everything that is used now will need a cinnamon replacement independend of gnome. so we can either continue developing own stuff or pull gnome changes every now and then
-<clem> because I've no one in front of me telling me exactly what is needed
-<d[-_-]b> ok move on
-<clem> from my understanding, it looks like gjs is the final hurdle?
-<glebihan> City-busz, do you know what is missing ?
-<City-busz> another issue with GNOME 3.8 is that the desktop background rendering is gone from gnome-settings-daemon: https://bugzilla.gnome.org/show_bug.cgi?id=682427
-<clem> was it put in nautilus?
-<City-busz> it's moved into mutter
-<clem> ok
-<City-busz> to the window manager
-<clem> the future looks bleak :)
-<City-busz> the desktop background rendering feature of nautilus is also gone
-<mtwebster> i'm working on removing background rendering altogether from nemo
-<clem> ok, that might be problematic..
-<mtwebster> just provide a transparent canvas to the desktop
-<City-busz> now nautilus renders a transparent ARGB window to draw desktop icons
-<mtwebster> but we'll have to handle one or the other.. something needs to draw the background
-<clem> something like cinnamon-settings-daemon? :)
-<clem> that won't be done in time for 1.8...
-<City-busz> maybe it can be implemented in muffin, based on mutter's patches
-<mtwebster> the problem is, in mint, we still need gsd to do it
-<mtwebster> so we can't just move it to muffin arbitrarily
-<clem> yes, we need it to work in 3.4/3.6
-<mtwebster> or rather, gsd still wants to do it
-<clem> this one is tricky..
-<clem> I'll make it an action on City-busz, myself, glebihan and mtwebster to talk about this and seek a solution, we really need to move on
-<City-busz> currently nemo fails to build on GNOME 3.8, because the gnome_bg_set_draw_background() function was removed from gnome-desktop: https://git.gnome.org/browse/gnome-desktop/commit/?id=ac536ef65ee399c3267b29049c62c70074b0a97d
-<clem> that's fixed
-<clem> that's the DND problem isn't it mtwebster?
-<mtwebster> clem: yes
-<clem> ok that's fixed then
-<mtwebster> i'm working to remove that entire file that handles rendering the desktop, as said before, so we wont' use gnome_bg at all
-<City-busz> okay
-<mtwebster> but i'll wait till we solve our bigger issue
-* leigh123linux (kvirc@SpotChat-772i57.dsl.as9105.com) has joined #linuxmint-dev
-<clem> hopefully we'll find a way to do it, it doesn't look easy though
-<mtwebster> i'll look at mutter tonight
-<clem> ok moving on to the next topic
-<clem> TOPIC: Road to 1.8 (what's left, when do we freeze/release)
-* clem has changed the topic to: Current topic: Road to 1.8 (what's left, when do we freeze/release),
-<clem> basically on this one, you probably saw all the version bumps today :)
-<clem> I'm getting another ISO ready, Mint 15 / Cinnamon 1.8
-<clem> I'll update the roadmap, find all the little things that aren't working well and list them :)
-<clem> we planned to release by the end of april... I think we might be a little late
-<autarkper> I have one blocker: https://github.com/linuxmint/Cinnamon/issues/1608
-<clem> thanks
-<d[-_-]b> basically for mint i think better late than unstable
-<clem> yes definitely
-* kentos (kentos@SpotChat-t1fcs0.mpls.qwest.net) has joined #linuxmint-dev
-<mtwebster> i think we should pull bumpmaps for now
-<glebihan> from where I stand, my main concern is about uncomplete features
-<clem> it goes without saying that there'll be a feature freeze at the end of the month and I wouldn't mind if we applied it a bit earlier
-<clem> mtwebster: yes
-<clem> glebihan: I'll go nazi on them
-<clem> glebihan: they'll be disabled
-<glebihan> there's the question of what to do with desklets too
-<clem> glebihan: dalcde fixed the DND issues afaik
-<mtwebster> we should get dalcde's pull requests in for desklets then reevaluate where they stand
-<clem> +1
-<clem> another thing is the inconsistent and incomplete UI look of the xlet modules in cinnamon settings
-<clem> that's something we should finalize
-<clem> applets is 95% there
-<clem> but it wasn't applied to themes, extensions and desklets
-<mtwebster> rjanja mentioned he had sent you stuff for serverside changes for desklets, extensions
-<clem> he did, some of it is on me :)
-<mtwebster> clem: i think we were sort of waiting to get applets 'just right' then duplicating it on desklets ,etc..
-<clem> my email is worse than my github dashboard mtwebster :))
-<clem> yes, we're still on applets indeed
-<mtwebster> but we haven't gotten that 'it's just right' yet
-<clem> agreed, completely my fault :)
-<clem> ok moving on.. cause I'm feeling down here :))
-<mtwebster> lol
-<glebihan> how dare you ? it's my fault ;)
-<clem> it's all on my on this one, I'll list all that's remaining and upgrade the server for the applet
-<clem> final topic: Dev blog
-* clem has changed the topic to: Current topic: Dev blog
-<Lusito> phew, done... you guys are chatty
-<clem> I think we're running out of time so I'll just do the talking and won't let anyone say anything ok?
-<clem> :))
-<Lusito> triaging is tagging issues on github I assume =
-<Lusito> ?
-<clem> yes
-<Lusito> alrite, count me in
-<clem> people are sad that nothing happens on the cinnamon blog
-<clem> unity fans get much more excited about a single new icon than they should
-<clem> and we've no buzz at all :)
-<d[-_-]b> you mean we need more pr?
-<clem> we've got a blog out there and we could start talking about the development
-<clem> for instance, you can now maximize windows horizontally thanks to mtwebster, that's something only github readers know :)
-<Lusito> well, You'll get some buzz by the 3d switchers
-<clem> so the idea is to open up the blog to developers
-<d[-_-]b> who do you concern a "developer"?
-<clem> that's a good question
-<d[-_-]b> cause you can't just let anyone write something who forked on github
-<clem> typically anyone who got his pull merged could probably talk about it...
-<d[-_-]b> I'd suggest to invite people to send in a blog entry when their pull request is merged
-<clem> there'd be a few things we'd want to talk about... to make sure he doesn't talk like he would in a pub..etc..
-<clem> it might come down to defining a team here as well
-<d[-_-]b> then he would send it to you/glebihan whatever and you would publish it
-<clem> and we might have to define rules (for instance, I don't want people to talk about things that might not happen.. things that aren't merged yet in other words)
-<clem> no, I'd rather go further and let people have author access
-<d[-_-]b> ok. but this might be dangerous
-<clem> as you illustrate here, the idea isn't mature yet and we need to think about multiple aspects
-<clem> but I wanted to let people know that this was something we were thinking about
-<d[-_-]b> as it could cause a not homoguenes picture
-<clem> true, it's something to plan, definitely
-<d[-_-]b> if you read a blog, you usually get used to a certain style. we should not spoil this experience
-<clem> indeed, but remember the monthly stats in Mint and the Developer of the Month?
-<clem> you have consistency there, but I'm the bottleneck again
-<Lusito> Is there a way to create a draft that is only visible to the team ?
-<clem> if we want things to happen I need to delegate
-<d[-_-]b> clem how about appointing someone to do the pr?
-<clem> not only in writing content on the blog, but in validating it.. I think we need to trust each other more
-<d[-_-]b> maybe larst would be interested instead of getting into the inner circle
-<d[-_-]b> you said he knows the changes and you trust him. so this might be a reasonable option
-<clem> two things I learnt... giving someone who does well more responsibility and taking it back when it turns out if was a bad idea usually ends up in them leaving the project... AND... if I do everything myself, we won't get much more done that what we're doing now.
-<clem> so let's go slowly on this, but the plan is definitely to let more people in, whether it's triaging like today, blogging, or at some stage merging
-<d[-_-]b> in all of those cases: many people who do things, some people to look it over
-<autarkper> I'll be taking my leave now. I hope the next meeting is a bit snappier. Bye all!
-<Lusito> Make a page with rules about blog posts, then ask a developer if he/she can comply to them, if so give them access. If they then can't comply to these rules (apart from minor mistakes), then you wouldn't want them on the team anyway
-<clem> that's what we have with the pulling vs merging, that creates bottlenecks d[-_-]b 
-<clem> ttyl autarkper 
-<glebihan> here again, it's a matter of trust. I think we have enough people in the team that can be trusted for clem to delegate the responsibility
-<glebihan> but rules need to be defined for things to go smooth
-<Lusito> Agree with clem, no need to bottleneck this. Responsible developers can write responsible blogs.
-<clem> definitely, let's all think of it and we can talk about it later
-<clem> Next meeting next week, Monday nights aren't supposed to be fun anyway right? :))

meetings/2013.04.15/minutes

@@ -1,18 +0,0 @@
-Topics:
-
-- Questions
-- Triaging issues (new members, tags, how to do it)
-- 3.8 compatibility and the use of GNOME libs in general (where do we use them, can we replace them?)
-- Road to 1.8 (what's left, when do we freeze/release), 
-- Dev blog
-
-Actions:
-
-- @clem: autarkper, lusito, dalcde, rjanja, cobinja and a question mark on larst
-- @city-busz, clem, glebihan, mtwebster: Talk about 3.8 desktop rendering issue
-- @clem: upgrade applet server code
-- @clem: list all problems for 1.8
-
-Decisions
-
-- Tags to be used: New Features, Bug confirmed (when the bug is valid, reproducible)

meetings/2013.04.22/log

@@ -1,418 +0,0 @@
-<clem_> Hi everybody and welcome to our 2nd meeting
-<glebihan> hi
-<d[-_-]b> hi
-<clem_> I'll try to go faster than last week this time :)
-<clem_> the topics are:
-<clem_> - Follow up on actions
-<clem_> - 3.8 compatibility
-<clem_> - 1.8 ETA and Roadmap
-<clem_> - Dev blog
-<clem_> - General questions
-<clem_> Let's start with the first topic
-* clem_ a changé le sujet en : Current topic: Follow up on actions
-<clem_> @clem: autarkper, lusito, dalcde, rjanja, cobinja and a question mark on larst
-<clem_> I managed to talk to dalcde and include him in the triaging team
-<clem_> I'm yet to do the same for the other people mentioned
-<clem_> I've met Lusito on a couple of occasions so that should happen soon
-<clem_> @city-busz, clem, glebihan, mtwebster: Talk about 3.8 desktop rendering issue
-<clem_> mtwebster took the lead on this and solved the issue with a global pull on 3.8 compatibility, there's a topic for this so I won't go in the details yet
-<clem_> - @clem: upgrade applet server code
-<clem_> Nothing was done on this one :(
-<Lusito> Not sure how much time I can devote to reading and judging tickets, but I'd try
-<clem_> @clem: list all problems for 1.8
-<clem_> I tested and listed everything I bumped into within the Roadmap
-<clem_> Next topic..
-* clem_ a changé le sujet en : Current topic: 3.8 compatibility
-<clem_> So here, we had an issue with Arch/Cinnarch and an upcoming issue with Fedora since they're using GNOME 3.8
-<clem_> Arch upgraded GNOME in their repository yesterday
-<clem_> I'd like to thank all the people who worked on this during the week
-<clem_> mtwebster gathered all commits/pulls and fixed all remaining issues into one mega pull:
-<Lusito> so it works with 3.8 now ?
-* AlbertP (albert@SpotChat-aofquv.solcon.nl) a rejoint #linuxmint-dev
-<clem_> https://github.com/linuxmint/Cinnamon/pull/1888
-<clem_> according to faidoc and city-busz yes, it works fine with 3.8
-<Lusito> nice
-<mtwebster> there are a couple 'catches' but nothing major
-<AlbertP> Github is telling that #1888 can't be automatically merged.
-<clem_> now, there's good news and bad news
-<clem_> the good news is that distros running 3.8 can run cinnamon...
-<clem_> the bad news is that that's a lot of changes, some of them dodgy, just before 1.8
-<AlbertP> did I miss much of the meet?
-<Lusito> nope
-<mtwebster> i'm not entirely convinced of the g-s-d and background interaction in 3.6/3.4
-<clem_> no AlbertP, not much, there'll be a log too
-<AlbertP> ok, that's fine.
-<clem_> personally, I'd prefer for this not to go in Cinnamon 1.8
-<glebihan> +1
-<d[-_-]b> +
-<d[-_-]b> 1
-<mtwebster> i agree
-<clem_> it brings nothing to 3.4/3.6 users and has a huge potential for regressions
-<clem_> of course that means 3.8 distros will need to apply the merge themselves, but the code is there, tested, I think we've done more than our fair share on this one already
-<mtwebster> i'll keep it rebased
-* Guest1878 est parti (Ping timeout: 121 seconds)
-<clem_> if it becomes an issue we can branch out and issue a release number 
-<clem_> something like 1.7.4-3.8 or something
-<d[-_-]b> agreed. only thing we should make sure is that this does not lead to a split into a 3.6 and 3.8 version (eg because someone changes things for 3.8 only)
-<clem_> but I don't see the point of doing it until a distro requests it
-<clem_> that's it, multi-tracking is something I'd rather not get into
-<AlbertP> agreed. With less than a month left till mint 15 release, we don't have the time to check everything for regressions.
-<clem_> once codebase that works everywhere is much easier to maintain
-<clem_> s/once/one
-<mtwebster> yeah.. i think that's a good one to start the next cycle on, so we have months and months to evaluate/fine tune
-<clem_> ok great, so we're good for 3.8 but we're not merging it
-* gaurav (gaurav@SpotChat-1ul.ag9.247.121.IP) a rejoint #linuxmint-dev
-<d[-_-]b> little off-topic: any reply from the cinnarch guys?
-<clem_> d[-_-]b: yes, faidoc says it worked fine in Cinnarch
-<d[-_-]b> ok thx
-<clem_> afaik they already have Cinnamon 1.7.x in there, patched with 3.8 support and everything runs fine
-<clem_> in Arch, not just Cinnarch
-<clem_> any other question re-3.8?
-<AlbertP> I seem to recall City-busz (who's helping faidoc with cinnamon on arch) had a pull request related to 3.8 too.
-<clem_> AlbertP: all pulls were closed, they were superseeded by https://github.com/linuxmint/Cinnamon/pull/1888
-<mtwebster> and one additional in nemo
-* clem_ checks
-<clem_> ok yes, https://github.com/linuxmint/nemo/pull/263
-<clem_> this one also, not sure? https://github.com/linuxmint/nemo/pull/258
-<mtwebster> not sure about the tracker part
-<City-busz> currently I have pull requests for cinnamon-screensaver only, but it's unrelated for GNOME 3.8, it applies to general GNOME compatibility
-<mtwebster> haven't looked at it
-<clem_> yes
-<glebihan> afaik, #258 is unrelated to gnome
-<clem_> ok
-<City-busz> I applied this tracker patch on Arch Linux
-<clem_> I'll test it hopefully tomorrow and merge it
-<City-busz> it's related to GNOME 3.8
-<mtwebster> the nemo-desktop-background portion was already taken care of on another patch
-<mtwebster> that was teh drag and drop patch
-<clem_> moving on to the next topic
-<Lusito> g2g, I'll check the log later, probably won't have too much to say here anyway.. have fun
-* clem_ a changé le sujet en : Current topic: - 1.8 ETA and Roadmap
-* Lusito est parti (Quit: Leaving)
-<clem_> so, the roadmap is currently up to date with what's left to do for Cinnamon 1.8
-* rocco (rocco@SpotChat-uprfnl.dyn.optonline.net) a rejoint #linuxmint-dev
-<clem_> if everyone is ok with it, I'd like to feature-freeze Cinnamon right now
-<glebihan> agreed
-<clem_> i.e. only bug fixes and roadmap items go in
-<mtwebster> yes
-<AlbertP> I'd like to see #1708 in since this one doesn't have that much regression potential.
-<clem_> AlbertP: 1708 and 1629 can go in, but they need rebasing
-<clem_> 1747 might also go in
-<clem_> although if none of them need to
-<clem_> ...
-<clem_> I mean, although none of them need to :)
- Tcl interface unloaded
- Python interface unloaded
- 
-* Historique chargé depuis Mon Apr 22 18:25:10 2013
- 
-* Vous parlez maintenant sur #linuxmint-dev
-* Le sujet de #linuxmint-dev est : Current topic: - 1.8 ETA and Roadmap
-* Sujet de #linuxmint-dev défini par clem_!clem@help le Mon Apr 22 18:20:40 2013
-* ChanServ active le mode +q #linuxmint-dev clem
-* ChanServ donne l'état d'opérateur de canal à clem
-<d[-_-]b> ok
-* kentos (kentos@SpotChat-vai29b.mpls.qwest.net) a rejoint #linuxmint-dev
-<AlbertP> with #1901, #1708 and #1629 in, I think cinnamon 1.8 is ok. #1850 is also an option, but being an applet it's also easy to distribute that one on Cinnamon Spices.
-<clem> sorry, I got disconnected..
-<clem> #1850 is a WIP
-<clem> it's one of the cool features planned for 1.8, it's not ready so it will be a cool feature planned for 2.0
-<glebihan> 1708 and 1629 can go in, but are not release blockers
-<glebihan> actually 1629 has nothing to do with releases
-* Malsasa est parti (Connection closed)
-<clem> definitely, I think the pull pool (hehe) is ok, we might merge a bit more but we've got most of it in
-<clem> on the roadmap there's a few more things to address and we're good to go imo
-* Garmine (Garmine@SpotChat-r41ok4.pool.telekom.hu) a rejoint #linuxmint-dev
-<clem> regarding ETAs and a release date... I've never announced dates before
-<clem> I usually release "when ready"
-<d[-_-]b> people like to have dates^^ it's like christmas
-<mtwebster> not really important, but it's been brought up a few times before:  a session 'emblem' for cinnamon, and maybe one for the default menu
-<mtwebster> i know the menu icon matches mate's
-<AlbertP> Agreed. For the pull requests on Cinnamon, it's OK now. We've discussed the 10 remaining pull requests enough, if you ask it me.
-<glebihan> people are impatient, but in the end, I'm sure they'd rather have a full working DE rather than one released the day it was annoucned to be
-<clem> mtwebster: where is the menu icon visible?
-<AlbertP> +1
-<clem> mtwebster: oh sorry, I see..
-<d[-_-]b> glebihan: sure
-<clem> mtwebster: I've needed an icon in MDM alright to represent cinnamon..
-<mtwebster> and our session select in mdm/etc.. is nothing
-<clem> mtwebster: that's not a blocker or anything to do with 1.8 though
-<mtwebster> of course, just mentioning it
-<clem> ok, so no release date..
-<d[-_-]b> maybe this could be some kind of comunity contest
-<clem> we'll release when ready
-<clem> i.e. when the roadmap is cleared
-<AlbertP> For the menu we could use a Minty icon.
-<clem> and we'll continue to merge bug fixes in before and after 1.8
-<clem> it will take me 1 or 2 days to get the announcements ready for 1.8
-<clem> this time next week I've got a feeling 1.8 will be out already
-<clem> then again, if it's not, it's not, no pressure or deadlines here
-<d[-_-]b> will it be part of backports for 13?
-<clem> d[-_-]b: yes
-<d[-_-]b> nice
-* gargamel (gargamel@SpotChat-l22.5tv.130.177.IP) a rejoint #linuxmint-dev
-<gaurav> clem: along with nemo too?
-<clem> gaurav: yes
-<clem> ok next topic:
-* clem a changé le sujet en : Current topic: Dev blog
-<clem> The "dev blog" is no other than the cinnamon.linuxmint.com blog
-<clem> I'm planning on adding its RSS feed to the LM planet (the one that populates people's FF auto-bookmark)
-<gaurav> we really need some screenshots for the slideshow on the top, it currently has only one
-<clem> and opening it to more authors than myself
-* Guest2194 s'appelle maintenant vrkalak
-* vrkalak s'appelle maintenant Guest80331
-<clem> the main blog is tied to the website, and social networks and isn't the place to talk about new stuff every time we commit something
-<clem> the audience on cinnamon.linuxmint.com is different though
-<clem> and that's a place where we could meet people who want more news, more detailed and more frequent
-<AlbertP> The cinnamon.linuxmint.com blog should indeed be updated more frequently if we want it to be interesting to end users.
-<d[-_-]b> in this case i'm not sure about inserting it into ff by default
-<glebihan> it does have one downside though
-<AlbertP> There's loads of new features that are worth being posted on such a blog.
-<gaurav> ok, I'm just viewing that site and the slideshow with one screenshot is really bugging me
-<glebihan> if the dev blog is going to be on cinnamon's website, it's gonna make it harder to share about other dev topics
-<clem> d[-_-]b: for reference, any youtube video called "Linux Mint something" gets in the bookmarks
-* gaurav est parti (Quit: Leaving)
-<clem> d[-_-]b: so there's definitely room for cinnamon devs to be there too :)
-<d[-_-]b> clem ook in this case it fits
-<clem> d[-_-]b: it's the dropdown "News" item in the bookmark toolbar
-<clem> glebihan: that's a good point
-<d[-_-]b> clem i think i deleted that one
-<clem> glebihan: it begs the question as to whether we needed a cinnamon website in the first place, or a website to talk about development
-<glebihan> clem, well, I think there are 2 kind of audiences here, and the cinnnamon website is interesting for "normal" users
-<clem> glebihan: I guess this is something the website audience should answer at some stage
-<clem> glebihan: but you agree that joe user and his grandma don't visit cinnamon.linuxmint.com
-<d[-_-]b> question is if we would like them to do so
-<clem> well I'm not sure..
-<clem> probably not
-<glebihan> clem, within the mint community, probably not, outside of it, maybe more, but I guess you're right
-<d[-_-]b> i don't think so as well
-<clem> I heard some complaints that the cinnamon website didn't explain what cinnamon was...
-<clem> and I kept thinking "how the hell did that guy got to the website?"
-<d[-_-]b> maybe google?
-<clem> it's a website for people who want to know what's coming right?
-<AlbertP> We could post the details on the cinnamon website when interesting features get added, and use the general Linux Mint blog to post a summary of new features when we release a major version like 1.8.
-<clem> you'd assume they already know what cinnamon is
-<clem> AlbertP: yes
-<glebihan> clem, probably from http://en.wikipedia.org/wiki/Desktop_environment or similar
-<d[-_-]b> well i guess some people might read: linux mint cinnamon somewhere. so they go out and try to find something about it
-<clem> regarding the blog, just like the triaging team, we'll need to set up a team of authors I guess
-<AlbertP> clem: about getting to the website, it's indeed not that easy to find a link to it on the web.
-<clem> AlbertP: but that's because Cinnamon isn't trying to sell itself
-<clem> AlbertP: the website is there for existing users, not as a vitrine to potential new ones
-<d[-_-]b> AlbertP: let's say someone reads an article about Linux Mint and Cinnamon. If he googles "linux mint cinnamon" it's the first hit
-<clem> right..
-<clem> and that's something that's a fair argument vs Mint as well
-<d[-_-]b> clem you should consider that many people switch to Mint mainly because of Cinnamon. So I think explaining what Cinnamon is won't be bad
-<clem> maybe you're right
-* Déconnecté (Connexion ré-initialisée par le correspondant).
-* clem est déjà utilisé. Réessai avec clem_...
-* clem_ active le mode +i clem_
-* clem_ active le mode +x clem_
--InfoServ- *** Message(s) of the Day ***
--InfoServ- [Portscans] Notice from Kuja, posted 15:31 on 09/10/2011:
--InfoServ- On connecting to this Network you are agreeing to be scanned for open Proxies. Please disregard any messages from Monitoring or Security software about this matter, it helps us keeping our Network a safe place.
--InfoServ- *** End of Message(s) of the Day ***
--NickServ- Welcome to SpotChat, clem_! Here on SpotChat, we provide services to enable the registration of nicknames and channels! For details, type /msg NickServ help and /msg ChanServ help.
--NickServ- You are now identified for clem.
-* nutime.de.SpotChat.org active le mode -x clem_
-* Vous parlez maintenant sur #linuxmint-dev
-* Le sujet de #linuxmint-dev est : Current topic: Dev blog
-* Sujet de #linuxmint-dev défini par clem!clem@help le Mon Apr 22 18:36:15 2013
-* ChanServ active le mode +q #linuxmint-dev clem_
-* ChanServ donne l'état d'opérateur de canal à clem_
-<glebihan> as far as I can tell, there are still at least as many MATE users as Cinnamon ones on Mint
-<clem_> sorry, I got DSQ again... with 3 ISPs you'd think one of them would work for an hour...
-<AlbertP> d[-_-]b: I think you are right. Cinnamon has a good reputation already on forums, and also in this chat, many people reading that become interested in what cinnamon actually is.
-<clem_> so, for the dev blog, I'd like to welcome people in
-* clem est parti (Ping timeout: 121 seconds)
-<clem_> and we can talk about how and what to do together within the blog team then
-<clem_> I don't think there's a need for me to set rules or guidelines since I'll probably learn as much as everyone else while going through it :)
-<d[-_-]b> fine
-<AlbertP> I would be available for that. Have written for a magazine before.
-<clem_> if we get to the point where we have an article every day and a crowd of passionate users and we cover more stuff than just cinnamon...
-<clem_> then even better
-<clem_> I was talking about omg and webupd8 earlier on
-<clem_> these tabloids are focused on unity and shell
-<mtwebster> do we start our own 'independent' spin page? :)
-<mtwebster> j/k
-<clem_> :)
-<clem_> one common thing that people say is that cinnamon isn't very active
-<AlbertP> and otherwise I could check the spelling of other people's items; at the magazine I've improved many articles written by a dyslectic.
-* Guest80331 est parti (Quit: Leaving)
-<clem_> when Cinnarch said it was 1 year late, I've read comments of people questioning our ability to maintain a DE
-<clem_> it all comes down to perception here
-<clem_> because nobody looks at the 1.2 and 1.4 releases and doesn't agree on the achievements
-<clem_> sorry.. 1.4 and 1.6 :)
-<d[-_-]b> how bout some chart?
-<clem_> but you can read hype on the next Unity every day
-<clem_> I don't even plan to give Unity a 10 minutes go when Ubuntu releases... yet, I know all its new features
-<clem_> for people who want to read buzz/hype about the next Cinnamon, the only source there is is github...
-<AlbertP> clem_: To me it seems like people on the Mint forum / Mint chat are no longer questioning this ability, but maybe they still do on other forums that are not Mint specific.
-<mtwebster> i think the results can speak for themselves, with a blog to highlight things
-<clem_> AlbertP: probably, and there's a concentration of like-minded people in these blogs as well
-<clem_> AlbertP: you can appreciate the lack of interest shown in the comments sections when MATE 1.6 was announced
-<mtwebster> AlbertP: on some forums/mailing lists, cinnamon is still a crappy 'fork'
-* Oscar799 est parti (Quit: Leaving)
-<clem_> so I'll go around the block asking people if they want to get involved in the blog then and we'll get things started slowly but surely
-<clem_> we'll post a few articles, see how people react, see what we learn about ourselves and if need changes from the website/blog itself then
-<d[-_-]b> clem_ if we had something like a chart which lists time on x axis and features on y axis, everybody could really see the progress
-<d[-_-]b> it just would strike you more than reading tons of blogs
-<clem_> d[-_-]b: I think the progress is there, the 1.6 announcement stressed that
-<clem_> d[-_-]b: but there's probably a demand for buzz
-<clem_> d[-_-]b: for instance, I read my gaming news every day :)
-<clem_> d[-_-]b: I don't like gamespot and IGN much, but they're great at providing me with my daily dose
-<clem_> d[-_-]b: if you like cinnamon and you want cinnamon news, it's hard to get your daily dose these days, even if things move on github
-<clem_> and MATE probably has that problem as well
-<clem_> maybe that's something we can cover as well.. there again we go back to glebihan's point
-<d[-_-]b> clem_ totally agreed. and i appreciate having a well updated blog. i just was thinking if we had this chart, every time someone would say "cinnamon is not active enough" you could point him there like "and what's that, huh?"
-<clem_> d[-_-]b: we do..
-<clem_> https://github.com/linuxmint/Cinnamon/graphs
-<d[-_-]b> yes but that's github. (and not to much understandable for a common user to be honest)
-<AlbertP> Github just added the "pulse" to see recent developments. https://github.com/linuxmint/Cinnamon/pulse
-<glebihan> clem_, I'd like us to take some time to think about the direction we want to take with the dev blog, ie making the blog a part of cinnamon's website or making cinnamon website a part of the dev blog
-<d[-_-]b> I was thinking of something more abstract. like "on day xyz we implement this new feature:"
-<clem_> AlbertP: wow that's cool :)
-<clem_> glebihan: ok, now or during the week?
-<AlbertP> But still like d[-_-]b says this is not for common users. That's what we need the blog for.
-<glebihan> clem_, there's no rush, can be during the week
-<clem_> glebihan: ok, I'll put an action on this then
-<clem_> ok, onto the next topic
-* clem_ a changé le sujet en : Current topic: General questions
-<glebihan> ok, when do we eat ?
-<clem_> we already ate
-<glebihan> damn
-<gargamel> Cinnamon has a lot of hidden features. Only the dev knows about them. Sometimes they even forget them. So make sure you cover all these new hidden features
-* City-busz est parti (Connection closed)
-<clem_> any questions guys? or off-topic stuff?
-<clem_> or a pull you want to talk about?
-<d[-_-]b> i wonder how dolphin does their content search :P
-<mtwebster> i'd like some direction on these github issues.. 
-<mtwebster> there are 100's of 'make it do this'
-<clem_> d[-_-]b: I've no idea, I noticed a pull on nemo about this
-<d[-_-]b> clem_: yes i did it^^
-<glebihan> clem_, d[-_-]b was the one making it
-<clem_> d[-_-]b: oh :))
-* clem_ hides
-<mtwebster> yes they're enhancement requests, but at what point do we say 'not the direction we're going'
-<mtwebster> when one person wants something
-<d[-_-]b> clem_: no problem. it's by no means ready
-<clem_> d[-_-]b: ok
-<clem_> mtwebster: let's take an example.. can you point to one in particular?
-<mtwebster> hmm
-<d[-_-]b> mtwebster: the search thing?
-<clem_> mtwebster: just one example Sarah... heh.. Michael
-<mtwebster> clem_: https://github.com/linuxmint/Cinnamon/issues/629
-<clem_> that's a great example actually :)
-<clem_> and there's people doing +1s :))
-<mtwebster> clem_: but i've heard you say on multiple occasions we wont' do it
-<mtwebster> or do we succumb to pressure after a while?
-<clem_> so here you're basically facing a very nice guy who's being very polite, who explains his idea and is +1'd by others...
-<AlbertP> Also a very wanted feature is having a panel on a 2nd monitor.
-<clem_> well, what do you think when you read the issue?
-<mtwebster> that was probably a bad example of 'obscure feature'
-<clem_> do you think "damn.. that guy's right"
-<clem_> or do you think "damn... how am I gonna say no to him"
-<mtwebster> i think of the technical and layout issues it presents
-<mtwebster> i.e. applets iwth text, etc..
-<mtwebster> but then i argued with lusito about it one day (he's for it)
-<mtwebster> and we could limit to icon only applets, etc.. to make it work
-<clem_> no
-<mtwebster> i just don't like it in general
-<clem_> because in the end of the day it doesn't bring much to most people and it brings a lot of complications..
-<clem_> assuming you do it and it doesn't complexify the code/design/potential for bugs..
-<clem_> you still need to explain to people why text isn't working when the panel is vertical
-<clem_> you introduced a limitation you didn't explain
-<d[-_-]b> i think this on is not a great example because it's not "either or". ie if it would be implemented it would not effect other things (apart from bugs maybe)
-<AlbertP> that's true. A panel on a 2nd monitor is technically easier, and probably wanted by more people.
-<mtwebster> clem_: the problem in a lot of these cases is obviously i can't read your mind.  i'm hesitant to close the door on something and you may go back and say, 'that's brilliant'
-<mtwebster> yes our issue list keeps growing and growing :)
-<mtwebster> yes/yet
-<clem_> mtwebster: then we should treat these as we treat pulls and I should get involved when you're not sure
-<clem_> mtwebster: in the end of the day github is a subset of community, which is a subset of launchpad... we've millions of users, there's no way we'll triage everything :)
-* Testing567 (Testing567@SpotChat-uprfnl.dyn.optonline.net) a rejoint #linuxmint-dev
-<mtwebster> clem_: how about a 'needs review' or something
-<mtwebster> tag
-<clem_> mtwebster: it's depressing sometimes, until you consider it from a different point of view...
-<clem_> from the point of view of answering people it's a complete failure
-<clem_> from the point of view of us having a pool of idea when we run out of inspiration it's brilliant
-<clem_> so the main problem here isn't to pass by a great idea, but to communicate to people that we're grateful
-<clem_> mtwebster: if you want, otherwise you can also assign the issue to me
-<mtwebster> you guys were joking about the 'considered' tag on mint ideas
-<clem_> no
-<clem_> people got vexed
-<clem_> considered means rejected
-<clem_> it used to be called rejected and people were not happy
-<clem_> now it's called considered (not as in "being considered" but as in "was considered") and people are happy
-<glebihan> now they're complaining about it being called "considered" and not about the fact that the idea was rejected :)
-<mtwebster> right.. i'm suggesting maybe something similar for enhancement requests
-<mtwebster> but i guess it still boils down to i have to flag something for you to review
-<glebihan> I've had to set as "considered" ideas asking for the "considered" status to be renamed :)
-<clem_> I'm not depressed about it because I saw it happen with everything we used
-<clem_> soon or later you get submerged by the size of the community
-<clem_> so at first we looked at every issue and fixed or closed every single on
-<clem_> because few people knew about github
-<clem_> now there's 400
-<clem_> tomorrow there will be 2,000
-<clem_> eventually it'll boil down to making sure contributors aren't vexed and us using contributions from the pool randomly when looking for cool ideas rather than looking at all of them systematically
-<clem_> I hope what I'm saying is too depressing :)
-<clem_> isn't
-<mtwebster> lol
-<d[-_-]b> no. it has to be done this way if we won't get blocked be requests
-<briand> you might've had it right, subconsciously, the first time.  ;)
-<clem_> hehe
-<AlbertP> clem_: contributors of pull requests already get a bit irritated when they need to rebase all the time. That's why I asked you to merge the debian build cleanup of nbourdau. It needed rebasing for the third time.
-<clem_> right, and that's how everything works...
-<AlbertP> #1708 also had that problem.
-<clem_> you highlight something, it gets done and w00t..
-<clem_> there's a lot of contributions everywhere, it's a huge problem but also a very good problem to have
-<clem_> there's a lot of users out there and many of them are happy to help, we can't talk to each one of them though.. there's too many of them
-<clem_> the mod team sends us the best ideas from the forums and the community website
-<clem_> and everytime we speak to people we try to explain how grateful we are and that Mint is the result of it all
-<mtwebster> is that a mailing list i could get on?
-<mtwebster> i'm a bit detached from the community website
-<clem_> on an individual basis though, we don't have the resources to communicate with our audience on a 1 to 1 basis
-<clem_> mtwebster: community.linuxmint.com
-<mtwebster> i know that :)  you said they send the best ideas
-<clem_> oh no, by email
-<mtwebster> ok
-<clem_> Suzanne would send an email saying this or that or linking to a thread
-<clem_> or Vincent
-<clem_> back to topic though, you can assign me on github issues
-<mtwebster> ok
-<clem_> but really the best way to get things done is just like everything else, by harassing me on the IRC :)
-<AlbertP> who's Suzanne?
-<clem_> AlbertP: Oscar799
-<AlbertP> ok.  didn't know that yet.
-<clem_> with that said I think we're doing great
-<clem_> we can look at the 400 issues and think it's too much, but that's not because Cinnamon isn't active, it's because it's got a big audience
-<mtwebster> true
-<d[-_-]b> i think you made it clear by now ;)
-<clem_> more bug reports is a good thing after all, not a bad thing
-<clem_> right, any other topic/questions?
-<briand> the support folks would still like to see a Linux Mint pastebin set up somewhere.. so we don't have to advertise ubuntu or debian during support issues..  ;)
-<clem_> I was hoping to set Fred on it, only he found the idea completely pointless
-<clem_> I like it a lot myself, it just didn't have time to get it done
-<d[-_-]b> yes. it's just more work without some real advantage
-<glebihan> clem_, that's something I could work on, if noone else is interested/has time
-<briand> there's no real advantage at the nuts & bolts level, I agree... it's just a more consistent experience for the end-user
-<d[-_-]b> briand agreed
-<briand> linuxmint branding, throughout, if you will...
-<clem_> glebihan: if you want, let me have a look re-hosting first
-<briand> and, you know.. there's room in the margins of those pages to promote the next great thing, etc..  ;)
-<glebihan> clem_, ok
-<clem_> glebihan: if it works fine server-side there'll be desktop integration in play so I'll let you have fun with that :)
-<glebihan> clem_, cool :)
-<clem_> we can even patch xchat I guess :)
-<briand> glebihan / clem_ :  we can integrate with an xchat settings tweak and a pastebinit config that points to it out of the box.
-<clem_> yes
-<briand> don't even have to patch it.. just add a default config to it.
-<clem_> well it could pastebin whatever takes more than say 2 lines
-<briand> precisely
-<clem_> so all you'd have to do is paste text in the entry and press enter
-<briand> in fact, I came across a script that essentially does that, out of the box.  greater than 3 lines in the buffer, it sends it off to pastebin.  I can see if I can dig that up, if it'll be helpful to you, glebihan 
-<clem_> anyway, it's a bit early for that let's talk about this outside the meeting
-<clem_> briand: nice
-<briand> yes, okay.   didn't intend to derail your meeting.   ;)     I'll go hide in the corner, again.   ;p
-<clem_> lol
-<clem_> I added an action for that
-<clem_> ok, thanks everybody for being here and see you next week same time same place :)

meetings/2013.04.22/minutes

@@ -1,22 +0,0 @@
-Topics:
-
-- Follow up on actions
-- 3.8 compatibility
-- 1.8 ETA and Roadmap
-- Dev blog
-- General questions
-
-Actions:
-
-- @clem: Add autarkper, lusito, rjanja, cobinja to the triaging team
-- @glebihan, @clem: Talk about larst and decide on whether he should join the triaging team
-- @clem: Upgrade applet server code
-- @clem, @glebihan, @mtwebster: Talk about the blog, its scope, what it should be etc..
-- @clem, @glebihan, @briand: Talk about pastebin and integration with xchat/DE
-
-Decisions
-
-- The GNOME 3.8 support pull request was finalized, but not merged. It's in Arch already but it won't go in Cinnamon 1.8 per se (as it brings nothing to 3.4/3.6 users and presents a risk for regressions close to the 1.8 release).
-- It was decided no release dates would be announced for Cinnamon 1.8. The new release will happen when the Roadmap is cleared.
-- Cinnamon was Feature Frozen, only bug fixes are going in.
-

meetings/2013.04.29/log

@@ -1,367 +0,0 @@
-<clem_> welcome to the 3rd official weekly meeting :)
-<clem_> for this one we didn't set any topics, but there's one important thing we need to discuss: Cinnamon 1.8
-<clem_> so we'll start with a follow up on last week's actions
-<clem_> then we'll talk about Cinnamon 1.8 ETA/release
-<clem_> and then we'll open the floor to questions, remarks, jokes, and whatnot
-
-<clem_> ok, let's start with the follow up
-<clem_> Minutes for the previous meeting: https://github.com/linuxmint/Roadmap/blob/master/meetings/2013.04.22/minutes
-<clem_> action: @clem: Add autarkper, lusito, rjanja, cobinja to the triaging team
-<clem_> action: @glebihan, @clem: Talk about larst and decide on whether he should join the triaging team
-<clem_> .. so, glebihan and I talked about this and we decided to welcome Lars into the team
-<clem_> Lusito and autarkper were also added
-<lars> thanks :)
-<clem_> I didn't get the chance to talk to rjanja and cobinja yet though
-
-<clem_> Next action..
-<clem_> @clem: Upgrade applet server code
-<clem_> this was done and the UI was updated in Cinnamon Settings
-<clem_> applets, desklets, themes and extensions can be installed/upgraded remotely
-<clem_> one thing wasn't done... the description still isn't parsed from the metadata on the server side
-<clem_> we'll probably need to remove the descriptions from the online tabs in cinnamon settings
-<clem_> there's a lot of improvements we can do on the server code (which was added to github btw)
-<clem_> and parsing the metadata isn't something we'll do in a hurry in time for 1.8
-
-<clem_> Next action..
-<clem_> @clem, @glebihan, @mtwebster: Talk about the blog, its scope, what it should be etc..
-<clem_> mtwebster came up with a ridiculous name...
-<clem_> and glebihan thought it was a good idea, so we went for it
-<lars> what name was it ?
-<clem_> the decision was made to create a new blog, distinct from the official one and from cinnamon.linuxmint.com
-<clem_> but to use a subdomain under linuxmint.com
-<clem_> so we'll use segfault.linuxmint.com
-<lars> ok
-<d[-_-]b> that's like: we are some nerds and write a blog
-<clem_> that's exactly it d[-_-]b 
-<clem_> the book we read before going to bed is xkcd
-<d[-_-]b> i don't like it... but your choice
-<lars> clem_: do we take wordpress ?
-<clem_> well it isn't too late to change it
-<clem_> but as we said, we'll pick the name which sucks the less... right now that's the one
-<clem_> the "least"
-<clem_> probably lars 
-* lockjs (james@SpotChat-mnoj7o.bethere.co.uk) has joined #linuxmint-dev
-<autarkper> cinnamonitor ?
-* mtwebster will have to rename his applet
-<mtwebster> it's not a cinnamon-only blog either
-<clem_> it will be handled as a news blog, with the aim of about 1 article per day, focused on dev and new stuff around the Mint ecosystem
-<lockjs> evening, sorry im late
-<clem_> so focused on cinnamon of course, but also talking about other things and it could cover other DEs
-<clem_> I've had a word with the MATE board, they're interested in the idea as well
-<d[-_-]b> why not new.linuxmint.com then?
-<d[-_-]b> *news
-<clem_> because it should be something people can refer to and have its own identity
-<d[-_-]b> ok
-<mtwebster> news doesn't imply dev either
-<clem_> it's not a place where Mint announces things to its community, but a place where people read buzz and devs can get people excited
-
-<clem_> Last action: 
-<clem_> @clem, @glebihan, @briand: Talk about pastebin and integration with xchat/DE
-<d[-_-]b> i see. hmm
-<clem_> Nothing was done on this one.
-<lockjs> dev.mint(/blog)
-
-<clem_> Next topic: 1.8 ETA and Roadmap
-<clem_> The roadmap is available at https://github.com/linuxmint/Roadmap/blob/master/README.md
-<clem_> It got pretty small :)
-<clem_> There's two things I consider blockers...
-<clem_> - The artefacts in the menu
-<clem_> - The fact that nemo doesn't l10n (which is missing in the roadmap right now)
-<mtwebster> clem_: didn't we remove all the old nautilus translations  about a month ago?
-* AlbertP (albert@SpotChat-66j.hko.67.92.IP) has joined #linuxmint-dev
-<clem_> we did, but we probably pointed to the wrong path
-<clem_> I'm sure it's easy to fix, we'll just need to make it work before 1.8
-<mtwebster> yeah.. probably somethign simple
-<AlbertP> Hi all. I've managed to get internet at a restaurant to join this meeting.
-<clem_> mtwebster has a pull on the desklets too, so DND shouldn't cause any crashes anymore
-<clem_> hi AlbertP 
-<clem_> Are there any issues people consider blockers?
-<autarkper> I have a blocker coming up: Cinnamon crashes if you turn on "Only use workspaces on primary monitor"
-<clem_> ok
-<autarkper> It's not confirmed yet but I'm starting to see a pattern
-<AlbertP> That "feature" was the default behaviour of gnome-shell, that's how it got into cinnamon.
-<autarkper> it's actually not that bad after one gets used to it
-<autarkper> I dont' mean the crashing :)
-<AlbertP> I made it possible to turn that off using cinnamon settings and I think off is default now. Don't know if there are still users of it.
-<glebihan> a feature crash ?
-<clem_> that's not something people need to tick on/off right, it's a matter of preference
-<clem_> I guess we could ask for a restart to apply that one, and stop listening to the key change here
-<clem_> otherwise we need to scan all windows on all workspaces, test their monitor and move them around..
-<AlbertP> autarkper: so it's crashing because it has to move the windows somewhere?
-<autarkper> I don't know why it's crashing, only that it crashes. It's a recent regression BTW.
-<clem_> ok
-* clem_ blames glebihan 
-<glebihan> of course :)
-<autarkper> https://github.com/linuxmint/Cinnamon/pull/1831
-<clem_> any other blockers?
-<clem_> Note that the first release of 1.8 will be 1.8.0
-<glebihan> anything else you want to blame me for ?
-<clem_> and that once it's out, it will be followed by quick successions of 1.8.x bug fixes releases
-<clem_> 1.8.1 could come an hour after 1.8.0 and contain only one bug fix...
-<AlbertP> clem_: I thought you had learned from 1.6.7.
-<clem_> we'll be very strict on the freeze and the potential regressions, but we'll be able to follow up with numerous tiny releases whenever we have fixes
-<glebihan> AlbertP, learned ?
-<clem_> learnt
-<clem_> same thing
-<glebihan> that wasn't my point :)
-<glebihan> what should have been learned ?
-<AlbertP> glebihan: The last thing clem merged before tagging 1.6.7 was a regression.
-<glebihan> AlbertP, oh
-<clem_> oh right
-<glebihan> well
-<clem_> it was indeed :)
-<AlbertP> So tagging a new release only an hour after 1.8.0 is perhaps too quickly.
-<clem_> look, I can't guarantee no regressions will ever go in...
-<glebihan> it took months to identify that as a regression, so it wasn't that bad :)
-<clem_> but the quick succession of bug fixes releases following the main 1.6.0 was a success
-<AlbertP> OK, so it's learnt, not learned. I should have known that. Thought it was like spelled/spelt which are both possible.
-<clem_> both spellings are correct
-<mtwebster> not in the US
-<glebihan> isn't it an English vs US thing ?
-<clem_> yes
-<lars> when will 1.8 be released ?
-<mtwebster> spelt is a hardy wheat grown mostly in Europe
-<clem_> as soon as the blockers are gone lars 
-<lars> ok
-<clem_> what's happening is that after a few bug fixes, 1.8.x will stabilize
-<clem_> and we'll eventually focus on 1.9
-<lars> ahhh ok
-<mtwebster> clem_: your nemo roadmap issue, i still can't reproduce..  and the menu ghosting, it's a possible driver issue i think
-<clem_> when that happens, we'll let 1.8.x be... unless there's a huge bug that REALLY needs to be fixed
-<lars> ok
-<clem_> so after 1.8.0 is out, it's not just about giving people fixes ASAP, but also making sure any code that gets in, gets in early... within that month or so where we're still focused on 1.8
-<lars> clem_: but we need to give 1.8 at least one more month to stabilize
-<lars> ah yeah
-<lars> you just said that last sentence :)
-<AlbertP> mtwebster: well mtwebster I usually attempt to write British, unless you know a good reason for writing American English in this chat.
-<clem_> nobody wants a buggy 1.8.0, but what really matters a lot here, is that 1.8.x which will ship in Mint, Fedora and all
-<AlbertP> lars: well Mint 15 isn't out yet. It'll have a few weeks anyway.
-<clem_> that's the one that needs to be rock solid
-<clem_> and the community feedback we'll get on 1.8.0, 1.8.1, etc.. will help a lot here
-<lars> AlbertP: no i didn't meant mint15 i meant 1.8 :)
-<mtwebster> AlbertP: i was attempting to be funny, apparently unsuccessfully
-<lars> AlbertP: not sure what you mean now
-<clem_> you can think of 1.8.0 as an RC, it works, it's stable, but people WILL find bugs in it.
-<lars> ok
-<autarkper> mtwebster: I appreciated your remark :)
-<clem_> it's the first 1.8.x which will get large community feedback
-<lars> clem_: yeah ok I unterstood now :)
-<clem_> in Mint we'll feed Romeo with 1.8.x
-<lars> mint 13 ?
-<clem_> yes
-<lars> ok but not mint 14 right ?
-<clem_> well, we'll see
-<lars> ok
-<clem_> either way we'll get feedback on 1.8.0
-<AlbertP> I'm sure 1.8.x will get into one of glebihan's PPA's for use on Mint 14 as well.
-<glebihan> why not mint 14 ? the users that are most looking forward to new features and are the more likely to provide feedback IMO are the ones running 14
-<lars> glebihan: yes I also ask me
-<clem_> by the end of May we'll have Mint 15 and a solid 1.8 Cinnamon, I'd expect to switch focus towards 1.9 then
-<glebihan> AlbertP, not for mint 13 / precise though
-<clem_> good point glebihan
-<AlbertP> glebihan: With cinnamon-control-center no longer a dependency it should be ok to run it on precise I think.
-<glebihan> AlbertP, but I won't do it in the PPA
-<AlbertP> glebihan: that's not such a problem if clem has it in romeo for maya.
-<AlbertP> glebihan: so it's ok.
-<clem_> of course that means pull requests will be ignored until the end of may unless they're bug fixes for 1.8
-<clem_> we had that problem before and it was frustrating, but if we stick to the agenda, it's only one month here
-<lars> clem_: you already can make a branch NEXT
-<clem_> that's the thing lars, I'd rather not multitrack
-<lars> clem_: ah it's a good argument clem
-<lars> clem_: good point
-<clem_> we can agree on letting master go to 1.9 at the end of May though
-<lars> ok
-<clem_> so if we need more fixes on 1.8 by then, we'll branch out 1.8 into its own maintenance branch
-<clem_> that's a guarantee I'm happy to give to developers
-<fpqc> anything new in 1.7.7? muffin and cinnamon were segfaulting really bad on the latest arch update
-<fpqc> but since it's a higher number, does that mean new features?
-<AlbertP> With 1.4 we also had such a branch and IMO that worked out well, without disturbing development on master.
-<clem_> I can't remember... I remember the frustration with 1.6 though
-<fpqc> 1.7.x already is a branch next, isn't it?
-<clem_> no it's using master fpqc 
-<clem_> ideally all devs would do bug fixing until the end of may and work on 1.9 in June... :)
-<fpqc> ah, but you compile nightlies off it anyway, don't you?
-<clem_> but people contribute what their passion drives...
-<fpqc> or well, other people do
-<AlbertP> clem_: well none of us seems to remember such frustration with 1.4. And with 1.6, other people including me were frustrated as well.
-<d[-_-]b> clem_ concerning the low manpower i would agree on not branching if not absolutely neccessary
-<clem_> we can't ask people to focus on what we want all the time
-<fpqc> clem, better to release full-featured but buggy software than bug-free software that can't do anything
-<clem_> autarkper: what's your input on this? You were frustrated the last time around. How do you see it this time around with master getting in 1.9 at the end of May?
-<AlbertP> clem_: that's right. But now we at least have a guarantee that master will be back to normal after a month. We can now tell developers a date on which we can look into their pulls again.
-<glebihan> fpqc, that's the arch way of seeing things
-<fpqc> glebihan, idk, I use nightly everything
-<clem_> autarkper: essentially it means we're freezing for a month, but with a guarantee that it won't last longer than a month.
-<glebihan> fpqc, exactly, which basically no mint user does
-<fpqc> that's why everything breaks so often lol
-<autarkper> clem: I would certainly have preferred not freezing 
-<fpqc> glebihan, I mean, they don't really havea choice
-<autarkper> I think we should be able to handle two branches
-<clem_> autarkper: the problem with not freezing is that every bug fix will need merging in both branches... 1.9 and 1.8
-<fpqc> you don't have a rolling release for mint, and mint is the girl that all the boys want to get to know
-<glebihan> fpqc, there's always a choice, but that wasn't really my point. We'll always choose not to release a feature over releasing it while it's still buggy
-<clem_> autarkper: it makes our job much harder precisely at the very moment when we're the most focused on Mint and the least on Cinnamon
-<AlbertP> clem_: last time with 1.6, there was no such date set. People were left in the dark about when development on master would continue - and that was, in my experience, why they got so frustrated. Now we can tell people that it'll be frozen until the first of June.
-<fpqc> glebihan, idk, there's nothing wrong with releasing buggy software as long as you label it unstable
-<autarkper> clem_: you could let a band of rookies take joint responsibility for one of the branches
-<glebihan> fpqc, we don't release unstable versions
-<fpqc> then how do you test?
-* mockturtl has quit (Ping timeout: 121 seconds)
-<clem_> with 1.8.0 :))
-<mtwebster> arch does
-<glebihan> fpqc, there's no need to release in order to test
-<fpqc> haha mtwebster
-<fpqc> glebihan, well, when you guys do a "release", it's a big deal since you do bi-annual releases
-<d[-_-]b> clem_ so how's the decission?
-<clem_> well, for me it's crystal clear, unless I absolutely have to, I don't want to maintain more than one branch
-<d[-_-]b> agreed
-<clem_> I'm hoping the fact that we promise to let master go by the end of may will make it easier on contributors this time around since they'll know how long they have to wait
-<fpqc> so do you guys have any big features planned in the distant future?
-* mockturtl (mockturtl@SpotChat-b5j3rh.res.rr.com) has joined #linuxmint-dev
-<d[-_-]b> fpqc: how bout checking out our new dev blog
-<clem_> oh yes, there's plenty of ideas :)
-<fpqc> or is it just bugfixing and GNOME compatibility stuff for the foreseeable future
-<clem_> that's never been a problem
-<fpqc> d[-_-]b, I read the devmeeting chat logs
-<clem_> Any other reaction on the topic of 1.8?
-<fpqc> clem, well mtwebster was talking about forking gnome-settings-daemon once and for all
-<fpqc> but what's the link to the blog
-<fpqc> I only see the thing that is announcing the latest LMDE release
-
-<clem_> ok, next topic: General questions
-<d[-_-]b> fpqc: it's not really out in the wild yet
-<clem_> gsd is likely to get forked for cinnamon 2.0
-<fpqc> yeah, that's what mtwebster said
-<clem_> using gsd brings a lot of issues...
-<fpqc> oh shit wait this is the dev meeting isn't it
-<fpqc> sorry for disturbing you guys
-<clem_> first, gsd is tightly linked to a particular version of GNOME..
-<AlbertP> fpqc: We're not doing such invasive things just before 1.8 release. and yes this is the dev meeting.
-<clem_> gsd 3.6 and gsd 3.8 don't talk the same language.. and it's making it hard for us to ship Cinnamon
-<fpqc> I like to read these after they happen, and since I'm not a dev, I don't want to disrupt
-<fpqc> so bye
-<clem_> then, there's the fact that gsd is made for GNOME.. not Cinnamon..
-* Oscar799 has quit (Quit: Leaving)
-<fred> clem_: PM
-<clem_> so it calls particular gnome components by their name and uses particular dbus services which we conflict with
-<clem_> that's a problem for MDM, cinnamon-screensaver etc..
-<AlbertP> clem_: well you know I'm not too fond of forking, but gsd does not have much upstream dependencies that are known to break. I think we're pretty safe with our own fork of the program as long as we get such conflicts solved.
-<clem_> forking gsd 3.6 into csd 2.0 will be easy and solve a huge amount of problems, it will also simplify the work on screensaver, control-center and make it easier to ship cinnamon on different distros and for user to run both gnome and cinnamon on the same computer
-<City-busz> I think that gsettings-desktop-schemas needs to be forked also, at least partially
-<mtwebster> we'd probably wrap that right into csd
-<mtwebster> eliminate that package
-<AlbertP> this time I agree with forking but I don't know how bad gsettings-desktop-schemas is.
-<clem_> we got into cinnamon because we knew what we wanted and we knew we could get it done, every time we fork something we'll consider whether it makes our DE better and whether we have the resources to take on more
-<AlbertP> mtwebster: I agree with you this time.
-<clem_> in the case of GSD, we'll need to look at it in-depth before making a final decision, but it already makes a lot of sense to consider forking it
-<City-busz> e.g. I had to aply some downstream patches in Arch Linux, because some settings were removed/renamed in 3.8: https://projects.archlinux.org/svntogit/community.git/tree/trunk/idle-delay.patch?h=packages/cinnamon-control-center
-<clem_> it's one component we use a lot which is not backward compatible, and doesn't do exactly what we want
-<clem_> it's also quite simple technically afaik
-<d[-_-]b> clem_: concerning mintflash: it's still 11.0 in mint 13, right? will this get fixed any time soon?
-<clem_> d[-_-]b: yes, that's on my todo, sorry I didn't get it done yet
-<d[-_-]b> clem_: ok. why do we need mintflash after all?
-<clem_> d[-_-]b: to make sure people get a decent version of Flash
-<clem_> d[-_-]b: Ubuntu got it wrong more than once
-<d[-_-]b> clem_: where's the difference to flashplugin-installer?
-<clem_> d[-_-]b: well initially Ubuntu was shipping the 32bit plugin to 64 users
-<AlbertP> clem_: since there will not be releases in this form beyond 11.2, it's less risky now.
-<clem_> d[-_-]b: and then at some stage they shipped the latest version without testing it
-<d[-_-]b> i have to agree with AlberP
-<AlbertP> clem_: no new major releases coming, only bugfixes: I don't see the point in pinning flash ourselves anymore.
-<clem_> d[-_-]b: when 3D accel was introduced in the plugin all video rendering was blue.. you remember that one?
-<clem_> it's easy to maintain, there's no real advantage in using the very latest
-<d[-_-]b> clem_: i see why it has been introduced. but now as AlbertP says, I don't think we need it anymore
-<clem_> and there's no guarantee Ubuntu will continue to ship it
-<AlbertP> clem_: I very much agree that it was a good thing to pin flash at a well-tested release in the past, but 11.0 is really to outdated now.
-<d[-_-]b> they will stop shipping flash?
-<AlbertP> clem_: if Ubuntu stops shipping it, we can start to ship latest 11.2 the same way we're shipping mint-flashplugin now.
-<glebihan> d[-_-]b, at some point, all Linux distros are likely to have to stop shipping it
-<clem_> who knows, I don't see a point on relying on them when we don't need to
-<clem_> but you've got a point on 11.0, I'll upgrade it asap
-<lars> clem_: can you please write on your TODO that you remove 'nautilus' from mint-meta-cinnamon in Mint 13 Romeo
-<clem_> lars: in backport?
-<lars> yeah
-<clem_> ok
-<lars> clem_: nice :)
-* WildTux (WildTux@SpotChat-q30gvd.dynamic.mundo-r.com) has joined #linuxmint-dev
-<lars> clem_: and does the flash 11.2 come in maya-backport or in maya-main?
-<clem_> main
-<lars> good
-<d[-_-]b> has to
-<clem_> any other topics anyone wants to cover?
-<clem_> glebihan: do you want to talk about scapegoating?
-* WildTux has quit (Quit: .)
-<City-busz> could you review my pull request for cinnamon-screensaver? https://github.com/linuxmint/cinnamon-screensaver/pulls
-<glebihan> clem_, I'm fine with my role :)
-<clem_> glebihan: ok
-<clem_> City-busz: yes, I did, I meant to take some time to talk to you about it
-<clem_> City-busz: #14 should get in
-<d[-_-]b> can we have a sweet little minty mascot pleaaaaaaaaaaaase ;)
-<clem_> City-busz: I tested the other 3 together and it caused regressions in Mint
-<mtwebster> penguin drinking a mint julep
-<clem_> City-busz: we need to provide the exec name for the screensaver to activate properly and the simplification of the string handling causes segfaults here
-<d[-_-]b> mtwebster: wearing a hula skirt?
-* blubb has quit (Quit: leaving)
-<clem_> City-busz: I committed a fix in cinnamon itself so we now call cinnamon-screensaver-command --lock, without the away-message argument when the message is empty
-<mtwebster> lol
-<clem_> City-busz: this makes things work well and so we don't need to simplify the string handling anymore
-* Malsasa has quit (Connection closed)
-<clem_> City-busz: of course there's probably still a little bug.. if you feed --away-message with "\n" or even "" for instance, it probably shows ""
-<clem_> City-busz: but for the normal use cases, it works pretty well now
-<City-busz> clem_: I don't agree that the other pathes are not needed
-<d[-_-]b> gotta leave. have a nice day
-<clem_> City-busz: regarding #11 and #12, we need this at the moment. We'll remove all that when GSD is forked of course.
-<clem_> ttyl d[-_-]b 
-<City-busz> at least, please consider merge #11, because it fixes some problem
-* d[-_-]b has quit (Quit: Leaving.)
-<clem_> City-busz: I'll have another look at it and test it on its own
-<City-busz> clem_: okay, thanks
-<clem_> City-busz: you patch it in for Arch atm anyway?
-<City-busz> clem_: yes
-<clem_> ok
-<mtwebster> so we sticking with segfault?
-<City-busz> I have to apply at least #11 to keep the compatibility with gnome-screensaver
-* mtwebster moves to important matters
-<clem_> City-busz: isn't 3.6 expecting "Lock" though, and not "LockMessage"
-<clem_> City-busz: or does it support both already?
-<City-busz> gnome-screensaver supports "Lock" only without any argument
-<City-busz> and if you call the "Lock" method without any argument, than it's not handled by cinnamon-screensaver, because it expects a string argument
-<clem_> why do they need to be compatible though?
-<lars> clem_: Sorry to get on your nerves...but...how is mint15 until now :) ?
-<lars> clem_: problems or alright ?
-<clem_> lars: no critical issues so far
-<lars> ah nice
-<lars> that's good 'cause the nonLTS releases don't have so much attention by canonical now
-<clem_> City-busz: is it for people to be able to run cinnamon with gnome-screensaver in the same session?
-<City-busz> because the 'gnome-screensaver-command --lock' uses the "Lock" method without any argument
-<clem_> yes, but we've no interest in providing a screensaver for shell users here..
-<City-busz> no, it's not for gnome users
-<clem_> if you call gnome-screensaver-command it should be compatible with gnome-screensaver, it doesn't need to work with cinnamon-screensaver
-<City-busz> I don't agree with you
-<clem_> you're talking about a user calling it? or gsd?
-<City-busz> gsd and gnome-session uses the 'gnome-screensaver-command --lock' command
-<AlbertP> City-busz: With cinnamon screensaver, you'd have to use cinnamon-screensaver-command --lock or something like that, instead.
-<clem_> yes, but that works well afaik City-busz 
-<clem_> at least here in 3.6, gsd and gnome-session work with cinnamon-screensaver perfectly
-<City-busz> no, because you replaced the gnome-screensaver-command with a symlink to cinnamon-screensaver-command
-<clem_> yes, that's why it works :)
-<City-busz> but I don't want to conflict between the two packages
-<clem_> why not?
-<City-busz> it's not ideal for users who want to use multiple sessions
-<clem_> it's not going to be ideal anyway until we fork gsd
-<City-busz> and the compatibility can be preserved easily with gnome-screensaver
-<AlbertP> City-busz: I think it's discussed before: if we want to support installing Cinnamon and Gnome Shell next to each other on the same linux system.
-<clem_> yes, it's something we already reviewed for mdm for instance
-<clem_> some components call each others directly and until we control both sides of the communication we need to pretend we're GNOME here and there
-<City-busz> even if you fork gnome-settings-daemon, gnome-session still uses the 'gnome-screensaver-command --lock' in some cases
-<clem_> gnome-session is part of the fork
-<clem_> gsd, gnome-session and there's a schema package as well I think
-<City-busz> then it's okay, if you rename the D-Bus interface also
-<clem_> oh yes, that's the goal
-<clem_> as much as possible we'll use our own gsettings and dbus contexts
-<clem_> the least we've got in common with GNOME DE the better
-<AlbertP> clem_: the gnome-session thing you want to fix, would be the "gnome-session-bin" package in the repo then. "gnome-session" in ubuntu repo, is the Gnome Shell session files.
-<clem_> it's the technology we find value in, not the DE itself, so we've already replaced all visual aspects of GNOME and we need to go a bit further and make sure we control our own configuration and backend services
-<clem_> eventually if we do it right it shouldn't matter whether people run 3.6 or 3.8 and whether they have Shell installed or not
-<clem_> AlbertP: yes
-

meetings/2013.04.29/minutes

@@ -1,16 +0,0 @@
-Topics:
-
-- Follow up on actions
-- 1.8 ETA and Roadmap
-- General questions
-
-Actions:
-
-- @clem: Add rjanja, cobinja to the triaging team
-- @clem, @glebihan, @briand: Talk about pastebin and integration with xchat/DE
-
-Decisions
-
-- Blog name: segfault
-- 1.9 development is frozen until the end of may to focus on bug fixes for 1.8
-- Master will go to 1.9 at the end of may (with 1.8 branching out if additional fixes are needed)

meetings/2013.05.06/log

@@ -1,214 +0,0 @@
-<clem> Welcome everyone to this weekly meeting
-<clem> I'm hoping we'll keep things short today and we won't go over 1 hour in length
-<clem> the topics for today are:
-<clem> - Follow up on actions
-<clem> - Segfault Blog
-<clem> - 1.8 Release
-<clem> - General questions
-
-<clem> Following up on the actions...
-<clem> - @clem: Add rjanja, cobinja to the triaging team
-<clem> --> I didn't get a chance to do that
-<clem> - @clem, @glebihan, @briand: Talk about pastebin and integration with xchat/DE
-<clem> --> Nothing was done on this either :(
-* clem looks at his shoes
-<clem> right.. next topic...
-<clem> Segfault Blog
-<glebihan> it's gonna be quick that way ;)
-<clem> The blog was successfully started
-<clem> it's hosted at http://segfault.linuxmint.com
-<clem> so far we kept a pace of 1 article per day but we only have two active contributors at the moment
-<clem> Any questions regarding the blog before we move on to the next topic?
-* glebihan now looks at his shoes
-<clem> nice shoes glebihan 
-<glebihan> thanks :)
-<clem> right, next topic then ...
-* clem whispers to glebihan, "only kidding, I don't like them" :)
-
-<clem> 1.8 release
-<clem> Cinnamon 1.8.0 was released
-* glebihan doesn't believe clem
-<clem> all packages were labeled 1.8.0
-<AlbertP> muffin too has jumped from 1.1.2 to 1.7.x to 1.8.0 versions.
-<clem> they can now evolve independently on the 1.8.x wave as we fix bugs
-<clem> yes
-<clem> so for instance, we can fix a few bugs in cinnamon and label it 1.8.1
-<clem> and have muffin and all stay at 1.8.0
-<clem> we won't make announcements for these bug fixes minor releases
-<glebihan> none at all ?
-<clem> any question on 1.8? anything you want to see included in 1.8.1?
-<AlbertP> mtwebster's menu pull already got merged?
-<mtwebster> AlbertP: yes
-<AlbertP> indeed, I see it on github #1958.
-<clem> link?
-<AlbertP> clem: no need, it's merged already.https://github.com/linuxmint/Cinnamon/pull/1958
-<clem> oh yes, that's in 1.8.0 already
-<AlbertP> For Muffin, what do we do with pulls #80 and #82? We should add a [2.0] label if they get postponed.
-<clem> there's a couple of fixes from glebihan coming in 1.8.1 and we're moving background defs to cinnamon-background-properties
-<mtwebster> i don't think 82 should wait for 2.0
-<glebihan> clem, my fixes are packaging fixes, they should be used when you push 1.8.0 into the repos
-<clem> #80 can wait
-<clem> glebihan: we'll probably have 1.8.1 by then
-<AlbertP> mtwebster: indeed I haven't had a response from luyikei yet on this, so we should't merge it right now.
-<clem> #82 we should talk about it when we get a chance
-<mtwebster> https://github.com/linuxmint/nemo/pull/282  i'd like to see in, as technically it's a fix, but not a huge deal
-<glebihan> clem, ok, didn't know when you intended to push
-<AlbertP> clem: label #80 as [2.0], keep #82 for the moment, ok?
-<clem> ok AlbertP 
-<clem> ok mtwebster 
-<clem> I'll check with you later on on this one mtwebster 
-<AlbertP> clem: we should remove muffin suggesting the gnome-session package in the deb packages.
-<glebihan> AlbertP, why ?
-<clem> gnome-session-bin is needed, not gnome-session
-<AlbertP> glebihan: gnome-session is the session of Gnome Shell. gnome-session-bin is the gnome session manager which we're using.
-<glebihan> ok
-<clem> do you want to make a pull AlbertP? or glebihan you want to commit that quickly?
-<glebihan> as a matter of fact, shouldn't we consider getting rid of the muffin package at some point ?
-<clem> yes
-<clem> but in the future :))
-<AlbertP> clem: we'd better have it recommend Cinnamon instead of a gnome shell package.
-<glebihan> clem, I can do it. So I should just replace gnome-session with gnome-session-bin right ?
-<clem> glebihan: gnome-session-bin would be a depend I think
-<glebihan> ok
-<clem> glebihan: it's cinnamon which should depend on gnome-session-bin really
-<AlbertP> clem & glebihan: a dependency of cinnamon, not of muffin. Muffin is just recommending it.
-<glebihan> err
-<glebihan> no
-<glebihan> muffin shouldn't depend on gnome-session-bin, recommend is correct I think
-<glebihan> same for cinnamon
-<clem> glebihan: although technically yes, you don't "need" it
-<clem> glebihan: you only need it to use the cinnamon session def
-<AlbertP> I'd rather have Muffin recommend cinnamon, then cinnamon would depend or recommend gnome-session-bin.
-<glebihan> AlbertP, no, as long as we have the muffin package, it should recommend gnome-session-bin as well
-<glebihan> AlbertP, muffin can be run without cinnamon, it shouldn't count on what cinnamon defines as dependencies
-<clem> glebihan: muffin doesn't provide its own session
-<clem> glebihan: anyway we don't even install muffin...
-<glebihan> clem, exactly why I think we should get rid of it
-<clem> :))
-<clem> ok, anything else in regards to 1.8?
-<AlbertP> glebihan: I think this dependency was intended to have mutter recommend the whole gnome session including the Shell.
-<glebihan> so... remove gnome-session recommends in muffin and add gnome-session-bin recommends on cinnamon ?
-<AlbertP> Cinnamon also has some pulls that would need to be marked [2.0].
-<AlbertP> glebihan: for Muffin, remove it indeed please; I will take a look what cinnamon's depending on currently.
-<AlbertP> glebihan: gnome-session-bin is currently not mentioned at cinnamon's dependencies/recommends, so feel free to add it somewhere in debian/control.
-<clem> glebihan: yes
-<AlbertP> I think we'd mark Cinnamon #1953 as [2.0] too, https://github.com/linuxmint/Cinnamon/pull/1953
-<clem> yes
-<clem> and 1907
-<AlbertP> and #1968 is 2.0 too? I wasn't certain for this one.
-<clem> yes
-* GitHub100 (GitHub100@SpotChat-ddhug2.rs.github.com) has joined #linuxmint-dev
-<GitHub100> [muffin] glebihan pushed 1 new commit to master: http://git.io/nnmU2w
-<GitHub100> muffin/master 82cecd8 Gwendal Le Bihan: Remove useless recommends
-* GitHub100 (GitHub100@SpotChat-ddhug2.rs.github.com) has left #linuxmint-dev
-* Testing567 (Testing567@SpotChat-uprfnl.dyn.optonline.net) has joined #linuxmint-dev
-<AlbertP> And Muffin shouldn't suggest gnome-control-center anymore, shouldn't it?
-<clem> no
-* satellit_e has quit (Ping timeout: 121 seconds)
-* GitHub4 (GitHub4@SpotChat-ddhug2.rs.github.com) has joined #linuxmint-dev
-<GitHub4> [Cinnamon] glebihan pushed 1 new commit to master: http://git.io/EO2iuw
-<GitHub4> Cinnamon/master d619677 Gwendal Le Bihan: Add recommends on gnome-session-bin
-* GitHub4 (GitHub4@SpotChat-ddhug2.rs.github.com) has left #linuxmint-dev
-<AlbertP> clem & glebihan: I'll remove the gnome-control-center suggestion.
-<clem> ok
-<glebihan> AlbertP, I'll do it while I'm at it
-<clem> muffin isn't used so it's no big deal, but you're right, it shouldn't
-<AlbertP> glebihan: I already have the file open here, so no need to.
-* Garmine (Garmine@SpotChat-mt1omi.pool.telekom.hu) has joined #linuxmint-dev
-* GitHub130 (GitHub130@SpotChat-ddhug2.rs.github.com) has joined #linuxmint-dev
-<GitHub130> [muffin] glebihan pushed 1 new commit to master: http://git.io/iWH3Dg
-<GitHub130> muffin/master dd7d9ce Gwendal Le Bihan: Remove useless suggests
-* GitHub130 (GitHub130@SpotChat-ddhug2.rs.github.com) has left #linuxmint-dev
-<glebihan> AlbertP, too late
-<glebihan> :)
-<AlbertP> ok.
-<clem> anything else on 1.8?
-<clem> any "General Questions"?
-<mtwebster> clem: a few spices website things
-<clem> ok
-<mtwebster> another reminder to remove your applets and desklets that are already in cinnamon :)  and, maybe improve the developer side of it, like notifications for comments
-<mtwebster> because we'll certainly have people complaining to devs to fix their stuff that doesn't download properly from cinnamon settings
-<clem> which one you want to see removed in particular?
-<mtwebster> clem: any that are duplicated in cinnamon already.  for instance, the photo desklet online is older than what's in cinnamon
-<mtwebster> the one we package uses the settings api, the one on spices doesn't
-<mtwebster> yet the online one shows as an upgrade
-<mtwebster> so it would be confusing
-<clem> gone
-<clem> clock and launcher gone as well
-<mtwebster> ok
-<mtwebster> i think there area  few applets but maybe you don't own them
-<mtwebster> they have the @cinnamon.org uuid though
-<clem> nightlife mint version gone
-* DarkEra (DarkEra@SpotChat-ep7sqb.access.telenet.be) has joined #linuxmint-dev
-<AlbertP> clem: I think we should mark gnome 3.8 compatibility pulls as [2.0] too.
-<AlbertP> muffin#81 and Cinnamon#1888
-<mtwebster> recent documents, trash, a11y applets
-<clem> is recent in cinnamon?
-<AlbertP> clem: yes it's in 1.8 at least
-<mtwebster> clem: yes all those are
-<AlbertP> clem: the 1.8 translation of Applets in Dutch is horrible! Let me correct that before Mint 15 please.
-<mtwebster> hehe
-<clem> AlbertP: that's in LP
-<AlbertP> clem: I know, but I thought I'd let you know then you can pull new LP translations into cinnamon before the mint 15 release.
-<clem> I don't see recent in cinnamon...
-<clem> AlbertP: oh yes, I will anyway
-* blubb (blubb@SpotChat-6f0pqe.hsi7.kabel-badenwuerttemberg.de) has joined #linuxmint-dev
-<glebihan> clem, https://github.com/linuxmint/Cinnamon/tree/master/files/usr/share/cinnamon/applets/recent%40cinnamon.org
-<clem> it's there alright..
-<clem> oh ok.. it was hidden by the one I downloaded :))
-<clem> hehe, good point to illustrate the problem :)
-<clem> ok recent, trash, a11y are gone
-* satellit_e (satellit@SpotChat-ub2.d9o.0.72.IP) has joined #linuxmint-dev
-<clem> mtwebster: notifications on comments, yes, but that's for later
-<clem> anything other questions/remarks?
-<mtwebster> i think 1.8 came together nice in the end
-<clem> yes, it's a bit about the bumpmaps
-<clem> a "pity" sorry
-<AlbertP> do we really need to depend on libgnome2-common?
-<clem> it provides... /usr/share/gconf/schemas/desktop_gnome_background.schemas
-<clem> interesting :)
-<clem> and /usr/share/gconf/schemas/desktop_gnome_peripherals_mouse.schemas
-<glebihan> that feels a bit outdated :)
-<AlbertP> clem: huh? I don't see that file in "apt content libgnome2-common" on Mint 13.
-<AlbertP> clem: oops I did apt contains libgnome2-common instead.
-<AlbertP> gconf schemas can be thrown away if you ask it me.
-<clem> we can probably get rid of the dep
-* Oscar799 has quit (Quit: Leaving)
-<AlbertP> glebihan: I'll remove this dep from muffin ok?
-<mtwebster> speaking of dependencies, i'm gonna start having a look at cinnamon-s-d
-<glebihan> AlbertP, ok
-<clem> there's three things I'm worried about for Mint 15
-<clem> 1. DVDs don't play (probably something small)
-<clem> 2. MDM was fixed in regards to freezes but you're scaring me here on that glebihan :)
-<clem> 3. The super-awesome fly-through-the-sky MDM theme which was going to make everyone ditch Windows for Linux Mint relies on WebGL and doesn't work on all specs :(
-* GitHub116 (GitHub116@SpotChat-ddhug2.rs.github.com) has joined #linuxmint-dev
-<GitHub116> [muffin] AlbertJP pushed 1 new commit to master: http://git.io/_eAm7w
-<GitHub116> muffin/master 9944ab3 Albert Pool: Remove libgnome2-common dependency
-* GitHub116 (GitHub116@SpotChat-ddhug2.rs.github.com) has left #linuxmint-dev
-<clem> I'm planning to upload my ISOs for QA on Wednesday night
-<clem> hopefully everything will be fixed by then :)
-<clem> aiming for mid-month for the RC
-<AlbertP> clem: where's that MDM theme?
-<mtwebster> yeah webgl doesn't work on my quadro 2000 - apparently good enough for engineering 3d models, but not clouds
-<mtwebster> i was pissed
-<clem> AlbertP: in mint-mdm-themes
-<mtwebster> it barely runs on a sandybridge
-<mtwebster> like 4 fps
-<clem> mtwebster: I'll try to get a version of that same theme without using webGL
-<clem> mtwebster: samriggs animated themes run fine in Virtualbox without 3D accel, whereas the cloud theme doesn't
-<clem> mtwebster: his animations are 2D though
-<mtwebster> ah
-<clem> mtwebster: still, stuff moves in the background, people notice, that's the main thing really
-<AlbertP> clem: on mint 15? Don't see a cloud theme on Mint 14 mdm themes.
-<clem> AlbertP: Mint 15
-<mtwebster> AlbertP: there's a forum thread that he uploaded it to as well
-<clem> AlbertP: v1.0.8
-<mtwebster> lemme find it
-<clem> http://forums.linuxmint.com/viewtopic.php?f=25&t=126979
-<clem> Alright, we managed to fit the meeting without one hour for the VERY FIRST TIME! :)
-<mtwebster> yeah that
-<clem> congratulations everyone
-<mtwebster> lol
-<clem> and many thanks for being here
-<clem> the minutes and logs will be uploaded shortly, see you all next week for the next meeting ;)
-

meetings/2013.05.06/minutes

@@ -1,13 +0,0 @@
-Topics:
-
-- Follow up on actions
-- Segfault Blog
-- 1.8 Release
-- General questions
-
-Actions:
-
-- @clem: Add rjanja, cobinja to the triaging team
-- @clem, @glebihan, @briand: Talk about pastebin and integration with xchat/DE
-
-

meetings/2013.05.13/log

@@ -1,228 +0,0 @@
-<clem> - Follow up on actions
-<clem> - Mint 15 RC
-<clem> - General questions
-<clem>  
-<clem> Actions:
-<clem> - @clem: Add rjanja, cobinja to the triaging team
-<clem> --> This wasn't done. I didn't really get the change to catch up with either of them yet.
-<clem> chance
-<clem> - @clem, @glebihan, @briand: Talk about pastebin and integration with xchat/DE
-<mtwebster> i'm here sorryu
-* glebihan whistles
-<clem> --> This is a low priority, nothing was done and it doesn't look like it will be done in time for Mint 15
-<clem> I'll remove this action and add it the list of points to look at for Mint 16
-<clem> Next topic: 
-<clem> - Mint 15 RC
-<clem> There's a few minor issues but the 4 ISOs were approved for an RC release today
-<cobinja> 4 isos? for cinnamon, mate and those for for 64 and 32 bit?
-<clem> yes
-<clem> it takes roughly 2 days for them to sync to all mirrors and for the announcements to be prepared, so we'll probably see them out publicly on the 15th
-<clem> the most sensitive/vulnerable part of the system I think is MDM
-<cobinja> that leaves 16 days for testing (if Final is to be released in May)
-<AlbertP> clem: can the keyboard shortcut for lock screen get fixed before final release?
-<clem> it stops plymouth, it launches Xorg, it handles the session process etc.. and it's also one of the projects we maintain that we know the least
-<clem> AlbertP: you mean ctrl-alt-L?
-<DarkEra> what prevents the system from shutting down by the way?
-<AlbertP> clem: not only that, also the lock screen key of HP laptops. Worked right in gnome-screensaver in its default configuration. cinnamon-screensaver does not respond to it, or maybe needs to be configured to respond to it.
-<clem> AlbertP: ctrl-alt-l works fine here on a laptop with C64RC
-<glebihan> works fine here too
-<clem> DarkEra: I don't know, I couldn't reproduce this problem
-<clem> DarkEra: I can restart/shutdown without problems in Mint 15
-<DarkEra> clem, weird. I still have that issue on the netbook
-<clem> one thing I can reproduce easily though.... if you leave MDM on for a little while, it goes to sleep and never wakes up
-<clem> you can still move the mouse but the greeter dies
-<mtwebster> i've seen that also
-<AlbertP> clem: The lock key may need to be added as keyboard shortcut in Cinnamon Settings. Still I'd like it to work out-of-the-box like it did with gnome-screensaver.
-<AlbertP> clem: cinnamon-screensaver in Mint 14 also does not respond to it.
-<clem> ok, that's something we can look at later AlbertP, when we backport it
-<clem> that issue with the greeter dying is a huge problem
-<AlbertP> clem: you mean backport to 14? cinnamon-screensaver is already in 15 where it also has this problem.
-<glebihan> clem, that's if you leave it at the login screen ?
-<clem> glebihan: yes
-<AlbertP> clem: or maybe you can't lock screen on a live dvd?
-<clem> glebihan: best way to test is to open a session, and switch user... 
-<cobinja> cinnamon-screensaver does responf to it in Fedora 18 (Though I forgot how to unlock it, had to kill it via text-login)
-<clem> glebihan: you'll have mdm on tty7 and your session on tty8
-<glebihan> clem, ok I'll have a look
-<clem> glebihan: after a while tty7 will only give you the mouse cursor and a black screen.. you can go back to tty8 with ctrl-alt-f8
-<AlbertP> cobinja: you mean a laptop's lock key?
-<clem> glebihan: the process list indicates that the greeter is defunct at that stage
-<cobinja> no, usual desktop pc
-<cobinja> AlbertP: ^^
-<clem> glebihan: I reproduce it ALWAYS in Mint 15, with both mdmgreeter and mdmwebkit, so it looks like it's to do with the slave
-<glebihan> clem, hmm, one more weird zombie issue with mdm, huh ?
-<clem> looks like it alright
-<clem> we still don't know why this is different in 13.04 but it's a major PITA
-<clem> a bug like this means you can't leave the computer on with the login screen... 
-<clem> if we can't fix it in time for Mint 15 stable, we'll need to use another DM in that release
-<AlbertP> cobinja: a desktop keyboard with lock screen key? I don't mean Ctrl-Alt-L.
-<cobinja> AlbertP: ok, i did mean that
-<clem> that would hurt the momentum of MDM right when it was about to get a bit of a boost with the new webkit greeter and other improvements
-* ilan_ (ilan@SpotChat-48v7tt.dynamic.ziggo.nl) a rejoint #linuxmint-dev
-<clem> AlbertP: the live session is particular
-<clem> AlbertP: I don't know for sure what's different in it, but I'm not sure the screensaver is operation in live mode
-<clem> operational
-<AlbertP> clem:  on an installed mint14 system the key didn't work either. It did work before installing cinnamon-screensaver there.
-<clem> AlbertP: also in live mode you're in a single-user environment with timed login
-<clem> AlbertP: did you restart?
-<clem> AlbertP: you'd need to make sure gnome-screensaver was dead and that the cinnamon-screensaver daemon had taken over the dbus interface
-<clem> another regression that was noted during QA is the lack of add-apt-repository command
-<clem> I'll add that quickly in mintsources
-<clem> the code is already to perform this graphically so it should be easy enough to add support for a command here
-<AlbertP> clem: yes, I have surely restarted... it was only some days later that I found this issue. Anyway I'll install 15rc anyway this week, then I can try it there in an installed, not live, system.
-<clem> there's a couple of other small problems here and there... the really big one is MDM though
-<glebihan> clem, why not use the already existing ass-apt-repository command ?
-<glebihan> *add
-<clem> glebihan: afaik it relies on software-properties
-<gaurav> lol
-<glebihan> clem, indeed, seems there are some weird dependencies involved there
-<clem> glebihan: I've seen issues with trivial repositories (used by mint-local-repository) and things getting mixed up between ubuntu and mint repos
-<clem> glebihan: the removal of software-properties is likely to solve a lot of problems
-<clem> glebihan: it wasn't designed for distros like Mint where the base is maintained by another project
-<glebihan> clem, right
-<AlbertP> clem: mixup is often due to 3rd party apps that want to add the universe or multiverse repository to the 1st line of sources.list (assuming that the main Ubuntu repo is there) to download something.
-<clem> AlbertP: we don't use /etc/apt/sources.list either anymore, so that should be solved as well
-<clem> AlbertP: also server-side we accept universe multiverse components, just so errors aren't thrown when that happens
-* blubb (blubb@SpotChat-6f0pqe.hsi7.kabel-badenwuerttemberg.de) a rejoint #linuxmint-dev
-<clem> are there any questions related to Mint 15 RC?
-<gaurav> yeah
-<gaurav> how many RCs will be there?
-<clem> hopefully just 1
-<gaurav> k
-<gaurav> bye
-* gaurav est parti (Quit: Leaving)
-<mtwebster> lol
-<clem> the issue on MDM is quite critical though
-<clem> I'm hoping all symptoms we observed are related..
-<clem> - greeter dying after a while
-<clem> - mdm unable to open new X on other tty
-<clem> - loss of sound until reboot
-* leigh123linux (kvirc@SpotChat-gvd8j4.dsl.as9105.com) a rejoint #linuxmint-dev
-<clem> - inability to start greeter
-<clem> we're in a difficult situation because the legacy MDM code does not work with 13.04
-<clem> something there is different at the very base level (select() calls don't behave like they did in the past)
-<clem> so it's not even a case of backtracking to the previous MDM and holding new features away from the new Mint
-<clem> we can only go forward here or look at alternatives
-<clem> and there aren't many...
-<leigh123linux> clem: lightdm
-<clem> lightdm is not configurable and misses important features
-<clem> the last time I reviewed it you couldn't even select your language
-<leigh123linux> clem: It's still the same
-<leigh123linux> There aren't many go dm's 
-<leigh123linux> ^good
-<clem> the two advantages of lightdm is that it can look good (it takes no effort to make Mint greeter based on the Ubuntu one) and we can assume it will work well.. since upstream Ubuntu and even Kubuntu are using it as well
-<glebihan> clem, about how would you say it takes for the greeter to die ?
-<glebihan> how *long*
-<clem> glebihan: on the laptop here about 10 minutes
-<clem> glebihan: the screen goes black, the mouse cursor stays
-<glebihan> k
-<AlbertP> select() is a call from the C library (libc6). It's very unlikely for libc to break existing userspace programs.
-<clem> I know AlbertP, I'm very intrigued by it
-<glebihan> AlbertP, it wouldn't be the only thing broken I've seen in libc6 2.17
-<AlbertP> clem: the manpage says select can in some cases report false positives
-<clem> AlbertP: all I know is that this code is inherited from GDM 2.20 (2008 or so) and it's been working great all the way to 2012... comes 13.04, it doesn't work anymore, forked processes go zombie, they're not ack'd to die anymore
-<clem> AlbertP: I don't know what's changed in 13.04 that causes that, but it's been a huge issue for MDM
-<clem> AlbertP: we fixed most of it, but as you can see we're not done yet
-<glebihan> clem, here (on my LMDE laptop), the greeter dies completely, no zombie, no black screen with a remaining cursor
-<clem> glebihan: and then what happens?
-<glebihan> I'll try on olivia after the meeting to see if it's the same
-<clem> glebihan: does the slave start a new one?
-<glebihan> clem, no
-<glebihan> clem, it just switched back to my opened session, the tty where mdm was running was left empty
-<clem> glebihan: ok same here, but it's defunct
-<clem> glebihan: i.e. session on tty8, defunct greeter on tty7, new greeter (after I switch user again) on tty9
-<glebihan> then it's slightly different, here when I switch user again, it re-uses the same tty
-<clem> glebihan: yes, I guess the main difference is that in 13.04 the greeter's death isn't ack'd by the slave
-<glebihan> but I guess that's the difference we've been observing between quantal and raring 
-<clem> glebihan: yes, it looks like a waitpid problem
-<clem> glebihan: still... from a design point of view, why would the greeter have to die?
-<clem> glebihan: shouldn't it wait until you log in?
-<glebihan> clem, there's definitely something wrong in mdm there
-<clem> glebihan: yes, it looks like there's a design issue as well as a waitpid one (the latter affecting raring only)
-<glebihan> clem, I'll have a closer look at it after the meeting
-<AlbertP> I agree, I don't think we can get this issue fixed instantly so let's discuss other matters first.
-<clem> ok
-<clem> any other questions re-Mint 15 RC?
-<clem> FlexiReapDelayMinutes=5
-<clem> And after how many minutes should we reap the flexible server if there is no
-<clem> # activity and no one logged on.  Set to 0 to turn off the reaping.  Does not
-<clem> # affect nested flexiservers.
-<clem> ^^ that looks suspicious :)
-<glebihan> indeed
-<clem> if turning it to 0 means we're rid of the problem for Mint 15 and we've got 6 month to design this a bit better, I think we should consider it :)
-<clem> I'll test that after the meeting too :)
-<clem> ok, next topic.. General questions
-<clem> is there anything anyone wants to address or talk about?
-<mtwebster> clem: we may need to implement a last minute feature in cinnamon
-<mtwebster> in fact i'm pretty sure we do
-<mtwebster> there was a muffin change some time back that moved a bunch of window types into the toplevel window group.  it has spawned numerous issues, mostly resulting in unresponsive panel in many situations
-<clem> yes
-<mtwebster> it was at the time to make sure ime/ibus popups for text entry showed up properly
-<clem> we moved DND away from that group right?
-<glebihan> clem, yes but it's not enough
-<clem> ok
-<mtwebster> clem: yes, but there are issues with notifications, as well as override windows - basically we need to revert that whole echange
-<glebihan> clem, there's a pull request from AlbertP to completely revert that commit
-<clem> oh boy...
-<mtwebster> and implement a cinnamon/clutter-based ime popup
-<clem> to replace the gtk one?
-<mtwebster> clem: yes
-<clem> can't we make the gtk one work?
-<mtwebster> clem: i did a lot of testing on it, the gtk popup is classified as window type "normal" by the program
-<clem> ok
-<mtwebster> if they properly classified it with the X server it wouldn't be a problem
-<mtwebster> like popup, etc..
-<AlbertP> clem: yes. We've had some discussion about it (feel free to call it an argument) and it became clear that we need to do it the same way Gnome Shell did it: our own popup.
-<clem> can we identify it via its title or something else?
-<clem> or its appname
-<mtwebster> clem: no - i tried all that
-<mtwebster> 'main.py'
-<clem> ah ffs :))
-<mtwebster> you wanna gamble on that? :)
-<AlbertP> but... how would other window managers (not forked off mutter) get this on top then?
-<AlbertP> I assume there must be some DE where the gtk popup is working.
-<cobinja> other wm's don't have that kind of window grouping as we do (since our UI is not in an X11 window)
-<glebihan> AlbertP, our problem comes from clutter and the chrome used for panels/menus/..., other DEs have no problem with that
-<AlbertP> OK.
-<clem> just to confirm, ibus is needed to input non-latin chars, like for instance if you want to write Kanji or something?
-<mtwebster> clem: correct - i have it set up and working on my pc
-<mtwebster> you hit the hotkey, then double-tap space, and a popup appears
-<clem> and this gtk popup is provided by the ibus guys?
-<mtwebster> with options
-<AlbertP> clem: I'd also consider merging #1995 https://github.com/linuxmint/Cinnamon/pull/1995
-<cobinja> there's a mutter/muffin window type called "override_other" which is used for all windows that specifically say "override_redirect" and are not of a type that is "override-redirect" by default. when using "override_other" we throw away the original type and therefore can't know, which windows can go to top window group and which don't.
-<mtwebster> i think so - i followed some directions i found online, i'd have to retrace my steps.  afaik, sudo apt-get install ibus
-<clem> it uses dbus to pop up?
-<clem> AlbertP: ok
-<mtwebster> cobinja: the problem is the original type of this popup is 'normal' - based on the x type atom
-<cobinja> yeah, right, there was that problem, too
-<clem> mtwebster: so what's the solution then? we pull the commit the shell guys did to implement their own popup?
-<AlbertP> clem: it's not as easy as that, keyboard.js changed a lot upstream
-<clem> mtwebster: we end up with a clutter popup which intercepts the dbus call to the gtk popup?
-<mtwebster> clem: i think it's that or we fork the gtk provider.  either one is quite a bit of work
-<mtwebster> the cinnamon solution is less so i think
-<clem> what happens right now?
-<clem> I mean, if you use ibus with cinnamon 1.8
-<mtwebster> exactly right now, it pops up like it should
-<clem> so what's the problem?
-<mtwebster> but other insidious things are broken
-<clem> like what for instance?
-<mtwebster> frozen panels from notifications
-<mtwebster> frozen panels from fullscreen apps
-<cobinja> remmina
-<glebihan> steam
-<mtwebster> remmina is useless
-<mtwebster> if you go to fullscreen mode
-<mtwebster> gtk-recordmydesktop (just an example)
-<clem> I see..
-<AlbertP> those are OVERRIDE_OTHER windows too.
-<mtwebster> clem: i haven't looked closely at the gnome-shell solution yet, but i assume it intercepts like you said
-<mtwebster> and we get a boxpointer popup
-<clem> well, we can put that in 1.8.x when we have a working solution
-<clem> it's a bug fix more than a feature really
-<clem> we'll need to test it heavily though
-<mtwebster> i was going to volunteer since i have ime working already
-<mtwebster> you can use it regardless of what locale you're on
-<clem> ok
-<clem> I'm going to focus on MDM
-<clem> thanks everyone for being here and see you all next week :)

meetings/2013.05.13/minutes

@@ -1,12 +0,0 @@
-Topics:
-
-- Follow up on actions
-- Mint 15 RC
-- General questions
-
-Actions:
-
-- @clem: Add rjanja, cobinja to the triaging team
-
-
-

meetings/2013.05.27/minutes

@@ -1,296 +0,0 @@
-Topics:
-
-- General questions
-
-Actions:
-
-- @clem: add dependencies to Mint packaging for cinnamon in 1.8.x
-- @clem: update nemo's translations in 1.8.x
-- @clem: check all pull requests and finalize 1.8.x before 1.9 starts on the 1st June.
-
-Logs: 
-
-<clem> Welcome everyone to this week's meeting
-* autarkper (pang@SpotChat-hdol0m.cust.tele2.se) a rejoint #linuxmint-dev
-<clem> there are no defined topics for this week
-<glebihan> hi 
-<autarkper> hi
-<clem> there's a couple of things I'd like to talk about though...
-<clem> 1. l10n quality checking
-<clem> 2. package dependencies in cinnamon
-<clem> 3. start of 1.9 development
-<clem> I'll tackle them in reverse order ... :)
-<clem> #3... as promised, we'll start developing 1.9 on the master branch on the 1st of June
-<clem> this week-end basically
-<clem> so if you're already bored and waiting for this to happen, it's only a matter of days :)
-<clem> #2, regarding dependencies... the biggest issue imo is the fact that cinnamon doesn't depend on cinnamon-common
-<clem> and that some muffin packages necessary for cinnamon to work aren't in the deps either
-<clem> I think that's something we should fix in 1.8.x
-* AlbertP (albert@SpotChat-aofquv.solcon.nl) a rejoint #linuxmint-dev
-<clem> #1, regarding l10n... we have bad translations in Nemo (in Turkish) and that makes Nemo segfaults when Turkish users copy files...
-<clem> ideally we would test the quality of po or mo files within our packaging and the packages would not build if a problem was found
-<clem> that's something we can address in 2.0, and in the meantime Nemo should get newer translations in 1.8.x
-<clem> I'm putting two actions on myself:
-<clem> - adding dependencies to Mint packaging for cinnamon in 1.8.x
-<clem> - updating nemo's translations in 1.8.x
-<clem> that's it from me :)
-<clem> any comments? questions?
-<mtwebster> clem: are you talking about make some sort of parse tool to check translation files?
-<clem> mtwebster: yes, either that or using a gettext tool (if there's one that's suitable)
-<clem> mtwebster: the main thing would be for arguments to match
-<mtwebster> ie decompile .mo then check result file for validity
-<clem> mtwebster: for instance yes
-<d[-_-]b> can't you simply grep that?
-<clem> d[-_-]b: msgunfmt produces the po output afaik
-<clem> I'd also like to simplify how we package translations...
-<clem> it's a real pita to update each package like that
-<clem> in Mint none of the tools ship with their translations, they all use mint-translations
-<clem> in Cinnamon, we've got translations in nemo, in cinnamon, etc etc... and the more tools we support the more work that's going to be
-<d[-_-]b> clem: well you could use a tool that allows translators to push translations into version control directly
-<clem> d[-_-]b: you'd still need to bump the versions and package it up
-<clem> d[-_-]b: you'd lose the ability to freeze content too
-<clem> that's a question we don't need to ask ourselves right now... but within the 2.0 cycle, we should consider whether it makes sense to simplify l10n
-<d[-_-]b> then how do other projects handle it?
-<clem> the way we do now
-<clem> it's tedious though
-<clem> when I upgrade translations, I basically take them from LP and update nemo, cinnamon, mdm, mint-translations
-* DarkEra est parti (Quit: Leaving)
-<clem> and that's ok... but tomorrow if I need to do it for each cinnamon component (ccc, csd, screensaver, etc etc..), I don't know...
-<clem> at some stage I don't really care about people running nemo 1.6 with cinnamon 1.8 or running nemo without cinnamon
-<clem> at some stage it might make more sense to simply have cinnamon translations, and all cinnamon components use the cinnamon gettext domain
-<d[-_-]b> so if you could just upgrade the version control with a single click that would make things easier? i'm not sure bout putting everything together
-<AlbertP> I'm sorry but I need to help somebody else with a computer problem. I have to go now.
-<clem> the only gain we get from having it the way it is now, is that all components include their own translations... and are thus usable individually
-<clem> that's not something we should really care about though, since they were developed for the sole reason to make cinnamon better
-* AlbertP est parti (Quit: Ik ga weg)
-<d[-_-]b> i personally would prefer to keep it that way. i would find it weird if someone decided to use nemo on unity and can't because translations are missing
-* Oscar799 est parti (Quit: Leaving)
-<clem> d[-_-]b: they could
-<glebihan> d[-_-]b, translations wouldn't be misssing
-<clem> d[-_-]b: but it would show up in English
-<clem> d[-_-]b: or they'd have to install cinnamon as well (which is already the case I think)
-<d[-_-]b> now who of you is right?
-<glebihan> d[-_-]b, they would have to install cinnamon-translations (or something like that)
-<d[-_-]b> glebihan: i see. seems not right to me in a way
-<clem> d[-_-]b: why not?
-<glebihan> d[-_-]b, as clem mentioned, we're developing as a part of cinnamon, if some people want to use it outside of cinnamon, that's their choice
-<glebihan> developing *nemo*
-<d[-_-]b> because you will have to install things you don't really need
-<glebihan> if it's only a translations packages, I don't see what the problem is
-<d[-_-]b> glebihan: i know. but thinking what might happen sometime in the future. let's say people decide to fork certain stuff
-<glebihan> d[-_-]b, let them deal with that then
-<clem> d[-_-]b: indeed, but we've never portrayed any of the cinnamon components as independent software developed for the Linux community
-<briand> fwiw, i agree...  seems to make more sense to do the translations once, rather than for each and every component
-<clem> d[-_-]b: in a way we let cinnamon be portrayed like that, but not nemo, not the cinnamon-screensaver (which even wears the name)
-<clem> so if tomorrow I hear some unity users replaced gnome-screensaver with cinnamon-screensaver, that's great.. but they're on their own
-<clem> because I won't have them in mind in my design
-<clem> that's not a responsibility we ever accepted
-<briand> like glebihan said, they just download/install cinnamon-translations as well, and they should be fine in that regard
-<clem> note also that this is mostly a packaging thing
-<d[-_-]b> clem: but it's only to make life easier right? if there was a chance to develop everything with its own translation at the same amount of work you would do that?
-<clem> Mint might use cinnamon-translations while fedora say, might continue to ship translations as part of nemo/cinnamon-common/ etc...
-<clem> d[-_-]b: I wouldn't break things for people without reasons, whether it's within our outside my audience
-<d[-_-]b> clem: ok so the translations will still come seperated (lets say seperated po's)
-<clem> d[-_-]b: updating translations at the moment is ok... I don't do it very often because it's a bit of a pain... but if we continue to develop more tools, at some stage I'll want to factorize
-<d[-_-]b> and no possibility to put them all to packages automatically?
-<clem> d[-_-]b: from a pure pragmatic point of view too... a translation package is an all package... it doesn't need compiling.
-<clem> d[-_-]b: so it's much easier to maintain
-<clem> d[-_-]b: right now for instance I'd much prefer to update cinnamon-translations than to release a new nemo
-<clem> d[-_-]b: from LP to github directly?
-<d[-_-]b> eg
-<clem> d[-_-]b: it can be done from LP to bazaar I think, but I'm not really interested in that
-<d[-_-]b> clem: eg pootle can do that
-<clem> d[-_-]b: I can also automate it on my end, but it's more a problem of maintaining multiple translations than the fact that it's manual
-<clem> d[-_-]b: having new translations should translate as having new translations... not a new nemo, a new screensaver, a new cinnamon etc..
-<clem> anyway, food for thought, let's talk about this later when we get into 2.0
-<d[-_-]b> i totally agree with that. i thought it was if there are nemo-translation and screensaver-translation or just cinnamon-translation
-<clem> any other questions/topics/remarks/comments?
-<d[-_-]b> just a quick note: the missing translations for synaptic are done already. but they don't get reviewed for whatever reason
-<clem> d[-_-]b: in what language?
-<d[-_-]b> german
-<clem> d[-_-]b: wait, synaptic.. we don't maintain these
-<clem> d[-_-]b: that's part of either synaptic or language-packs
-<d[-_-]b> i know. just because i recognised they were missing (that's why i asked mtwebster earlier)
-<clem> ok
-<autarkper> clem: last week I think you said you were going to have a look at https://github.com/linuxmint/Cinnamon/pull/2048, or am I mistaken?
-<clem> autarkper: you're right :)
-<clem> autarkper: I'll add an action on myself for this
-<autarkper> clem: I'm not insisting personally
-<clem> autarkper: hehe :)
-<clem> autarkper: I'll have a look and probably push it to 1.8.x
-<mtwebster> there are a number of others that are probably good for 1.8
-<autarkper> clem: sounds good
-<clem> I'll have a look
-<clem> I'm not as much in a hurry to get them in as before, as you probably know Mint 15 is on its way
-<clem> the ISOs were approved and are syncing with mirrors as we speak
-<clem> so the ETA for these is this week-end, since we start 1.9 on the 1st
-<d[-_-]b> did cinnamon-translations make it in?
-<clem> d[-_-]b: no, that's 2.0
-* acewin est parti (Ping timeout: 121 seconds)
-<clem> d[-_-]b: it's the first time we dicussed it
-<clem> discussed
-<d[-_-]b> discussed what?
-<clem> d[-_-]b: factorizing translations
-<glebihan> clem, you say the ISOs are syncing ? I don't see them on heanet ?
-<d[-_-]b> clem: sorry i don't get it. so the translations eg for cinnamon-settings do not get in because there is no factorization yet?
-<clem> glebihan: they start at pub.linuxmint.com then go onto heanet
-<glebihan> clem, ok
-<clem> d[-_-]b: no, each package contains its own translations right now
-<d[-_-]b> clem: yes. i'm only asking if the translations that were missing for cinnamon got into the new iso's^^
-<d[-_-]b> (not talking about any cinnamon-translations package)
-* acewin (acewin@SpotChat-0te.ap6.217.98.IP) a rejoint #linuxmint-dev
-<clem> d[-_-]b: oh, no
-<clem> d[-_-]b: even the turkish segfault came too late
-<clem> d[-_-]b: they'll be available as updates though
-<d[-_-]b> ok
-<clem> I don't know if you've all followed the feedback on Mint 15 RC, but it's been really impressive
-<clem> I've never seen so much positive vibes personally
-<mtwebster> it should be easy to make sure tokens match up.  I would think launchpad would complain if quotes mismatch
-<mtwebster> but i don't know for sure
-<mtwebster> there's a python lib - polib, that lets you parse through po and mo files, i'm messing with it now
-<clem> some people had no sound, others had no bumblebee, couldn't join hidden essid networks and so on... we had bad critical issues...
-<clem> yet people didn't mind too much
-<d[-_-]b> because it's sexy
-<clem> 1.8 brought its fair share of new features, but I think the big thing here is that it's more tightly integrated than before
-<clem> it's not just a shell anymore
-<clem> nemo isn't just better now, it looks better
-<clem> and there's screensaver, control center modules, desklets... you really feel like you're running a DE
-<clem> even though you aren't... yet
-<clem> mtwebster: in the case of nemo's TR po, I think it was because of quotes..
-<clem> mtwebster: afaik the arguments matched and to me even the quotes looked fine
-<mtwebster> clem: the args are reversed
-<clem> mtwebster: let me find the string..
-<mtwebster> the quotes are fine
-<mtwebster> 38651:msgid "Moving file %'d of %'d (in \"%B\") to \"%B\""
-<mtwebster> 38704-msgstr "Dosya(\"%B\") 'den \"%B\" 'ye  ta..n.yor %'d / %'d"
-<clem> msgid "Moving file %'d of %'d (in \"%B\") to \"%B\""
-<clem> msgstr "Dosya(\"%B\") 'den \"%B\" 'ye  taşınıyor %'d / %'d"
-<clem> hehe :)
-<mtwebster> %B is a custom token, of a string
-<d[-_-]b> mtwebster: why is it done with %s and so on? i know in libreoffice they do it like ($HEIGHT)x($WIDTH). so you can push args around as you like
-<clem> I don't understand why it fails
-<mtwebster> clem: because it's putting an integer where it expects a string
-<mtwebster> and vise versa
-<clem> mtwebster: why?
-<glebihan> because our  l10n strings aren't good
-<mtwebster> the argument list is unchanged (, int, int, string, string)
-<mtwebster> but our tokens in the translated string are string, string, int, int
-<glebihan> we should specify the argument index in the string
-<glebihan> ie %1$s instead of %s
-<clem> well we can name them right?
-<d[-_-]b> look at my post?
-<clem> in python you can %(somename)s
-<mtwebster> not sure
-<glebihan> clem, should be possible, I've never used that, i always use indexes
-* chattr est parti (Connection closed)
-* chattr (regnad_kcin@old.same.place) a rejoint #linuxmint-dev
-<glebihan> d[-_-]b, that's messy
-<d[-_-]b> glebihan: well it avoids the problem.
-<clem> _("%(mystring)s blah %(myint)d" % {mystring: myval; myint: 2})
-<clem> we use dicts in python for that
-<glebihan> d[-_-]b, it's also much more trouble code-wise, when there are native solutions to workround it
-* shantorn (Shantorn@SpotChat-6jgom3.cust.wildblue.net) a rejoint #linuxmint-dev
-<d[-_-]b> glebihan: i don't think they invented it on their own like that on libreoffice..
-<clem> actually, my example is broken :))
-<clem> but heh, we use dicts anyway :)
-<glebihan> d[-_-]b, maybe they did, maybe they didn't, it's still messy
-<glebihan> d[-_-]b, that would mean we stop using gettext functions and rely on some replace function
-<mtwebster> regardless how we solve it, we have to make sure translators understand, and have a way to check mo files
-<clem> mtwebster: so you're saying any language where the arguments aren't in the same order is going to produce segfaults if they're of different types?
-<mtwebster> the check utility is simple to do, explaining to translators i dunno
-<mtwebster> clem: yes, it doesn't know any different
-<clem> omg...
-<mtwebster> you're giving it an int where it expects a string
-<mtwebster> it makes perfect sense to me :)
-<clem> you should have been born a computer mtwebster 
-<mtwebster> lol
-<glebihan> clem, but that's because using several arguments in an l10n string without indexes is bad practise
-<clem> segfaulting in the user's face is considered bad manner too :)
-<d[-_-]b> and even if you add indices noone will ever know what will be inserted (you can only guess)
-<clem> right, we need to fix that in 2.0 :)
-<clem> we can't go on using unnamed/unindexed args in the same l10n string :)
-<glebihan> clem, right, but even if the arguments were of the same type, it would still be an issue. There wouldn't be segfaults, but words in the wrong order
-<clem> glebihan: yes, that much more ok though
-<glebihan> clem, agreed
-<clem> progress: 100 out of 34 files were copied so far.. 
-<clem> in the mint tools there are occurences like that...
-<clem> some are named others aren't
-<clem> python doesn't care about types as much though
-<clem> so it's more a problem for translators than for us
-<mtwebster> yeah python just tries to make sense of it
-* autarkper est parti (Ping timeout: 121 seconds)
-<clem> ok let's tackle these in 2.0, for now I'll update the translations for nemo
-<glebihan> d[-_-]b, they will know just as well as they do now
-<clem> the Turkish translators basically turned their sentence around to match our argument order...
-<d[-_-]b> glebihan: yes. that's part of the problem
-<clem> it probably sounds weird in Turkish now, but at least they'll get to read something :)
-* kaie (kaie@SpotChat-sot7hh.dip0.t-ipconnect.de) a rejoint #linuxmint-dev
-<glebihan> d[-_-]b, well, translating always requires to know where the strings are being used, you can't just blindly translate without seeing the applicaiton
-<clem> until another translator "fixes" it and it segfaults again :)
-<glebihan> d[-_-]b, I don't see that as a problem, it's just how it is
-<d[-_-]b> glebihan: it's still slower than if you knew what the arguments mean directly
-<clem> mtwebster: you want to talk about csd?
-<mtwebster> clem: sure
-<glebihan> d[-_-]b, not really, because you often can't know what a sentence means outside of its context (whether there are arguments or not)
-<mtwebster> i've got it operational in mint 15, and it compiles in lmde.  I have branches for nemo, cinnamon, cinnamon-control-center that implement changes to use c-s-d instead of g-s-d
-<mtwebster> i'm going to start work on porting media keys into cinnamon
-<clem> same with people, to be taken within their context... some guys around here don't make any sense outside of the pub for instance, we tried to talk a few times, and we always ended up agreeing we'd meet in the pub instead...
-<glebihan> lol
-<clem> mtwebster: so, one we use csd... other than gnome-session, are we still using any part of GNOME?
-<mtwebster> clem: gnome-desktop is used a great deal - that's mostly libraries though
-<mtwebster> i don't think we need to fork at this point
-<clem> mtwebster: these are utility libs, if they don't change often there's no need to fork them
-<clem> mtwebster: I don't know if they do though
-<clem> if we look at the issues we had with arch/fedora, we're mostly talking GSD... and then after there's regressions in what? gjs? cogl, clutter?
-<mtwebster> i haven't been able to get c-s-d actually start with the session in lmde - i don't know enough about debian though, it seems /etc/xdg/autostart isn't used
-<mtwebster> clutter, gjs so far i think
-<clem> mtwebster: no, it shouldn't use it
-<clem> mtwebster: the session starts components according to their session tags (in their desktop file)
-<clem> mtwebster: I'm definitely having a look at gnome-session to see if we're better off having our own session though...
-<mtwebster> well - it's behaving differently than ubuntu, regardless
-<clem> mtwebster: not necessarily a fork of gnome-session.. it could be a simple binary or even a script to start the cinnamon session
-<mtwebster> for now, I'm having cinnamon call itself "X-Cinnamon" in the session startup, that prevents gnome-s-d from starting
-<mtwebster> then in main.c of cinnamon, I re-set XDG_CURRENT_DESKTOP back to GNOME so we get our applications back
-<clem> mtwebster: that's got "ditch gnome-session" written all over it
-<mtwebster> the only regression i've seen is the gnome-keyring stuff
-<mtwebster> i.e. it's asking me to unlock it when i fire up chromium
-<mtwebster> but that's probably something simple
-<mtwebster> and to do with my session name not being GNOME
-<mtwebster> anyhow, i wanted to get a head start on this for 2.0.  and so far it's been a good decision to fork it, imo
-<clem> oh yes, I don't think there's a choice here
-<mtwebster> it'll eliminate a lot of fixes currently in that gnome-3.8 rollup also
-<mtwebster> eliminate the need for i mean
-<clem> it's the weakest point in Cinnamon at the moment, it makes no sense to use the GNOME backend
-<clem> long term it means we're going to have to maintain these configuration tools of course
-<mtwebster> i've got a cinnamon-settings-daemon branch in my nemo, cinnamon, and cinnamon-control-center repos on github
-<clem> so that's more work for us, but we can all agree on the fact that some of them suck, so that's an opportunity to improve things as well
-<mtwebster> yes
-<clem> I wouldn't mind downgrading some actually... the printers module for instance
-<clem> or porting the simple ones to python
-<clem> anyway, we've got 6 months for all that :)
-<mtwebster> i planned on porting media-keys and the OSD popups to cinnamon
-<clem> well, we need to talk about the panel
-<clem> whether we want one or not
-<clem> and what that means to things like OSD and all
-<mtwebster> what panel?
-<clem> a gtk panel that works when cinnamon crashes
-<clem> at the moment it's called gnome-panel
-<mtwebster> oh yeah
-<clem> CSD would run everywhere whereas cinnamon would only work on some specs
-<clem> so there's pros and cons to porting things to cinnamon
-* kaie est parti (Quit: Leaving)
-<mtwebster> how critical is osd if you're in emergency mode though?
-<clem> also, people might want to use CSD with unity
-<clem> :))
-<clem> I'm kidding... :)) I heard the same joke about nemo though
-<d[-_-]b> *not laughing at all :P*
-<mtwebster> well that's perfectly valid :)
-* o0ze (ooze@lookup.failed) a rejoint #linuxmint-dev
-* o0ze est parti (Connection closed)
-<clem> mtwebster: without OSD you cant' see the name of the song you're playing.. I'd say that's pretty CRITICAL! :)
-<glebihan> yes, because : oh my desktop just crashed, I'm in some kind of fallback mode, let me listen to some music while I fix that (and don't you dare telling me I won't see which song is playing)
-<clem> mtwebster: I don't know about you but I'd rather use OSD than Shazam when my computer plays a song I like...
-* d[-_-]b est parti (Quit: Leaving.)
-<clem> anyway, I guess we can discuss this outside the meeting :))
-<mtwebster> lol
-<clem> thanks everybody for being here, see you all at the next meeting ;)