archive:// support in stable (was: Feature and string break request)



[removing alex, gnome-i18n@ and nautilus-list@ from the CC; we must
include them again for any final decisions that i would like to see at
our meeting.]

release-team members,

so we discuss including support for the archive:// handler in the stable
2.22.x series. there's arguments for and against this.
let me try to summarize and list some stuff from irc today:

      * the underlying archive backend is already in gvfs stable.
      * adding support for this is "just" a desktop file (this also
        means: if people want to test it, they can create the desktop
        file and they're done).
      * it can deprecate file-roller usage for many people who don't
        write in archives. can be a good thing, but not necessarily in a
        stable release.
      * it adds one new string ("Archive Mounter").
      * distros can disable it by --disable-archive.
      * introduces a new gvfs dependency on libarchive.

technically spoken, 2.22.0 did not have the stability that other
"stable" gnome releases had because of many late changes and regression
fixes, so the "stable" argumentation does not fit for gvfs-related
stuff.
feature-wise spoken, 2.22.0 is as feature-frozen as other stable series'
releases, so the "stable" argumentation fits here.

now please other r-t members think of it and come to a pro or con
conclusion within the next days. :)

i myself have become less risk-avers in the last months now that we
pushed libsoup 2.4 (though being criticized by a few affected
maintainers for porting that late to a new API). to me it's sometimes a
question of making the gnome platform more attractive and to keep the
momentum we have hacking on gvfs/gio, so i tend to agree getting this in
for 2.22.1.
i'd however like to see other r-t members' opinions before we announce a
final "yes" or "no".

andre

-- 
 mailto:ak-47 gmx net | failed
 http://www.iomc.de/  | http://blogs.gnome.org/aklapper

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]