Re: Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing
On 12/19/18 1:05 AM, Philipp Kern wrote: > In the Ubuntu PPA case you get free reign over what's in that archive > and what you backport as part of offering the package. Obviously this > might conflict with the existing set. But the same is true for a > centralized volatile archive if you need to backport a large set of > build dependencies to make the whole thing work in the first place. And > I'm sure you wouldn't just go for a gitlab source package with bundled > build dependencies. That is why I prefer it as an extension of backports where the dependencies still follow the regular release cycle, they should be in testing and that means doing proper transitions for breaking changes and only the gitlab package itself be kept in volatile. > Now the policy question of who can ship what in a way that looks > semi-officially as being part of Debian is tricky. I personally find the > notion that testing should just be the staging ground for the next > release to be unfortunate but at the same time know how we ended up with > it. Maybe there's a place for packages that cannot usefully be supported > for a stable release and hence need to live in parallel. But then again > I wonder if the answer wouldn't be an archive where the input is built > for all suites and where the dependencies are bundled - if only because > you'd track upstream closely and would through that (hopefully) pull in > necessary security updates. I think it is still possible to maintain dependencies without bundling if it is like backports, ie, we can update them to newer upstream versions. Hence the requirement to redefine volatile. If they are not accepted in backports, a lot of packages will be duplicated, but even that is okay if backports team is not happy to take the new packages. And if this discussions go no where, the only option would be to make it an installer package, like diaspora-installer. But I'm not sure if it'd add much value over upstream provided omnibus packages. > Kind regards > Philipp Kern > > [1] And to some degree I am unhappy with backports' team's antagonistic > view on volatile here. Stuff like gitlab would have been rejected in the > same way it would've been in backports. The useful bits live on, it > wasn't abandoned to cause more work for backports. At the same time > backports can serve as a replacement of a subset of use cases too, where > its rules fit just fine. Thanks for sharing this. signature.asc Description: OpenPGP digital signature
Re: Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing
>> We had volatile, which, redefined properly, could help. I am trying >to draft such a definition. > >Did you get a chance to work on it? I do have this on my todo list for around Christmas. People who know me that I deliberately leave out the year, but my intentions are 2018 ;). -nik
Re: Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing
On Wednesday, 19 December 2018 2:11:43 AM AEDT Holger Levsen wrote: > instead of volatile we need PPAs. I think concept of "volatile" is better, stronger. PPA allows people to ship whatever they want without cooperating in policy compliant (official) repo. This is the Debian way where many people work together in one centralized resource. Many people working in many places (PPA) will undermine cooperativeness and trust - a something we can only have in backports-like "volatile" repo. -- Cheers, Dmitry Smirnov. --- The great enemy of the truth is very often not the lie -- deliberate, contrived and dishonest, but the myth, persistent, persuasive, and unrealistic. Belief in myths allows the comfort of opinion without the discomfort of thought. -- John F Kennedy signature.asc Description: This is a digitally signed message part.
Re: Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing
On Wednesday, 19 December 2018 9:17:51 AM AEDT Thorsten Glaser wrote: > Did you mean: in an unstable-like “volatile” repo? Yes perhaps more like "unstable". I'm saying that IMHO we should have only one common/shared "PPA" for "stable" users. I do not want many personal/individual archives. > Backports have a defined mission, which has nothing to do > with the “volatile” proposal. What you were referring to, > integration- and checks-wise, is, I think what you get in > *any* repository maintained by ftpmasters, so it’d be more > like sid, except only a partial distribution (add-on). I also think that we could just relax official "backports" criteria but that would be so hard that it seem easier to arrange another "volatile" repo... -- Regards, Dmitry Smirnov. --- Success consists of going from failure to failure without loss of enthusiasm. -- Winston Churchill signature.asc Description: This is a digitally signed message part.
Re: Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing
On Wed, 19 Dec 2018, Dmitry Smirnov wrote: > trust - a something we can only have in backports-like "volatile" repo. Did you mean: in an unstable-like “volatile” repo? Backports have a defined mission, which has nothing to do with the “volatile” proposal. What you were referring to, integration- and checks-wise, is, I think what you get in *any* repository maintained by ftpmasters, so it’d be more like sid, except only a partial distribution (add-on). bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing
On 2018-12-18 18:40, Pirate Praveen wrote: On 12/18/18 8:41 PM, Holger Levsen wrote: On Tue, Dec 18, 2018 at 08:38:39PM +0530, Pirate Praveen wrote: But if that is not possible, volatile as a separate archive is also fine. instead of volatile we need PPAs. I think a redefined volatile is the best option for sharing work. But PPA approach is best in case of conflicts. I'm leaning towards volatile and hence I proposed it. If you feel strongly about PPAs, please propose and drive it. Either option will work for me. Just for the record - I know you say "a redefined volatile" - and as a former volatile team member: This would in no way have been suitable for volatile either. Just like backports the assumption is that the packages are up to Debian's quality standards and we make the result available to users of stable earlier. Volatile's mission statement was keeping software like virus scanners actually useful while doing minimal changes to stable and that was the main reason for folding it into the regular release as well as creating -updates to have a timely push mechanism.[1] In the Ubuntu PPA case you get free reign over what's in that archive and what you backport as part of offering the package. Obviously this might conflict with the existing set. But the same is true for a centralized volatile archive if you need to backport a large set of build dependencies to make the whole thing work in the first place. And I'm sure you wouldn't just go for a gitlab source package with bundled build dependencies. Now the policy question of who can ship what in a way that looks semi-officially as being part of Debian is tricky. I personally find the notion that testing should just be the staging ground for the next release to be unfortunate but at the same time know how we ended up with it. Maybe there's a place for packages that cannot usefully be supported for a stable release and hence need to live in parallel. But then again I wonder if the answer wouldn't be an archive where the input is built for all suites and where the dependencies are bundled - if only because you'd track upstream closely and would through that (hopefully) pull in necessary security updates. Kind regards Philipp Kern [1] And to some degree I am unhappy with backports' team's antagonistic view on volatile here. Stuff like gitlab would have been rejected in the same way it would've been in backports. The useful bits live on, it wasn't abandoned to cause more work for backports. At the same time backports can serve as a replacement of a subset of use cases too, where its rules fit just fine.
Re: Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing
On 12/18/18 8:41 PM, Holger Levsen wrote: > On Tue, Dec 18, 2018 at 08:38:39PM +0530, Pirate Praveen wrote: >> But if that is not possible, volatile as a separate archive is also fine. > > instead of volatile we need PPAs. I think a redefined volatile is the best option for sharing work. But PPA approach is best in case of conflicts. I'm leaning towards volatile and hence I proposed it. If you feel strongly about PPAs, please propose and drive it. Either option will work for me. signature.asc Description: OpenPGP digital signature
Re: Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing
On Tue, Dec 18, 2018 at 10:12 AM Holger Levsen wrote: > On Tue, Dec 18, 2018 at 08:38:39PM +0530, Pirate Praveen wrote: > > But if that is not possible, volatile as a separate archive is also fine. > > instead of volatile we need PPAs. Shortly before the Stretch release, when I was scrambling to find a way to provide updates for webkit2gtk for Stretch's lifetime, I think volatile was suggested as something that was able to sort of do what I needed. But it's not a good example since Debian Security ought to handle webkit2gtk updates for Buster, as is done with Firefox ESR and Chromium. Thanks, Jeremy Bicha
Re: Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing
On Tue, Dec 18, 2018 at 08:38:39PM +0530, Pirate Praveen wrote: > But if that is not possible, volatile as a separate archive is also fine. instead of volatile we need PPAs. -- 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: Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing
On 2018, ഡിസംബർ 18 7:14:14 PM IST, Rhonda D'Vine wrote: > And yes, I'm with Alexander, the volatile maintenance can't be dumped >on the backports team. It's a different workflow anyway. My proposal for backports is to have only the dependencies of packages in volatile that fall in the current definition of backports kept there, ie, 1. They are already in testing and 2. will be part of next stable. And use volatile only for packages that cannot fit this criteria. I'd be happy to join the backports team to help with the extra load. I hope others will join too. But if that is not possible, volatile as a separate archive is also fine. It is just that many packages will have to be in both archives and that is a lot of extra work, which I think can be avoided. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing
Hey, * Pirate Praveen [2018-12-18 09:34:46 CET]: > On 12/3/18 8:11 PM, Dominik George wrote: > >> well, Debian is using gitlab!!! so this sentence has no sense. The > >> problem here > >> is that is a complex software that depends of a lot of pieces and it's > >> not > >> easy/possible to fit the definition. So, maybe we should create another > >> category > >> of software. > > > > Yes, and that Debian officially uses GitLab, from a foreign source, without > > being able to support it in Debian, does make me feel ashamed for the > > project. > > > >> maybe creating another kind of repo. debian-contributuions > >> debian-blabla, whatever. > >> > > > > We had volatile, which, redefined properly, could help. I am trying to > > draft such a definition. > > Did you get a chance to work on it? Yes, it looks very much that the shutting down of volatile made wishes appear for backports to cover it - while it wasn't (and shouldn't) be the scope for it. It would make it indistinguishable which packages within backports are following the regular rules and which would be those fast moving targets without any useful tracking or upgrade features in the regular sense. (Part of that was btw. also the creation of a seperate sloppy pocket for backports from oldstable+2 releases, to make it clear what to expect in there) And yes, I'm with Alexander, the volatile maintenance can't be dumped on the backports team. It's a different workflow anyway. Good luck, Rhonda -- Fühlst du dich mutlos, fass endlich Mut, los | Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden Fühlst du dich machtlos, geh raus und mach, los | 23.55: Alles auf Anfang Fühlst du dich haltlos, such Halt und lass los|
Re: Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing
On Tue, 18 Dec 2018, Pirate Praveen wrote: > [adding -devel to cc] > > On 12/3/18 8:11 PM, Dominik George wrote: > >> well, Debian is using gitlab!!! so this sentence has no sense. The > >> problem here > >> is that is a complex software that depends of a lot of pieces and it's > >> not > >> easy/possible to fit the definition. So, maybe we should create another > >> category > >> of software. > > > > Yes, and that Debian officially uses GitLab, from a foreign source, without > > being able to support it in Debian, does make me feel ashamed for the > > project. > > > >> maybe creating another kind of repo. debian-contributuions > >> debian-blabla, whatever. > >> > > > > We had volatile, which, redefined properly, could help. I am trying to > > draft such a definition. > > Did you get a chance to work on it? > > I think it has to be an extension of backports with dependencies that > fall within the backports criteria being maintained in backports and > only packages that cannot be in backports maintained in volatile. > > Original definition of volatile from https://www.debian.org/volatile/: > "Some packages aim at fast moving targets, such as spam filtering and > virus scanning, and even when using updated data patterns, they do not > really work for the full time of a stable release. The main goal of > volatile is allowing system administrators to update their systems in a > nice, consistent way, without getting the drawbacks of using unstable, > even without getting the drawbacks for the selected packages. So > debian-volatile will only contain changes to stable programs that are > necessary to keep them functional." > > Proposed definition: > "Some packages aim at fast moving targets, such as complex web based > software with very small release cycles and new dependencies, they do > not receive security support or bug fixes for the full time of a stable > release. This means backporting targeted fixes are impossible. The main > goal of volatile is allowing system administrators to update their > systems in a nice, consistent way, without getting the drawbacks of > using unstable, even without getting the drawbacks for the selected > packages. New dependencies introduced can be maintained in backports > repository. So debian-volatile will be an extension of debian-backports, > with dependencies that fall within the criteria maintained in > debian-backports." I don't think that -backports is the right suite. It should be something new, with a new team. Alex signature.asc Description: PGP signature
Re: Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing
[adding -devel to cc] On 12/3/18 8:11 PM, Dominik George wrote: >> well, Debian is using gitlab!!! so this sentence has no sense. The >> problem here >> is that is a complex software that depends of a lot of pieces and it's >> not >> easy/possible to fit the definition. So, maybe we should create another >> category >> of software. > > Yes, and that Debian officially uses GitLab, from a foreign source, without > being able to support it in Debian, does make me feel ashamed for the project. > >> maybe creating another kind of repo. debian-contributuions >> debian-blabla, whatever. >> > > We had volatile, which, redefined properly, could help. I am trying to draft > such a definition. Did you get a chance to work on it? I think it has to be an extension of backports with dependencies that fall within the backports criteria being maintained in backports and only packages that cannot be in backports maintained in volatile. Original definition of volatile from https://www.debian.org/volatile/: "Some packages aim at fast moving targets, such as spam filtering and virus scanning, and even when using updated data patterns, they do not really work for the full time of a stable release. The main goal of volatile is allowing system administrators to update their systems in a nice, consistent way, without getting the drawbacks of using unstable, even without getting the drawbacks for the selected packages. So debian-volatile will only contain changes to stable programs that are necessary to keep them functional." Proposed definition: "Some packages aim at fast moving targets, such as complex web based software with very small release cycles and new dependencies, they do not receive security support or bug fixes for the full time of a stable release. This means backporting targeted fixes are impossible. The main goal of volatile is allowing system administrators to update their systems in a nice, consistent way, without getting the drawbacks of using unstable, even without getting the drawbacks for the selected packages. New dependencies introduced can be maintained in backports repository. So debian-volatile will be an extension of debian-backports, with dependencies that fall within the criteria maintained in debian-backports." signature.asc Description: OpenPGP digital signature
