Re: Why Vcs-* fields are not at least recommended ?
On 2020-08-19 07:47 +0200, Geert Stappers wrote: > > > Please, pretty please, make `debcheckout ` possible 'dgit checkout ' is possible. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Why Vcs-* fields are not at least recommended ?
On Wed, 19 Aug 2020 at 10:28:51 -0700, Sean Whitton wrote: > On Wed 19 Aug 2020 at 12:49PM +02, Ulrike Uhlig wrote: > > For actively maintained packages I personally do not understand that > > people in 2020 develop code without using a VCS and still put out only > > tarballs. But I might be unaware of some corner cases where this is the > > only way to do it. > > AIUI there are some packages with huge assets which git can't handle. Even those seem like a job for a debian/-only git repository (gbp buildpackage --git-overlay, and avoid dgit, which AIUI always wants everything from the source package to be in git) rather than having no version control for the debian directory. See openarena-data, for example. smcv
Re: Why Vcs-* fields are not at least recommended ?
Le mer. 19 août 2020 à 19:29, Sean Whitton a écrit : > Hello, > > On Wed 19 Aug 2020 at 12:49PM +02, Ulrike Uhlig wrote: > > > For actively maintained packages I personally do not understand that > > people in 2020 develop code without using a VCS and still put out only > > tarballs. But I might be unaware of some corner cases where this is the > > only way to do it. > > AIUI there are some packages with huge assets which git can't handle. > > But not many. > About that: i wonder why just maintaining a debian/ dir is not enough. The gbp layout with master/upstream/pristine-tar is overkill. Jérémy
Re: Why Vcs-* fields are not at least recommended ?
Hi! On 19.08.20 19:28, Sean Whitton wrote: > On Wed 19 Aug 2020 at 12:49PM +02, Ulrike Uhlig wrote: > >> For actively maintained packages I personally do not understand that >> people in 2020 develop code without using a VCS and still put out only >> tarballs. But I might be unaware of some corner cases where this is the >> only way to do it. > > AIUI there are some packages with huge assets which git can't handle. > > But not many. Thanks for explaining! So, if I understand correctly, the Vcs field should not be mandatory, but could be recommended (in pedantic or normal mode) by lintian. - ulrike
Re: Why Vcs-* fields are not at least recommended ?
Hello, On Wed 19 Aug 2020 at 12:49PM +02, Ulrike Uhlig wrote: > For actively maintained packages I personally do not understand that > people in 2020 develop code without using a VCS and still put out only > tarballs. But I might be unaware of some corner cases where this is the > only way to do it. AIUI there are some packages with huge assets which git can't handle. But not many. -- Sean Whitton signature.asc Description: PGP signature
Re: Why Vcs-* fields are not at least recommended ?
On Wed, Aug 19, 2020 at 04:33:28PM +0500, Andrey Rahmatullin wrote: > On Wed, Aug 19, 2020 at 07:31:08AM -0400, Roberto C. Sánchez wrote: > > > For non actively maintained packages on could check them into Git > > > oneself and then start a history from there, and potentially update the > > > package. > > > > > I have had good results with snapshot.debian.org. On a few occasions, > > simply downloading each successive version from snapshot.debian.org and > > then using something like 'gbp import-dscs *.dsc' gives more than > > sufficient version history. Granted, that has limitations, but it is > > available right now. > gbp import-dscs --debsnap > The only thing I don't like about the debsnap option is that it does not seem to have a way to limit the number of snapshots that are retrieved or to specify the versions of interest. For instance, if I only want to see the versions of a package that constitute stable security updates, I might do something like this: debsnap -v -d . -f foobar --first 1.2-3 --last 1.2-3+deb9u5 Then: gbp import-dscs *.dsc If the --debsnap option to import-dscs has that capability then it must not be documented. Regards, -Roberto -- Roberto C. Sánchez
Re: Why Vcs-* fields are not at least recommended ?
On Wed, Aug 19, 2020 at 07:31:08AM -0400, Roberto C. Sánchez wrote: > > For non actively maintained packages on could check them into Git > > oneself and then start a history from there, and potentially update the > > package. > > > I have had good results with snapshot.debian.org. On a few occasions, > simply downloading each successive version from snapshot.debian.org and > then using something like 'gbp import-dscs *.dsc' gives more than > sufficient version history. Granted, that has limitations, but it is > available right now. gbp import-dscs --debsnap -- WBR, wRAR signature.asc Description: PGP signature
Re: Why Vcs-* fields are not at least recommended ?
On Wed, Aug 19, 2020 at 12:49:11PM +0200, Ulrike Uhlig wrote: > Hi Alexis, > > On 18.08.20 23:10, Alexis Murzeau wrote: > > > I'm wondering why Vcs-* fields in debian/control (Vcs-Browser and/or > > Vcs-) > > are not recommended (or maybe even strongly recommended) ? (I mean here > > that I think > > having Vcs-* fields should be recommended for active packages) > > > There is no lintian tag for missing Vcs-* fields (not even a low severity > > one, > > but I don't know if it's because of lack of interest or because of the > > policy). > > If one uses lintian in its pedantic mode, and a package is > co-maintained, i.e. has a Maintainer and Uploader field, then lintian > does recommend using a VCS: > https://lintian.debian.org/tags/co-maintained-package-with-no-vcs-fields.html > > I agree that it might be useful to extend this tag to non co-maintained > packages as well, potentially at least in pedantic mode. > > > Maybe the fact that we still have the package' source tarballs for each > > released version is enough, but this loose the VCS history and ongoing work > > in > > case someone else wants to contribute too. > > I fully agree with you here. > > For non actively maintained packages on could check them into Git > oneself and then start a history from there, and potentially update the > package. > I have had good results with snapshot.debian.org. On a few occasions, simply downloading each successive version from snapshot.debian.org and then using something like 'gbp import-dscs *.dsc' gives more than sufficient version history. Granted, that has limitations, but it is available right now. Regards, -Roberto -- Roberto C. Sánchez
Re: Why Vcs-* fields are not at least recommended ?
Hi Alexis, On 18.08.20 23:10, Alexis Murzeau wrote: > I'm wondering why Vcs-* fields in debian/control (Vcs-Browser and/or > Vcs-) > are not recommended (or maybe even strongly recommended) ? (I mean here that > I think > having Vcs-* fields should be recommended for active packages) > There is no lintian tag for missing Vcs-* fields (not even a low severity one, > but I don't know if it's because of lack of interest or because of the > policy). If one uses lintian in its pedantic mode, and a package is co-maintained, i.e. has a Maintainer and Uploader field, then lintian does recommend using a VCS: https://lintian.debian.org/tags/co-maintained-package-with-no-vcs-fields.html I agree that it might be useful to extend this tag to non co-maintained packages as well, potentially at least in pedantic mode. > Maybe the fact that we still have the package' source tarballs for each > released version is enough, but this loose the VCS history and ongoing work in > case someone else wants to contribute too. I fully agree with you here. For non actively maintained packages on could check them into Git oneself and then start a history from there, and potentially update the package. For actively maintained packages I personally do not understand that people in 2020 develop code without using a VCS and still put out only tarballs. But I might be unaware of some corner cases where this is the only way to do it. - ulrike
Re: we do recommend workflows (Re: Why Vcs-* fields are not at least recommended ?)
On Wed, Aug 19, 2020 at 12:19:42PM +0200, Mattia Rizzolo wrote: > > > And we cannot recommend using a VCS because we don't usually recommend > > > workflows. > > [...] > > > I don't think anything is "supposed" here. We don't recommend workflows > > > > yes, we do. workflows and tools. i'm not sure why you think we don't? > > > And, specifically: > https://lists.debian.org/debian-devel-announce/2020/04/msg9.html I see only "If your upstream uses Git, it is recommended that you use Git as the version control system for your packaging" (with an explicit "no recommendation otherwise"), a recommendation to use Salsa and suggestions for cases when you already use Git. So it's mostly a recommendation where to put your Git repo and how to configure it if you already decided to use Git. It even implies that no specific branch layout is recommended and omits many other questions. It's also quite interesting that it suggests that using Git if the upstream uses it is useful without explaining why or how, and considering many people just import upstream tarballs. -- WBR, wRAR signature.asc Description: PGP signature
Re: we do recommend workflows (Re: Why Vcs-* fields are not at least recommended ?)
On Wed, Aug 19, 2020 at 09:56:49AM +, Holger Levsen wrote: > On Wed, Aug 19, 2020 at 02:18:08AM +0500, Andrey Rahmatullin wrote: > > And we cannot recommend using a VCS because we don't usually recommend > > workflows. > [...] > > I don't think anything is "supposed" here. We don't recommend workflows > > yes, we do. workflows and tools. i'm not sure why you think we don't? And, specifically: https://lists.debian.org/debian-devel-announce/2020/04/msg9.html It felt to me 2019 was one of the years of endless debates, kind of surprised by that sentence indeed! -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: we do recommend workflows (Re: Why Vcs-* fields are not at least recommended ?)
On Wed, Aug 19, 2020 at 09:56:49AM +, Holger Levsen wrote: > > And we cannot recommend using a VCS because we don't usually recommend > > workflows. > [...] > > I don't think anything is "supposed" here. We don't recommend workflows > > yes, we do. workflows and tools. i'm not sure why you think we don't? We started recommending dh only recently and we still don't recommend using VCS, using git specifically or using a specific git packaging helper. There are many other things we don't recommend, e.g. specific ways to make sure your package is buildable in a minimal chroot. -- WBR, wRAR signature.asc Description: PGP signature
we do recommend workflows (Re: Why Vcs-* fields are not at least recommended ?)
On Wed, Aug 19, 2020 at 02:18:08AM +0500, Andrey Rahmatullin wrote: > And we cannot recommend using a VCS because we don't usually recommend > workflows. [...] > I don't think anything is "supposed" here. We don't recommend workflows yes, we do. workflows and tools. i'm not sure why you think we don't? -- cheers, 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: Why Vcs-* fields are not at least recommended ?
On Wed, Aug 19, 2020 at 02:18:08AM +0500, Andrey Rahmatullin wrote: > On Tue, Aug 18, 2020 at 11:10:04PM +0200, Alexis Murzeau wrote: > > I'm wondering why Vcs-* fields in debian/control (Vcs-Browser and/or > > Vcs-) > > are not recommended (or maybe even strongly recommended) ? (I mean here > > that I think > > having Vcs-* fields should be recommended for active packages) > They are just information fields. You cannot fill them if you aren't using a > VCS. > And we cannot recommend using a VCS because we don't usually recommend > workflows. > > > I acknowledge that previously, packages might not have been developed using > > a VCS as said in the policy. But I think now most packages have a VCS where > > it is developed. > I'm sure (almost) all of these packages already have Vcs-* tags. > > > Also, I see some orphaned packages in the QA group now actively maintained > > without VCS, which seems counterproductive if someone else wants to > > contribute > > too. > > In that case, this would be almost like a NMU I guess, but against an > > "non official maintainer" with manual merges (or lost changes). > > > > Or maybe orphaned package with QA upload are not supposed to be always > > collaboratively maintained ? (I'm new to these concepts, but to me the > > response to this should be "no"). > I don't think anything is "supposed" here. We don't recommend workflows > and if you need to make just one upload for an orphaned package you don't > need to touch any VCS. And for packages without a repo somebody would need > to create one which is extra work when you need to make just one upload. Please, pretty please, make `debcheckout ` possible Groeten Geert Stappers DD -- Silence is hard to parse
Re: Why Vcs-* fields are not at least recommended ?
On Tue, Aug 18, 2020 at 11:10:04PM +0200, Alexis Murzeau wrote: > I'm wondering why Vcs-* fields in debian/control (Vcs-Browser and/or > Vcs-) > are not recommended (or maybe even strongly recommended) ? (I mean here that > I think > having Vcs-* fields should be recommended for active packages) They are just information fields. You cannot fill them if you aren't using a VCS. And we cannot recommend using a VCS because we don't usually recommend workflows. > I acknowledge that previously, packages might not have been developed using > a VCS as said in the policy. But I think now most packages have a VCS where > it is developed. I'm sure (almost) all of these packages already have Vcs-* tags. > Also, I see some orphaned packages in the QA group now actively maintained > without VCS, which seems counterproductive if someone else wants to contribute > too. > In that case, this would be almost like a NMU I guess, but against an > "non official maintainer" with manual merges (or lost changes). > > Or maybe orphaned package with QA upload are not supposed to be always > collaboratively maintained ? (I'm new to these concepts, but to me the > response to this should be "no"). I don't think anything is "supposed" here. We don't recommend workflows and if you need to make just one upload for an orphaned package you don't need to touch any VCS. And for packages without a repo somebody would need to create one which is extra work when you need to make just one upload. -- WBR, wRAR signature.asc Description: PGP signature
