https://wiki.debian.org/UpstreamGuide $ sudo apt-get install gobby-infinote $ gobby -c gobby.debian.org debconf14/bof/upstream-guide /------------------------------------------------------------------------ | Discussion summary debdry definition of a sane upstream non-creative upstreams wrt packaging, smart, expressive, declarative packaging systems accept patches [todo pabs] positive recommendations instead of negative ones give reasons for the recommendations requirements analysis idea: packagers guide about talking to upstreams work with other distros on upstream guides - Fedora etc co-ordination with other distro devs helps achieve better results upstream step out of comfort zones - try to do things in other distros encourage communication discourage distro wars encourage upstreams to look at build errors/warnings /------------------------------------------------------------------------ | Food for thought Missing items? [kathey] Grammar, clarity & spelling. mail debian-l10-english after the BoF. waf section is contentious. Cleaning the Tree: (if out-of-tree works, we can rm -rf the build tree, otherwise we need clean targets that remove anything that can be automatically rebuilt, including generated source) Perl: (we like stuff from CPAN, why?) (plugins => see above) Python: (they have a standard way of packaging too) (plugins => see above) (other languages with their own deployment tools): Ruby, nodejs, PHP, Haskell, Go, Rust. reaching out to the Debian teams for them API/ABI stability is a general issue, especially with newer languages language-specific package managers teach upstream communities about API stability communicating benefits of Debian's approach - debops security & Haskell - needs rebuilds of reverse deps master file of doom for testing, unsure for stable issues are about community rather than tools relationships between Debian and upstream various tools to workaround distributions - virtualenv etc points out issues with contributing to debian and ease of packages package managers are for: rapid releases and updates during development various Debian processes are blockers need ways for lowering barriers - PPAs? document that stable is for production language we use for our releases discourages devs from using it ways to get stable system plus a dev env containing newer things OSes without distro package management Branching: (why we maintain ancient versions in stable) (what to do if you think we shouldn't do this) stable-updates way to keep apps out of stable but in testing/backports this is why, good thing because, we accommodate concerns by, describe use-cases interact with the Debian maintainer to avoid dev versions in stable and suggest specific versions for long-term stable maintenance (e.g. common across distributions) and be clear about responsibilities concious choice about release practices checklist of choices timelines may conflict predicatable freezes help co-ordinate release team should remind devs to contact upstream having many versions across different distros is a major pain Upgrades: (converting old system wide data) (converting old user data) this is an upstream area - not Debian specific Downstream Patches: (we need your help in understanding your package) (please add unit tests even for functionality you believe is trivial so we can see if a patch breaks something) External advice: doomed to FAIL guidelines: includes some advice that large successful projects do not heed. Writing a C library: (includes some advice that can be considered controversial) /---------------------------------------------------- | Gobby chat [11:15:12] It's written in Python, and it's controversial for telling people to copy the entire build system into your project rather than using it as a system library. [11:15:56] Seconded: we should explicitly say "you should use one of these handful, and here are best practices for those". [11:41:24] Yes, you definitively need a distro portal for upstream projects (with people from each distro). "Upstream guide" translated into a sort of federated site. [11:43:39] And one of the sections in that federated "Upstream guide" site would be the release cycle graphic for each one of the distros involved. [11:45:31] That *would* be brilliant. (Also, there's a joke in there about "federated" and "Fedora".) [11:45:59] I did not know about that Fedora joke. [11:46:36] adrian15: One does not currently exist; I was suggesting that the term "federated" suggests one. :) [11:48:29] Appstream (Check Cambridge videos) would be a part of it. And, also, you could recycle this distro-common site so that some upstream applications that do not get upstream security updates or something can be updated there. Like a second upstream. But only one second upstream. Not one upstream per distro as it happens right now. [11:49:14] That does seem appealing. [11:54:35] Get developers with new code into Debian? Rename Debian Unstable into something else ? /------------------------------------------------------------------------ | Feedback from an upstream developer Please move "Initial Packaging" into its own wiki subpage. It would make the table of contents more easy to read. At the same time upstream newcomers will be less threatened by the lenght of the document. I think it will be more useful for the upstream developers to have a wiki per language. What I'm talking about is: "Your Build System" section. So that once you enter this section you are asked to choose among the languages (standard, c, java, perl, python,... ) links. Then in each of one the Your-Build-System-Per-Language pages you could reuse a common template (I guess that the common template would match the current "General Considerations"). What I mean is that if I choose to go into Your-Build-System-Java I'm not supposed to read any autoconf and automake configuration because most Java programs have their build system based on ant. Anyway even if you think that there should not be a Your-Build-System-Per-Language per page I highly recommend moving "Your Build System" into a subpage of its own. Again, it adds too many steps and makes the table of contents bigger. Introduction: Please add at the very beginning of the introduction a definition on what an upstream developer is and maybe what a upstream program is. What Debian is. Why Debian is important for your upstream program (your program will be able to be used by all the Debian users (Write here the total Debian users in 2013)) Introduction Redesign - Begin I don't like the current Introduction at all because it does not seem to be useful. Anyways my proposal is to change it into a target or public oriented one. I'll give some fake examples so that you get an idea. * If you are an upstream developer you might be interested in: ** Adapting your usptream program so that it is easier to package ** Being able to package your upstream program and submit it to Debian * If you are a Debian Developer you might be interested in: ** Checking if an upstream program complies with DFSG ** Advising upstream developers on how to improve their programs ** Advising upstream developers on other (Check "If you are an upstream developer..." above). * If you are an user of an upstream program and you want it to be included into Debian ** You can hire a programmer so that it packages it ** You can package the upstream program yourself by using instructions targeted at upstream developers Introduction Redesign - End (Not sure about this one). Move "External advice" into a subwiki of its own. Good practices. Add an initial (or if you want a last one) section named "Good practices". So that means good practices that we expect from your program. This section (or subwiki) would have the current sections: "Upgrades", "Porting", "Branding" and "Media Types". Optionally you can read External advice. "Your upstream package and Debian in a daily basis". That would be the pre-last section which would include the current sections: "Branching", "Downstream Patches" and a note on asking the upstream developer to observe also "Good practices" section advice. Note: Be sure to fix "Good practices" to something right in English language ;). As an upstream developer. These are the questions I would like this guide to answer: - BEGIN * Non Debian specific questions ** I am a newcomer to FOSS world. Although I know how to program I don't know what are the standards and / or best practices for a program like mine. Could you please guide me on which group or person could guide / mentor / sponsor me so that my upstream work meets a minimal criteria ? I guess that will make easier an Integration of upstream software to Debian later. * Debian specific questions ** What do you expect from a Perl / Python / name your language application/program as a minimal criteria to meet? As an upstream developer. These are the questions I would like this guide to answer: - END Upstream package or maintainers experience table. - Begin So I know that in External advice there are many links to people who explain how to make a program so that it is package friendly. I think that it would be nice if we could setup a table with upstream maintainers experience around Debian. So the idea is that new people would update this table. So the headers would be: Upstream program name | Debian package name | Upstream maintainer | Blog entry so that you have something like: Foo | foo | John Smith | http://johnsmith.blog.com/foo-debian-adapt-01 Foo | foo | John Smith | http://johnsmith.blog.com/foo-debian-adapt-02 Plus resx | plusresx | Kevin Landers | http://kevinlanders.blog.com/resx-into-package I am requesting this kind of table because upstream developers would find them more confortable if they can read other upstream developers success histories. And because most of the External advice links that I have seen seem to be distribution agnostic. And, although, that it's fine I think that we should focus on Debian specific content. Upstream package or maintainers experience table. - End "Send / Submit your package to Debian" section. If you read current wiki you will see that the second section is "Initial Packaging" and the third section is "After initial packaging". If you read the latter you will see: "If your package has been packaged for Debian, thank you and congratulations". Come'on! It has not been packaged for Debian! Because you have not told how to proceed. So between these two sections there should be another section that gives an overview on how to submit a package to Debian and I guess that it would also have a link to the appropiate wiki page. Maybe: https://wiki.debian.org/DebianMentorsFaq ? Please advise a better page because my Debian.org understanding is not perfect yet. adrian15 requests summary - Begin So a summary of my requests that you can apply to other sections of this wiki that I haven't parsed yet would be: * Identify which public is the document targeted at (upstream developers, debian developers, final users) * Identify what tasks you want the your targeted public to achieve. * Write these tasks into the wiki page so that it's easy to read * Make sure these tasks do not lack any of their steps * Move into a subpage or wiki of its own whatever tends to be very large (too many subentries in table of contents) * Try to think as an upstream developer. Yeah, I know, this one is difficult even if you are an upstream developer. * Bring toghether sections that make sense to be in the same overall step of a task (i.e. what I did with "Good practices" ) adrian15 requests summary - End