#+TITLE: Meeting minutes: CTAN team at TUG 2015, v1.1 #+AUTHOR: Manfred Lotz, #+LaTeX_CLASS: scrartcl #+LaTeX_CLASS_OPTIONS: [smallheadings,fontsize=10pt,a4paper] #+LATEX: \newpage Meeting on Monday, July 21st 2015: Petra, Gerd and Manfred Meeting on Tuesday, Juy 22nd 2015: Petra, Gerd, Joachim and Manfred * Legal We agreed that we need professional support in order to avoid legal vulerability for ~ctan.org~. - ~ctan.org~ is registered for the TeX User Group. See: ~whois ctan.org~ - Gerd points to an article in c't from March/April 2015. The only one I found is in c't 9/2015, p. 162: /FAQ Datenschutz auf Websites/. Actions: - [X] Manfred to ask Jürgen Fenn for advice, perhaps he knows a lawyer who could help us 2015.08.04: Manfred sent mail to Jürgen Fenn; Gerd on CC - [ ] If we need money for a lawyer we will ask DANTE or TUG for sponsoring * Communication Platform CTAN We agreed to add fields - Public email address of the author - Not yet clear if such an address is author or package bound. Petra and Manfred prefer to have a public email address per author. In this case the entry should go into the ~authors~ file. - Community mailing list - Community URL - URL of ticket system These fields are to be seen as an addition to the already existing ~~ field in XML. However, as long as the upload web form isn't reworked such fields create additional work for the upload managers as many authors surely will mess up the content of those fields (Petra, Manfred). This led us to a discussion of the login feature and the upload form. Gerd wants to simplify the upload form heavily. There are also ideas of providing an API. Gerd mentioned Martin Scharrer who provided something in the past but it doesn't any longer. Perhaps this could be updated to make it work again. However, till now Gerd hasn't been successful in getting in touch with Martin. Action: - [ ] Gerd will provide a much simplified upload form for discussion. * Topics ** Recommendations - Petra doesn't like the name as it implies some bias; she suggest something like /related topics/ - Gerd mentioned that below the title /Recommendations/ there is a line /"Maybe you are interested in the following packages as well"/ which makes it clear that it is no evaluation. Actions: - [X] In the meantime Gerd has changed /Recommendations/ to /Suggestions/. ** Structured Topics Agreed - we will have a topic tree - which is not based on taxonmoy - but should denote attributes and characteristics. - Gerd will manage a tree in the portal - A new scheme of topics have to be agreed upon, and this also requires a session where the upload team has a chance to get familiar with this. - a topic tree shouldn't have more than three levels, otherwise it gets unmanageable for ordinary humans. - then plain topics could be retrieved daily from the portal into the ~topics~ file. - of course this implies a validation of the catalogue before committing such a file into subversion/ - a topic tree could be retrieved daily and put into a file ~topics.tree~ or a similar name. - then the ~also~ field could be removed from XML Actions - [ ] Gerd will further work on this proposal - [ ] which then could serve as a base for a CTAN team meeting discussion * Licenses We agreed that we need to exand the current possibility of specifying exactly one license. We should support - Dual licenses The user of the package has a choice of at least 2 licenses when using the package. - Scoped licenses where there are at least two different licenses covering different areas of the package. Example: lppl1.3 for the LaTeX part of a package and OFL for the font part of a package Gerd suggested if this is too complicated then a simpler scheme could be to list all applicable licenses for a package. Joachim said that determining the exact license situation of a complex package is very complicated, and he is sure that a developer is not able to do this properly if the license situation is complicated. He further pointed out that the most important thing to know is if a package is free (could be distributed) or not. This is also what is important for Karl Berry and Christian Schenk. : Action: No concrete actions planned. Needs further discussion. * Packages ** Remove container packages Packages which contain other packages in its directory. Examples: ~oberdiek~, ~obsolete~. Not discussed much, no decisions made yet. ** Eliminate File Packages Agreed upon that - we want to have a directory for each package - we know that it isn't easy to achieve for existing /file packages/ - One example are Heiko Oberdiek's 94 packages which are all in ~macros/latex/contrib/oberdiek/~. - talked to Heiko who agreed to slowly moving his packages to ~macros/latex/contrib/~. - however this might take time, and his old stuff must be kept because of dependency things till the whole action is completed. - for new packages upload manages won't accept a package without its own directory. - [ ] Manfred will start to migrate /ctan paths/ in the XML files for those packages which on the one hand have ~file="true"~ in the XML file but have already their own directory. ** No version number in package directories - upload manager won't allow that for new packages anyway - [ ] for those packages Manfred will try to change /ctan path/ in XML where this is possible. Action is started and ongoing. As of July 1st we had 594 packages with ~file='true'~ in the ~ctan path~ element. As of August 6th we have still 547 packages. ** Readme Files Main reason for ~README~ was that Apache web server displays ~README~ directly. Discussion about enhancing the ~README~ requirement resulted in allowing - ~README~ - ~README.txt~ - ~README.md~ Gerd's portal can render all those formats. We do not want to allow ~README.html~ as this isn's nicely readable using a command like ~less~ (Joachim's argument). Actions - [X] Manfred to ask at the TeX Live mailing list if there are any objections. Feedback from Karl Berry, Norbert Preining and Lars Madsen positive. - [X] Starting to allow above mentioned formats for uploaded packages - [ ] Website has to be updated to reflect changed policy. ** Proper Title of Documentation - Gerd's suggestion to take the title of the PDF document as #+BEGIN_SRC xml #+END_SRC Here /details/ would be substituted by the title of the PDF document. - Manfred and Petra don't agree as this is a large amount of error prone extra work for them. ** Modification Date for Packages - we agreed that this would be fine - but no solution yet - perhaps this could be incorporated in a new ~version~ element as suggested in the [[#fields][Fields]] section. * TeX Archive under Version Control We agreed this is a good idea. It requires - changing the ~ctan_install~ script - changing the mirroring scripts which injects files into CTAN - if we manage to have the ~.git~ directory at the same level as the ~tex~ directory then outgoing mirroring won't be affected - do we want to include ~./systems~ in version control? - do we want to allow pull requests from others? - do we want to delete ~obsolete~ tree because it is under version control, or do we keep it visible? Actions: needs further discussion * Portal ** Images for Packages and Topics ** Personalized Portal Features Advantage of user registration is that those users (authors and non-authors) have additional benefits. Non authors could vote for a package so that (with a certain number of participants) popular resp. /'good'/ packages could be easier detected. Joachim strongly advised against a mandatory login as from past exerience it could be expected that this will not easily be accepted by the authors which could even mean authors will dismiss CTAN as a package repository. Nevertheless, a login should be advertised as a possiblity for authors by mentioning that a registered user has benefits from that. BTW, a registration is possible for everyone currently. Actions: - [ ] Gerd plans to activate the Login-Link for all pages on ctan.org. However, more tests are required. ** Admin Interface * Catalogue in TeX Archive Gerd wants to check the structure of the XML to see if there is anything of no use which thus could be deleted. One example of a candidate for deletion is the ~also~ field discussed before. Gerd's proposal to replace the ancient HTML pages by a single PDF document wasn't discussed because time ran out. An experiment for this can be found under http://comedy.dante.de/~gene/ctan-book.pdf * Upload ** CGI Upload It was agreed to stop using the old CGI upload form for uploads via the portal Action: - [ ] For this Joachim (when back from vacation) will get in touch with Gerd. ** Fields :PROPERTIES: :CUSTOM_ID: fields :END: Currently, we have two attributes for field ~version~. This is ~number~ and ~date~. Usually ~number~ is something like ~1.0~, ~4.1.3a~ but could be something really strange like for instance ~2015 V2 Level 2~. Date isn't used as much. If used then it could be (not forced, though) something like the date which comes with a version in the package ~dtx~ file. The upload form contains just one field for both. Authors often mess up the contents in some way. Joachim proposed to have just one field for ~version~ in the catalog as the version is something the author should decide upon. This means the upload managers usually wouldn't complain about the content of the version field as long as the version field shows some ~ascending modification~ when the author provides an update. Example: ~1.4.1a~ is reasonable if the previous version was ~1.4.~. Version as it is today: #+BEGIN_SRC xml #+END_SRC New version element: #+BEGIN_SRC xml ... #+END_SRC The only disadvantage is that in case the author provides a date we have no chance to validate the date from an XML point of view. We agreed upon this version. Another possibility is to add an upload date as an attribute. No agreement here, yet. This is something for further discussion. #+BEGIN_SRC xml ... #+END_SRC Actions: - [ ] In the meantime Petra expressed doubts and wanted some further discussion. - [ ] If this is finally agreed upon Manfred will change DTD and XML accordingly. * Hall of Fame Nothing decided.