Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
* Vincent Bernat: > Because without uniformity, we make it harder for people to contribute. > I have already mentioned Fedora that provides everything in git with CI > enabled, ability to contribute with pull requests, but that's far the > only proponent. Fedora still uses VCS-in-VCS, so it's not real Git. You cannot simply send a pull request for anything that changes source code. You still have to create a patch file and add it to the RPM spec file. Some package maintainers have their true repositories elsewhere and synthesize the patches from that, but there's no standard way of doing that yet. (packit is not yet integrated with Fedora infrastructure, and it is quite new. It's unclear if it will fare better than the many previous attempts.)
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On Wed, Jul 24, 2019 at 12:23:42PM +, Scott Kitterman wrote: > Since use of a public VCS isn't universal among free software projects, > the implication is that one could take a non-free upstream tarball, dump > it into git on salsa and magically make it free. I think this is a > ridiculous concept. The concept of "preferred form for modification" is mostly about those who actually do the work. If there's an active upstream taking a drive-by patch, it's the upstream's opinion that matters. Dumping a tarball into git doesn't restore lost commit messages, patch history, nor authorship data -- just like you can't un-preprocess C code (nVidia's "nv" driver comes to mind). Ie, I consider making matters worse to be worth forbidding; I'm not proposing declaring old code non-free because it doesn't use techniques which were not even invented then. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour? ⠈⠳⣄
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On Wed, Jul 24, 2019 at 09:20:07AM -0400, Tiago Bortoletto Vaz wrote: > On Wed, Jul 24, 2019 at 09:01:34PM +0900, Norbert Preining wrote: > > (Or, heretic voice, maybe because it is easier to > > throw people out when everything is standardized?) > > Norbert, it's not the first time in recent emails that you insinuate, > semi-jokingly, that Debian might "throw people out" for whatever reasons > you like to think. I just wanted to point out here that this is not > true in Debian. Could you at least check whom are you talking about first, please? Because at this point your insinuation that Norbert is "joking" is disgusting. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out, ⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven big-ass trumpets are playing in the ⠈⠳⣄ sky. Your cat demands food. The priority should be obvious...
Re: Sprint report from the AH/DAM/DPL Sprint, 22/23 June 2019
On Thu, Jul 25, 2019 at 02:00:52AM +, Holger Levsen wrote: > There were other points I disliked or disagreed but as said the mail was > too long and the current noise level at DebConf is unbearable, so I > don't remember. apropos not remembering: I very much *agree* with most of the AH/DAM/DPL work, *many* *many* thanks for these! -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On Wed, Jul 24, 2019 at 8:56 PM Holger Levsen wrote: > On Thu, Jul 25, 2019 at 01:35:59AM +0200, Thomas Goirand wrote: > > tl;dr: Shall we standardize on 3 layouts? Or simply not vote on this? > no, its too early to standardize on layouts. And whether or not it is time (I find myself agreeing with Holger that it is not), I'm unconvinced that a GR is the correct mechanism for implementing what feels to me much more like a debian-policy proposal and revision. -- Harlan Lieberman-Berg ~hlieberman
Re: Sprint report from the AH/DAM/DPL Sprint, 22/23 June 2019
Hi Steve, thanks for this report, but it's too long. Really. For now I will just say that I'm *really* horrified by the idea of AH^wcommunity team keeping lists of people's behaviour. This can go very wrong in so many directions easily. Also I dont think that's Sam hastily conducted survey is of much value. There were other points I disliked or disagreed but as said the mail was too long and the current noise level at DebConf is unbearable, so I don't remember. -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C "... the premise [is] that privacy is about hiding a wrong. It's not. Privacy is an inherent human right, and a requirement for maintaining the human condition with dignity and respect." (Bruce Schneier) signature.asc Description: PGP signature
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On Thu, Jul 25, 2019 at 01:35:59AM +0200, Thomas Goirand wrote: > > tl;dr: Shall we standardize on 3 layouts? Or simply not vote on this? no, its too early to standardize on layouts. -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On 7/23/19 7:31 PM, Thomas Goirand wrote: > 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for > packaging. > > 2- Mandating using the "gbp patches unapplied" layout for Git, as this > seems to be the most popular layout, and that we need some kind of > consistency. > > 3- Mandating using Salsa as a Git repository. Hi everyone! After reading the thread, and discussing it during Debconf, I can see clearly that point 1- doesn't seem controversial, and looks like widely accepted, that 3- also looks like possible to pass if we allow the possibility to use mirroring, but that 2- *is* controversial. tl;dr: Shall we standardize on 3 layouts? Or simply not vote on this? I still believe that standardizing on Git layouts is important, though maybe the timing for imposing one or another isn't appropriate, especially considering that it looks like a lot of people are strongly unsatisfied with our way to manage upstream patches, using Quilt or otherwise. As a consequence, I am withdrawing the proposal to mandate using the "patches unapplied" layout, because it will frustrate a large amount of people in our community. Though would it seem sensible to everyone if we agree on 3 layouts, documented let's say in debian/control with a new VcsGitLayout or something similar (please suggest a better way to document this if this exists)? For example, if we had: VcsLayout: patches-unapplied or VcsLayout: patches-applied or VcsLayout: debian-folder-only will that cover enough cases? Is this even a good idea? Let's stay as open to suggestions as possible in this thread. :) Also, I've read about workflows, when we're really talking about layout. Please remove "gbp" out of this discussion, it's irrelevant. I know it's hard to focus because the layout are directly driving the workflows, but let's please try! Finally, is there here a consensus that we should simply not vote on this at all? Possibly, this also could be a good outcome, I'm not sure about this yet, and I'm looking forward reading answers on this. Last, you've probably noticed that I haven't proposed a text for this GR. This is on purpose, as I want to give it a few weeks for the conversation to drive the way to write this text. Maybe the whole summer, so we can vote in September. I've decided to open this discussion so we can have face-to-face conversation at Debconf, but I also keep in mind that some of us are probably in holidays. I'm also still seeking for volunteers to help me write this GR text once we have finished discussing all of this, and reading everyone's opinion. Cheers, Thomas Goirand (zigo)
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On 7/24/19 6:31 AM, Norbert Preining wrote: > So be it, but don't put *your* bothering onto others. I am bothered by a > lot of things, too, and I don't ask you to be bothered the same way. Even if you dismiss Github, replace it by $foo, and explain to me why I should register there because you call it $home? Do you expect your peers in Debian to register as many accounts as there's Git-aaS platforms in this world? Look what's been done on other distributions. Nobody else does like us, because it simply doesn't make sense at all. It's currently a huge mess. My suggestion is to fix it, once and for all. Thomas
Re: anti-tarball clause and GPL
On Wed, Jul 24, 2019 at 10:28:19PM +0200, Florian Weimer wrote: > On the other hand, not allowing source distribution as a “flat > tarball” sounds like an additional restriction, which would be > incompatible with the GPL. (Just like parts of glibc used to require > distribution on tapes, only less inconvenient.) I believe that "flat" tarball in Adam's question means tarball stripping out VCS information, not tarball as a format. Also, the clause doesn't disallow the distribution using tarball, but only define what "source code == preferred form for making modification" is. So, "flat tarball" becomes object code license-wise. Yao Wei signature.asc Description: PGP signature
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On July 24, 2019 1:16:37 PM UTC, Vincent Bernat wrote: > ❦ 24 juillet 2019 12:23 +00, Scott Kitterman : > >> This entire discussion feels to me like a small group of developers >> trying to tell the rest of us "my way or the highway". We are >> perfectly capable of phasing out obsolete workflows without a hammer >> like a GR (remember dpatch). > >Without a GR, the outcome is decided by a shouting contest. A GR seeems >great to know if people are a majority or not. 50% + 1 of developers mandating details like this to 50% - 1 of developers is a horrible way to solve problems like this. If you want people to do things a certain way, have it solve problems that cause people to decide they want to use it. Once you get rough consensus on the new way, change policy. Scott K
Re: anti-tarball clause and GPL
* Adam Borowski: > In the light of the currently discussed GR proposal, I wonder if the > following license clause would be considered DFSG-free and GPL-compatible: > > ## > I do not consider a flat tarball to be a preferred form for modification. > Thus, like any non-source form, it must be accompanied by a way to obtain > the actual form for modification. There are many such ways -- unless you > distribute the software in highly unusual circumstances, a link to a > network server suffices; see the text of the GPL for further details. > ## > > I believe such a statement would be GPL-compatible; rationale: > * by the 2011 Red Hat kernel sources outcry, it is obvious such a tarball > is long obsolete > * a flat tarball deprives the recipient of features of modern VCSes > * comments giving rationale for a change tend to be written as VCS commit > messages > * future forms are not banned: it is conceivable that next week someone > invents a revolutionary new form that wins over git > > Thoughts? The GPL version 2 already requires that you maintain something like a ChangeLog: | 2. You may modify your copy or copies of the Program or any portion | of it, thus forming a work based on the Program, and copy and | distribute such modifications or work under the terms of Section 1 | above, provided that you also meet all of these conditions: | | a) You must cause the modified files to carry prominent notices | stating that you changed the files and the date of any change. On the other hand, not allowing source distribution as a “flat tarball” sounds like an additional restriction, which would be incompatible with the GPL. (Just like parts of glibc used to require distribution on tapes, only less inconvenient.)
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
* Bastian Blank: > On Wed, Jul 24, 2019 at 01:46:36AM +0200, Thomas Goirand wrote: >> On 7/23/19 11:59 PM, Adam Borowski wrote: >> > Big fat enormous NO! gbp is a workaround for the biggest evil in our >> > packaging: quilt. Watching pro-git-only talks on the Debconf, I got the >> > impression that if we dropped the VCS-in-VCS approach, there'd be no need >> > for most of that complexity. >> How do you track what you've applied in Debian, and the status of your >> patch upstream? With DEP3 patch headers in d/patches, we track this easily. > > git cherry-pick to get new changes. git diff to get all changes, git log > to list changes. You just need to know the branch point. I expect you'd need some more tool support to find backports that did not properly converge after an upstream merge (that is, importing a new .orig.tar.gz in the current model), so that you can be aware and remove the lingering difference. For partially diverging trees, “git diff” might be a bit too much. However, I do think that such tooling will be far simpler and more deterministic than any two-way Git importer (having written one of those for RPM spec files, complete with LCS-based editing of Patch:/%patch directives). But isn't a GR a bit premature? I would have expected something to build directly from salsa.debian.org first—like how Fedora builds from Git repositories on src.fedoraproject.org. I'd hope for something without VCS-in-VCS, but even if you prefer that, but build-from-salsa applies to any approach which mandates a centralized Git (in addition to the already-centralized archive). (I really hate VCS-in-VCS, although I know it primarily from a non-Debian context these days.)
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On Tue, Jul 23, 2019 at 11:59:59PM +0200, Adam Borowski wrote: > Big fat enormous NO! gbp is a workaround for the biggest evil in our > packaging: quilt. Watching pro-git-only talks on the Debconf, I got the > impression that if we dropped the VCS-in-VCS approach, there'd be no need > for most of that complexity. gbp is nasty stuff, yes. Years ago I made plans to make good use of the "3.0 (custom)" source format by writing one large patch into the finished source package. It would just work with non-linear history by simply diffing the branch point and the head. What is also missing: merge friendly changelog management. > And, a flat tarball like .orig is no longer a preferred form for > modification. Do you remember the brouchacha in 2011 when Red Hat released > their kernel sources that way? It was never. A tarball is a container of files. The files inside are the perferred form of modification. Regards, Bastian -- It would be illogical to assume that all conditions remain stable. -- Spock, "The Enterprise Incident", stardate 5027.3
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On Wed, Jul 24, 2019 at 01:46:36AM +0200, Thomas Goirand wrote: > On 7/23/19 11:59 PM, Adam Borowski wrote: > > Big fat enormous NO! gbp is a workaround for the biggest evil in our > > packaging: quilt. Watching pro-git-only talks on the Debconf, I got the > > impression that if we dropped the VCS-in-VCS approach, there'd be no need > > for most of that complexity. > How do you track what you've applied in Debian, and the status of your > patch upstream? With DEP3 patch headers in d/patches, we track this easily. git cherry-pick to get new changes. git diff to get all changes, git log to list changes. You just need to know the branch point. And nothing forces you not to use DEP3 or something similar in git. Or you add a file to that commit with information you need. Bastian -- "... freedom ... is a worship word..." "It is our worship word too." -- Cloud William and Kirk, "The Omega Glory", stardate unknown
Re: anti-tarball clause and GPL
On 7/23/19 6:49 PM, Adam Borowski wrote: > In the light of the currently discussed GR proposal, I wonder if the > following license clause would be considered DFSG-free and GPL-compatible: > > ## > I do not consider a flat tarball to be a preferred form for modification. > Thus, like any non-source form, it must be accompanied by a way to obtain > the actual form for modification. There are many such ways -- unless you > distribute the software in highly unusual circumstances, a link to a > network server suffices; see the text of the GPL for further details. > ## > > I believe such a statement would be GPL-compatible; rationale: > * by the 2011 Red Hat kernel sources outcry, it is obvious such a tarball > is long obsolete > * a flat tarball deprives the recipient of features of modern VCSes > * comments giving rationale for a change tend to be written as VCS commit > messages > * future forms are not banned: it is conceivable that next week someone > invents a revolutionary new form that wins over git > > Thoughts? Flat tarballs are not the preferred form for the modification of anything; they are a popular method for storing directory hierarchies, which can then be distributed in many ways. Modern VCSes provide other methods for distributing directory hierarchies, some of which are becoming quite popular in their own right (i.e. "git clone"). So, to my reading, upstream is merely adding restrictions to the way some project's source code may be distributed, which looks to me like an additional restriction that makes it GPL-incompatible. Imagine forking something like gcc, and then requiring that anyone distributing your fork must distribute the result using git. Can you imagine the FSF being on board with that? (Actually, to make it more clear, imagine forking gcc, and then requiring distribution via CVS. I think a few more people would object than just the FSF, and on more than just principled grounds. But it also illustrates why this kind of restriction is against the spirit of free software.) If the intent is to not strip out the usual VCS metadata, then why not just say that? "We consider VCS metadata to be essential to proper modification of our project, and thus stripping out such metadata is tantamount to making the result a non-preferred form for modification of the work." Does it really matter that your .git directory was created directly with the git tool, as opposed to being unpacked via tar? The git tool itself doesn't seem to care. Personally, I wouldn't take this latter approach, because I don't trust that VCS tools treat their metadata with enough care to make a VCS checkout operation reproducible. And that doesn't even consider how VCS metadata tends to explode in size over time. But, to each their own.
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On 24.07.19 17:38, Fabien Givors wrote: > Le 24/07/2019 à 15:16, Vincent Bernat a écrit : >> Without a GR, the outcome is decided by a shouting contest. A GR seeems >> great to know if people are a majority or not. > A GR is not just a poll. Yup. I personally see little chance this goes through. To have polls, among DDs and our users, seems like a good idea, though. Best, Steffen
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
Le 24/07/2019 à 15:16, Vincent Bernat a écrit : > Without a GR, the outcome is decided by a shouting contest. A GR seeems > great to know if people are a majority or not. A GR is not just a poll. Consider the following two questions: i) Which is the recommended workflow among X, Y, Z? ii) Do I accept, whatever the result of i), to make it mandatory for all submitted packages? I'm not sure most would agree to ii) unless they support the option chosen in i) What if the chosen standard is far from perfect? It's been said that the vcs² approach of gbp+quilt is more of a workaround than a well designed one. And there may be other problems. How will we be able to make (on even seek) progress if the workflow requirements are strictly defined? While the positive outcomes of having such a standard are clear, I think it should first come as a strong recommendation: the "right way" of doing packaging in most situations, along with a clear documentation and a toolchain working out-of-the-box and handling the different use-cases. If it's the "painless way", it will become a standard even without a GR. -- captnfab
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
> Do you ask me to increase my work load to at least 300% only because of some > standardization procedure for the minuscule chance that I am suddenly > abducted by aliens? No, it’s not about being abducted by the aliens, but there are other more realistic factors that might get any developer to stop contributing. I find it useless to list them all just to prevent you from strawmanning. > (Or, heretic voice, maybe because it is easier to > throw people out when everything is standardized?) Anyway, I am really really tired of your whining in just every message you send, so I am just blacklisting you. Ondrej -- Ondřej Surý ond...@sury.org
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On Wed, Jul 24, 2019 at 09:01:34PM +0900, Norbert Preining wrote: > On Wed, 24 Jul 2019, Ondřej Surý wrote: > > > so, why isn't it enough to recommend those things? > > > > Because you are not the only developer in the whole world? > > And when you disappear or just don’t have a time and somebody > > else needs to fix your packages, then it’s a heap of unnecessary > > trouble to go through because of someones “personal” preferences. > > Sorry, I spent about 15 years packaging TeX and friends - and I spend > most of my Debian time with that. > > Do you ask me to increase my work load to at least 300% only because of some > standardization procedure for the minuscule chance that I am suddenly > abducted by aliens? (Or, heretic voice, maybe because it is easier to > throw people out when everything is standardized?) Norbert, it's not the first time in recent emails that you insinuate, semi-jokingly, that Debian might "throw people out" for whatever reasons you like to think. I just wanted to point out here that this is not true in Debian. And I do this because I don't want people to feel themselves discouraged of speaking out in the project. That exhausting process has hurt everybody involved, and has finished with appologies from both sides after so much pain. And I just can't believe that we didn't learn anything from it after all. Bests, -- tiago
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
❦ 24 juillet 2019 12:23 +00, Scott Kitterman : > This entire discussion feels to me like a small group of developers > trying to tell the rest of us "my way or the highway". We are > perfectly capable of phasing out obsolete workflows without a hammer > like a GR (remember dpatch). Without a GR, the outcome is decided by a shouting contest. A GR seeems great to know if people are a majority or not. -- Don't sacrifice clarity for small gains in "efficiency". - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On July 24, 2019 10:43:57 AM UTC, Phil Morrell wrote: >On Wed, Jul 24, 2019 at 07:34:02PM +1000, Alexander Zangerl wrote: >> i detest unwarranted, imposed, uniformity. i *love* consistency. we >have >> had consistency in the distribution for ages. we don't need uniform >> workflows. > >It's not (always) about mandating workflows, see Ian's careful >distinction in the GitPackagingSurvey between sharing format and >workflow. Your previous mail said: > >> as long as the resulting package aupload conforms to the specs i see >no > >I believe this GR is about moving the needle on what those specs say - >that a source tarball is no longer enough to represent the "preferred >form of modification" for debian developers (to reference another >thread). **If** it's decided that a debian package must have a git >representation hosted on salsa as a service to users, then yes that may >restrict your workflow freedom. Since use of a public VCS isn't universal among free software projects, the implication is that one could take a non-free upstream tarball, dump it into git on salsa and magically make it free. I think this is a ridiculous concept. >I hope it wouldn't go as far as requiring that you literally use >git-buildpackage itself, but it might say that in non-exceptional >cases, >tag2upload must replace dput. That's a long way off, but yes you would >end up having to adapt your workflow slightly to meet the new spec. I've been a Debian contributor for over a decade. I've never built a package for upload from anything other than dpkg-buildpackage. I've used gbp (as well as git-dpm and doing it manually) for patch management. This entire discussion feels to me like a small group of developers trying to tell the rest of us "my way or the highway". We are perfectly capable of phasing out obsolete workflows without a hammer like a GR (remember dpatch). I probably have better things to do with my time than learning from scratch how to contribute to Debian. Scott K
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On Wed, 24 Jul 2019, Ondřej Surý wrote: > > so, why isn't it enough to recommend those things? > > Because you are not the only developer in the whole world? > And when you disappear or just don’t have a time and somebody > else needs to fix your packages, then it’s a heap of unnecessary > trouble to go through because of someones “personal” preferences. Sorry, I spent about 15 years packaging TeX and friends - and I spend most of my Debian time with that. Do you ask me to increase my work load to at least 300% only because of some standardization procedure for the minuscule chance that I am suddenly abducted by aliens? (Or, heretic voice, maybe because it is easier to throw people out when everything is standardized?) Why don't you simply trust those who are responsible for packages that they know what is the most appropriate way? Are we now in a state in Debian that Developers are treated as employees that have to obey and follow the rules, or are we still a group of self-determined engineers that are able to make our own decisions, including what packaging is the best/most convinient, with the aim of building the best distribution? > Debian is a team effort and it always was, although it sometimes I strongly disagree - it is **not** - it is the work of lots of dedicated individuals, not team work. There are some teams that work together, but this is not Debian. > It’s fine to be a different, but when it hinders other’s ability to contribute > sometimes it’s better to bite the bullet and be nice to your fellow > Debian Developers by making your packaging accessible. Again weak. If you want to contribute, unpack the source package and fix bugs, improve packaging, whatever. Then send patches. The maintainer will include that in the work flow - you learn how it works, and next time maybe already do the same. This is not even the slightest reason NOT to contribute. Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
> so, why isn't it enough to recommend those things? Because you are not the only developer in the whole world? And when you disappear or just don’t have a time and somebody else needs to fix your packages, then it’s a heap of unnecessary trouble to go through because of someones “personal” preferences. Debian is a team effort and it always was, although it sometimes look like a team of zen-buddhists - each walking a different path and different direction - we do converge to a common goal at the end. It’s fine to be a different, but when it hinders other’s ability to contribute sometimes it’s better to bite the bullet and be nice to your fellow Debian Developers by making your packaging accessible. Ondrej -- Ondřej Surý ond...@sury.org
Re: farewell
> I trust you are able to critize technology without attacking people, so > there is NO reason to not speak out. It was **me** who was thrown out for some time, so please leave the call to me to decide what I post here - my trust in the currently responsible teams to give a fair process is currently non-existent. That trust was eradicated within a very short period - and as with fame, it takes a long time to be rebuild. Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On Wed, Jul 24, 2019 at 07:34:02PM +1000, Alexander Zangerl wrote: > i detest unwarranted, imposed, uniformity. i *love* consistency. we have > had consistency in the distribution for ages. we don't need uniform > workflows. It's not (always) about mandating workflows, see Ian's careful distinction in the GitPackagingSurvey between sharing format and workflow. Your previous mail said: > as long as the resulting package aupload conforms to the specs i see no I believe this GR is about moving the needle on what those specs say - that a source tarball is no longer enough to represent the "preferred form of modification" for debian developers (to reference another thread). **If** it's decided that a debian package must have a git representation hosted on salsa as a service to users, then yes that may restrict your workflow freedom. I hope it wouldn't go as far as requiring that you literally use git-buildpackage itself, but it might say that in non-exceptional cases, tag2upload must replace dput. That's a long way off, but yes you would end up having to adapt your workflow slightly to meet the new spec. > or do you also plan to insist that your roofing contractor only uses > tools and only cuts the rafters with your preferred saw? To extend the analogy, no, but I would be happy insisting that they place tiles, not thatch, and that rafters are cut in accordance with local building regulation. This will incidentally turn away all thatching contractors and anyone's workflow which relies on e.g. cutting corners when out of sight. Ultimately, assume a maintainer, or a whole team of uploaders gets hit by a bus, how can we specify the definition of a "package" such that other DDs can quickly and easily take up future maintenance. -- Phil Morrell (emorrp1) signature.asc Description: PGP signature
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
Vincent Bernat wrote: > While not having any official position in either of these projects, I > was able to contribute easily to both of them because they use a > standard workflow: no need to read tons of documentation. There is some truth in this, but I'm not sure the proposal is directly addressing this issue. I'm a Debian user with some experience of packaging in-house applications, and very small exposure to uploading to Debian. I'm adding my point of view as a relative newbie for packaging, FWIW. The New Maintainer's Guide currently presents several different workflows, with very little guidance on which one to use, therefore this proposal sounds completely backassward to me: new maintainers are supposed to learn about several competing workflows and figure out themselves which one to use *before* building their first package, while experienced developers are being mandated to use one specific one, even though they might have valid reasons for using a non-standard one. How about having one *recommended* workflow, which is well documented and kept up-to-date, while still allowing experienced developers to adopt alternatives? Or at least do this in two stages: first get newcomers and people eager to change on board, and only then, in a second step, mandate a change in workflow from old dogs who must be forced to learn new tricks. Thomas
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
Hi, Am 23.07.19 um 19:31 schrieb Thomas Goirand: > So, the topics are: > > [snip]> > 2- Mandating using the "gbp patches unapplied" layout for Git, as this > seems to be the most popular layout, and that we need some kind of > consistency. Other people have already brought up reasons against this, but I just wanted to mention that the Haskell Group doesn't use a gbp layout for all of it's packages. Converting all the packages to gbp would mean a lot of work for the conversion and would probably result in less convenient workflows for the team once the conversion is done. At least from my point of view, I don't see how the benefit of consistency outweighs the cost of conversion and not being able to adjust your workflows to your needs. Regards Sven signature.asc Description: OpenPGP digital signature
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On Wed, Jul 24, 2019 at 07:34:02PM +1000, Alexander Zangerl wrote: > >> so, why isn't it enough to recommend those things? > >Because without uniformity, we make it harder for people to contribute. > > i detest unwarranted, imposed, uniformity. i *love* consistency. we have > had consistency in the distribution for ages. we don't need uniform > workflows. > > what good can come from reducing diversity and actively probibiting > flexiblity? Other people can more reliably fix your packages. > and why do you insist on micromanaging the workflow i've got > to use? Because you are not the only one who may work on your packages. > or do you also plan to insist that your roofing contractor only uses > tools and only cuts the rafters with your preferred saw? This comparison is irrelevant. -- WBR, wRAR signature.asc Description: PGP signature
Re: anti-tarball clause and GPL
On Wed, 24 Jul 2019 at 02:34:13 +0200, Adam Borowski wrote: > > > ## > > > I do not consider a flat tarball to be a preferred form for modification. > > > Thus, like any non-source form, it must be accompanied by a way to obtain > > > the actual form for modification. There are many such ways -- unless you > > > distribute the software in highly unusual circumstances, a link to a > > > network server suffices; see the text of the GPL for further details. > > > ## Are you asking this hypothetically, or is there a piece of software that someone intends to apply this to? As always for legal questions on whether something is allowed in Debian, asking -legal will only get you some speculation: the ftp team is the authority on what can and can't be in Debian. However, I think this would be an unwise precedent to set, with undesirable practical implications, and I suspect the ftp team would think the same. Remember that GPL-2 §3c is only allowed for non-commercial redistribution, so commercial redistributors have to use §3a or §3b. This means they have to take steps to redistribute the preferred form for modification themselves (e.g. copy it to *their* network server). In the GPL-3 case, a commercial redistributor could rely on §6d (GPL-3 §6 is the equivalent of GPL-2 §3), but it's unwise to rely on a third party for this without some sort of contractual relationship, because "you remain obligated to ensure that it is available for as long as needed to satisfy these requirements" (so linking to upstream's network server is not enough, because if upstream stop distributing source, you would be in violation of the license unless you immediately stop distributing binaries). Debian and its derivatives are longer-lived than many of the packages we include, so we need to know that we are already distributing source for all our binaries. Redistributing the entire history of a third-party project is practically problematic because it is no longer enough to check that there is nothing you don't want to distribute (e.g. non-free software) in the HEAD commit: you also have to check that there is nothing that you don't want to distribute anywhere in the history. If I remember correctly, this is why the ftp team do not allow "3.0 (git)"-format source packages in the Debian archive: if a git-based source package format is allowed in future, it will have to be "shallow", which makes it functionally equivalent to a tarball plus metadata. For established projects, the complete history is also inconveniently large: my git clone of glib2.0 has a 57M .git, which compares poorly with a 4.5M source tarball (and glib2.0 isn't even particularly big or old by the standards of projects like glibc and the Linux kernel). > By this logic, a pile of .c files with comments removed or preprocessed > with cpp would be allowed as well. The VCS is also a means to store > human-readable comments. We have to draw a line somewhere. You could equally well say the software's bug tracking system and mailing lists, which also store human-readable comments, are part of the preferred form for modification - but those don't normally have any copyright license granted (I certainly didn't put this email under a copyright license!) so they are non-free. > Another piece of [meta]data that a flat tarball lacks is authorship > information. Projects that consider this to be important put copyright notices in source files, lists of authors in source files and/or lists of authors in ./AUTHORS. smcv
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On Wed, 24 Jul 2019 11:23:07 +0200, Vincent Bernat writes: >> so, why isn't it enough to recommend those things? > >Because without uniformity, we make it harder for people to contribute. i detest unwarranted, imposed, uniformity. i *love* consistency. we have had consistency in the distribution for ages. we don't need uniform workflows. what good can come from reducing diversity and actively probibiting flexiblity? and why do you insist on micromanaging the workflow i've got to use? i thought we wanted to produce a good distribution, not force everybody gratuitously to use the same tools. or do you also plan to insist that your roofing contractor only uses tools and only cuts the rafters with your preferred saw? regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ "[Perl] isn't a programming language, it's a thousand special case rules flying in close formation." -- Peter da Silva signature.asc Description: Digital Signature
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On Wed, Jul 24, 2019 at 02:23:26PM +0500, Andrey Rahmatullin wrote: > > > If we're not willing to force people to use debhelper, forcing them to > > > use git and > > > salsa seems much more extreme. > > > > +1 > > > > let's first, if at all, get the mandatory use of debhelper into policy > > which is much more important. > As was recently discussed, we don't want to mandate it, but the > recommendation was added in 4.4.0. Sorry, this was specifically about dh(1), I don't remember if the discussion mentioned mandating debhelper in addition to recommending dh(1). -- WBR, wRAR signature.asc Description: PGP signature
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On Wed, Jul 24, 2019 at 10:49:05AM +0200, Daniel Baumann wrote: > > If we're not willing to force people to use debhelper, forcing them to use > > git and > > salsa seems much more extreme. > > +1 > > let's first, if at all, get the mandatory use of debhelper into policy > which is much more important. As was recently discussed, we don't want to mandate it, but the recommendation was added in 4.4.0. -- WBR, wRAR signature.asc Description: PGP signature
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
❦ 24 juillet 2019 17:07 +10, Alexander Zangerl : > well, i do exist. i have a few packages that aren't vc'd, and i don't see > any need to change that. while i don't mind git, but i'd hate to be _forced_ > to use salsa and gbp. > > so, why isn't it enough to recommend those things? Because without uniformity, we make it harder for people to contribute. I have already mentioned Fedora that provides everything in git with CI enabled, ability to contribute with pull requests, but that's far the only proponent. For example, NixOS works this way and they maintain more packages than us with far fewer people. HomeBrew is another example. While not having any official position in either of these projects, I was able to contribute easily to both of them because they use a standard workflow: no need to read tons of documentation. Having everything in git would be a first step. -- Grief can take care of itself; but to get the full value of a joy you must have somebody to divide it with. -- Mark Twain signature.asc Description: PGP signature
Re: farewell
On 15472 March 1977, Norbert Preining wrote: I reply to you in private to make sure that my comments are not seen as uttered within the Debian project, which could bring me into just another difficult situation. No it would not. Repeating the above as you recently love to do does not make it any more true. It just makes you appear whining for no good reason. It is never bad to critize, it is never bad to mention bugs, it is never bad to talk about shitty technology. And there is a load to criticize, there are way too many bugs, there is a shitload of bad technology out there, and many free software apps/projects appear to go ways that defy any good logic. Pointing that out is *always* ok. It just is NOT ok when that pointing out consists of attacks or of demeaning people. I trust you are able to critize technology without attacking people, so there is NO reason to not speak out. -- bye, Joerg
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On 7/24/19 7:29 AM, Harlan Lieberman-Berg wrote: > If we're not willing to force people to use debhelper, forcing them to use > git and > salsa seems much more extreme. +1 let's first, if at all, get the mandatory use of debhelper into policy which is much more important. Regards, Daniel
Re: anti-tarball clause and GPL
On 24.07.2019 00:49, Adam Borowski wrote: Hi! In the light of the currently discussed GR proposal, I wonder if the following license clause would be considered DFSG-free and GPL-compatible: ## I do not consider a flat tarball to be a preferred form for modification. Thus, like any non-source form, it must be accompanied by a way to obtain the actual form for modification. There are many such ways -- unless you distribute the software in highly unusual circumstances, a link to a network server suffices; see the text of the GPL for further details. ## I believe such a statement would be GPL-compatible; rationale: * by the 2011 Red Hat kernel sources outcry, it is obvious such a tarball is long obsolete * a flat tarball deprives the recipient of features of modern VCSes * comments giving rationale for a change tend to be written as VCS commit messages * future forms are not banned: it is conceivable that next week someone invents a revolutionary new form that wins over git Thoughts? Few comments: A "flat tarball" cannot be considered a preferred form for modification. Few tools allow you to edit a flat tarball (maybe `mc`). It is just a form of distribution. We sent to GNU patches, new files, or extract of functions. I think you confuse the "preferred form for modification" to "preferred method of distribution of sources". Compression of tarball often change, so we need "new" (less than 10 year old) tools to extract many tarball (tarball format also had few improvements). GPL do not restrict format and compression of tarball. Early GNU programs come with many different distribution methods. 'tar' is much modern (so initially on "modern GNU" systems). The tar was never considered as only (or main) method to obtain sources. IIRC from very old discussion, you can have a GPL compatible distribution method of your choice, if you distribute tools to extract sources, or such tools are easy available to the user who bought your software. There is no need to have free tools: if you distribute binaries for Solaris, it is enough that user could use a proprietary Solaris command to get the source. Note: tarball are often not GPL compliant, because we are lazy. VCS solves most of the problems (or helps): GPL requires us to have and distribute a changelog, so that we can track better licenses, modification time, and copyright. Debian requires own changelog (we use GPL for Debian stuffs), but as we saw, upstreams often forget it. In such cases (without changelog) a tarball cannot be considered fully GPL compliant. ciao cate
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
Norbert Preining writes: ... > I am personally not upset at all, On reading back what you wrote, I see that the impression I'd somehow gained has no basis in fact, so I'm sorry for even suggesting it. Perhaps it was just the brief flurry of "Reply to every email" behaviour that set some unconscious flag in me, probably harking back to Joey's thread-patterns post. Anyway, it looks like people are speaking up for themselves now, which is good. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: anti-tarball clause and GPL
Adam Borowski writes: > Hi! > In the light of the currently discussed GR proposal, I wonder if the > following license clause would be considered DFSG-free and GPL-compatible: > > ## > I do not consider a flat tarball to be a preferred form for modification. > Thus, like any non-source form, it must be accompanied by a way to obtain > the actual form for modification. There are many such ways -- unless you > distribute the software in highly unusual circumstances, a link to a > network server suffices; see the text of the GPL for further details. > ## > > I believe such a statement would be GPL-compatible; rationale: > * by the 2011 Red Hat kernel sources outcry, it is obvious such a tarball > is long obsolete > * a flat tarball deprives the recipient of features of modern VCSes > * comments giving rationale for a change tend to be written as VCS commit > messages > * future forms are not banned: it is conceivable that next week someone > invents a revolutionary new form that wins over git > > Thoughts? Not everyone uses version control. Making requirements on how people make modifications would be a significant change. It would definitely be incompatible with the GPL. Cheers, Walter Landry
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On Wed, 24 Jul 2019, Alexander Zangerl wrote: > On Wed, 24 Jul 2019 07:07:51 +0200, Philip Hands writes: > >You may be responding on behalf of people who turn out not to exist. > > well, i do exist. i have a few packages that aren't vc'd, and i don't see > any need to change that. while i don't mind git, but i'd hate to be _forced_ > to use salsa and gbp. > > so, why isn't it enough to recommend those things? > > as long as the resulting package aupload conforms to the specs i see no > need to bring out the big bludgeon of policy to silence the > minority packagers/old farts whose packages are older than 10y/people who > don't like salsa. I don't think that correlates with being old or experienced. Alex signature.asc Description: PGP signature
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On Wed, 24 Jul 2019 07:07:51 +0200, Philip Hands writes: >You may be responding on behalf of people who turn out not to exist. well, i do exist. i have a few packages that aren't vc'd, and i don't see any need to change that. while i don't mind git, but i'd hate to be _forced_ to use salsa and gbp. so, why isn't it enough to recommend those things? as long as the resulting package aupload conforms to the specs i see no need to bring out the big bludgeon of policy to silence the minority packagers/old farts whose packages are older than 10y/people who don't like salsa. regards az -- Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/ Fachbegriffe der Informatik, 99.9%: Lüge. -- Uwe Ohse signature.asc Description: Digital Signature
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
Hi > Would it not be worth waiting for them to respond to this issue > themselves, rather than immediately firing off a series of emails that > give the impression that you are personally upset about this? Communication with contributors can be difficult and long delayed, mostly due to being located in China and often away from personal device. We have one in our team. The respective packages are still mentined as old svn, not existing any more. Do you think they have time and energy to reading this here and comment? I am personally not upset at all, I just find it not a good idea to *mandate* things that are very personal development practices. But if we want to get rid of some developers, well, this is a way ahead I guess. Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
