On Wed, Nov 23, 2016 at 5:19 PM, Didier 'OdyX' Raboud <o...@debian.org> wrote: > The TC had an IRC meeting yesterday [0], and I (was) volunteered to wrap up > the different outcome possibilities, which would help forming our opinions. > Not all these options are exclusive, or would need an actual TC decision. > > Here we go: > > A) 'global' stays maintained as it currently is. > > This would imply: > - no new 'global' upstream release before stretch, > - no 'htags removal' warning in stretch, > - possibility for the maintainer (and/or other interested parties) to start > maintaining a 'global6'; this wouldn't offer any guarantee for a more > recent version of 'global' in stretch. This would also imply having two > 'global' packages in certain suites. > > B) A fresher version of 'global' is uploaded to experimental 'soon' > (with or without interested parties' help; with or without a TC decision) > > This would imply: > - any interested party would file (and close) Debian bugs for issues and > regressions (with appropriate severities), to make the 'fitness for a > stable release' assessment easier, and earlier. > > C) After the release of stretch, a fresher version of 'global' is uploaded to > unstable with the explicit goal of making it available in buster. > > This would imply: > - any interested party would file (and close) Debian bugs for issues and > regressions (with appropriate severities), to make the 'fitness for a > stable release' assessment easier. > - after migration to testing, this would make the fresher version of 'global' > available for backporting to stretch-backports. > - the version of 'global' released in stretch could carry 'htags removal' > warnings; > > D) A fresher version of 'global' is uploaded to unstable 'soon', targetting > stretch (with or without interested parties' help; with or without a TC > decision) > > This would imply: > - overruling the 'global' maintainer's decision (§6.1.4, implies 3:1 majority > in a TC vote); > - any interested party (including the maintainer) would file (and close) > Debian bugs for issues and regressions (with appropriate severities), to > make the 'fitness for a stable release' assessment easier. > - that this fresher version of 'global' would reach 'fit for release' status > before the Stretch release. > > E) the 'global' package is handed to other maintainer(s) > > This would imply: > - overruling the 'global' maintainer's decision (§6.1.4, implies 3:1 majority > in the TC vote);
In offline discussions with Wookey, we came to the realisation that reading the various bug reports (including this one) it is not very clear how global (upstream) is structured, the functionality it provides and bits that are holding back the debian update. Gnu Global is a source code tagging system similar in functionality to ctags or cscope. It allows searching for symbol definitions and use in the codebase by splitting the functionality into two steps - * Indexing - This is a offline step where an index of source code symbols definitions and references for a code base is created. This functionality is provided by "gtags" binary (part of upstream global). Indexes (or is it indices?) typically live in the source tree (they don't need to). * Searching - Once the code base is indexed, the indexes can be used to search for symbol definitions as well as query locations where the symbol is referenced. This can be done using the "global" binary (again provided by upstream). Also there are various integrations with commonly used editors - emacs, vim, elvis, etc - that internally invoke global for their symbol lookup requirements. So if you are a developer who would like to use global to navigate your way through a large code base a common way to use it would be to use "gtags" and the editor integration of your choice. In addition to the above mechanisms, upstream also provides "htags" which can be used to generate an HTML version of the index. "htags" uses the index created by "gtags" and the source tree as input and generates html files which allow you to navigate the source code in the browser. By default, htags generates static pages which means you can browse the code in a local browser without requiring a web server. Optionally, "htags" can generate a dynamic index (which reduces disk space usage) but requires an http server setup to be able to serve the pages. In this scenario, you will also need to be able to execute CGI scripts as the symbol lookup is done when serving the http request (as opposed to pre-processed when using static pages). And this last bit (integration with system web server) is the functionality that had security concerns raised by Ron and for which there are patches in the debian package. In recent versions (> 6.4, Apr '15), upstream has dropped support for generating scripts that expect to be written to system cgi-bin folder. As demonstrated by wookey[1], it is still possible to use the dynamic html option as a non-root user by running a web server using higher numbered ports. IIUC, Ron's patch removes the need for htags to write to system cgi-bin (by providing an indirection mechanism for incoming http requests). Serving dynamic source index via system cgi-bin is, IMHO, a small part of the functionality provided by the package and should be seen as such while making any decision regarding the package. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816924#65 > > -- > Cheers, > OdyX > > [0] http://meetbot.debian.net/debian-ctte/2016/debian-ctte. > 2016-11-22-16.59.html