On 2019, ജൂലൈ 28 6:36:21 PM IST, Phil Morrell wrote:
>On Tue, Jan 01, 2019 at 05:49:37PM +0530, Pirate Praveen wrote:
>> I think STS (Short term support) will fit nicely with LTS. If there
>is
>> no serious objections, I'd go with this.
>
>As debconf is finishing, though I don't know if either
On Tue, Jan 01, 2019 at 05:49:37PM +0530, Pirate Praveen wrote:
> I think STS (Short term support) will fit nicely with LTS. If there is
> no serious objections, I'd go with this.
As debconf is finishing, though I don't know if either of you attended
this year, has there been any progress on this
Hi Dominik,
On 26/12/18 2:16 am, Dominik George wrote:
> Heisann, alle sammen,
>
> as announced in the recent thread about maintaining, I hereby propose a
> repository that allows making “backports” of packages available to users
> of the stable distribution, if those packages cannot be maintained
Hi Dominik,
happy new year to you and everybody.
I read your proposal, and the whole discussion with great interest.
In brief, I think that it would be wise to uncouple the fast-paced
("fast-forwards" ?) repository that you propose from the stable backports,
and I hope that you will be able to g
On Mon, Dec 31, 2018 at 1:06 PM Ben Hutchings wrote:
> At the risk of bikeshedding, some alternate names that might be less
> confusing:
>
> - fresh-apps
> - evergreen
> - rolling-apps
At further risk of bikeshedding, how about "sideports"?
1. Uses a metaphor rather similar to backports.
2. Sorts
On 1/1/19 3:42 PM, Scott Leggett wrote:
> To continue the bikeshedding, what about "express"? Seems quite fitting
> as the packages don't make the usual stop through testing...
I think STS (Short term support) will fit nicely with LTS. If there is
no serious objections, I'd go with this.
signat
On 2018-12-31.18:06, Ben Hutchings wrote:
> On Mon, 2018-12-31 at 18:31 +0100, Jonas Meurer wrote:
> > Pirate Praveen:
> > > On 2018, ഡിസംബർ 31 5:19:22 PM IST, Jonas Meurer
> > > wrote:
> > > >
> > > > Please don't name it 'rolling'. This term is used a lot in the sense of
> > > > 'rolling relea
On Mon, 2018-12-31 at 18:31 +0100, Jonas Meurer wrote:
> Pirate Praveen:
> > On 2018, ഡിസംബർ 31 5:19:22 PM IST, Jonas Meurer
> > wrote:
> > > Pirate Praveen:
> > > > On 12/28/18 11:06 AM, Thomas Goirand wrote:
> > > > > If the problem is hardware and connectivity, then IMO you can easily
> > > >
Pirate Praveen:
> On 2018, ഡിസംബർ 31 5:19:22 PM IST, Jonas Meurer wrote:
>> Pirate Praveen:
>>> On 12/28/18 11:06 AM, Thomas Goirand wrote:
If the problem is hardware and connectivity, then IMO you can easily
find a sponsor for it. My company could well offer it for example
(hosted
On 2018, ഡിസംബർ 31 5:19:22 PM IST, Jonas Meurer wrote:
>Pirate Praveen:
>> On 12/28/18 11:06 AM, Thomas Goirand wrote:
>>> If the problem is hardware and connectivity, then IMO you can easily
>>> find a sponsor for it. My company could well offer it for example
>>> (hosted in Geneva with very n
Pirate Praveen:
> On 12/28/18 11:06 AM, Thomas Goirand wrote:
>> If the problem is hardware and connectivity, then IMO you can easily
>> find a sponsor for it. My company could well offer it for example
>> (hosted in Geneva with very nice connectivity to almost everywhere).
>>
>> Setting-up a repos
On 12/30/18 8:02 AM, Pirate Praveen wrote:
> On 12/28/18 11:06 AM, Thomas Goirand wrote:
>>> If you know how to start with a new service at
>>> {volatile,fastpaced,whatever}.debian.net without having to reinvent the
>>> wheel for acceptign uploads, getting packages built, etc., please
>>> enlighten
On 12/30/18 12:47 AM, Wouter Verhelst wrote:
> On Wed, Dec 26, 2018 at 07:19:02PM +0100, Dominik George wrote:
>> - It costs a lot time that could better be used elsewhere.
>> - It costs extra money, which I for one do not have to spare.
>
> So ask someone who does and who would care about this
On 12/28/18 11:06 AM, Thomas Goirand wrote:
> If the problem is hardware and connectivity, then IMO you can easily
> find a sponsor for it. My company could well offer it for example
> (hosted in Geneva with very nice connectivity to almost everywhere).
>
> Setting-up a repository isn't hard. And
On Wed, Dec 26, 2018 at 07:19:02PM +0100, Dominik George wrote:
> > If you don't see obstacles, why not start today?
>
> I think I already made those obstacles clear: Starting outside means
> buying,
(or getting donated)
> installing and operating at least a server vor volatile.debian.net (o
On 12/26/18 8:16 PM, Dominik George wrote:
>> For backports the general supportability assumption is that you provide a
>> sane upgrade path from stable to the backports and from the backport to the
>> next stable (optimally the same package). Once you take the presence of the
>> stable package out
On 12/27/18 10:49 AM, L.P.H. van Belle wrote:
>
> Hai,
>
> A very interesting thread this, since im doing this already for samba, my
> comments..
> If i may ..
>
> Im running a samba repo now for jessie and stretch. ( and ubuntu 18.04 )
> I really needed newer samba packages and i was not ab
On 12/27/18 3:06 PM, Dominik George wrote:
>> Basically you would like to build an architecture equivalent to Ubuntu's
>> PPA
>
> No. Please at least try reading the thread first - it was explicitly
> explained several times that this has absolutely nothing to do with the
> idea of PPAs.
Well, I
Thomas Goirand schrieb:
> And for a start, I don't think you really need a buildd network, just amd64
> is ok-ish.
Agreed. If there's actual demand for further architecture support,
it will appear naturally by people offering to do the necessary
setup.
Cheers,
Moritz
(Please reply to pkg-samba-maint only)
Le jeu. 27 déc. 2018 à 11:00, L.P.H. van Belle a écrit :
>
>
> Hai,
Hi,
> A very interesting thread this, since im doing this already for samba, my
> comments..
> If i may ..
>
> Im running a samba repo now for jessie and stretch. ( and ubuntu 18.04 )
> I
On 12/26/18 7:19 PM, Dominik George wrote:
> Hi,
>
>> 2. I am happy with the current charter of backports and I think it's
>> possible to move forward with fastpaced without having to change
>> that charter.
>
> Yep. That's exactly why the proposal changes nothing about -backports. I
> a
On 12/26/18 5:45 PM, Dominik George wrote:
> On Wed, Dec 26, 2018 at 03:05:55PM +0100, gregor herrmann wrote:
>> And besides that, I think the more universal answer is
>> bikesheds/PPAs/you-name-it instead of yet-another-suite.
>
> Absolutely not. It might be an answer, but to an entirely differen
> Basically you would like to build an architecture equivalent to Ubuntu's
> PPA
No. Please at least try reading the thread first - it was explicitly
explained several times that this has absolutely nothing to do with the
idea of PPAs.
-nik
signature.asc
Description: PGP signature
Hi guys,
Trying to make sure I understand clearly this long thread here.
Basically you would like to build an architecture equivalent to Ubuntu's
PPA that users could add to their apt sources to get newer versions faster
instead of dealing with their apt preferences?
I personally like the curren
Den 27. desember 2018 12:30:33 CET, skrev Holger Levsen :
>On Wed, Dec 26, 2018 at 11:37:21PM +0100, Dominik George wrote:
>> As long as the package is in -volatile
>
>FYI: as long as this proposal is been presented with the name -volatile
>it's dead to me and saves me from reading mails in this th
On Wed, Dec 26, 2018 at 11:37:21PM +0100, Dominik George wrote:
> As long as the package is in -volatile
FYI: as long as this proposal is been presented with the name -volatile
it's dead to me and saves me from reading mails in this thread.
Please try to listen if you start a discussion.
--
ch
erzonden: dinsdag 25 december 2018 21:46
> Aan: debian-devel@lists.debian.org;
> debian-backpo...@lists.debian.org; debian-rele...@lists.debian.org
> Onderwerp: Proposal: Repository for fast-paced package backports
>
> Heisann, alle sammen,
>
> as announced in the rece
On 12/25/18 3:46 PM, Dominik George wrote:
[...]
>
> Name of the new repository
> ==
>
> In the past, the name “volatile” was used for a similar repository, but
> with a different scope (limited to data packages for things like virus
> scanners). I will thus use the work
Hi,
> How to handle upgrades from stable to stable+1. Packages from backports
> upgrade with no issues as stable+1 contains the same packages already
> compiled for the stable+1.
As long as the package is in -volatile, it is not in stable+1, and
upgrades are ensured by the volatile maintainer. If
> For backports the general supportability assumption is that you provide a
> sane upgrade path from stable to the backports and from the backport to the
> next stable (optimally the same package). Once you take the presence of the
> stable package out of the mix, it becomes weird. How long do you
On 26/12/2018 19:31, Dominik George wrote:
- The package must not be in testing, and care must be taken for the
package not to migrate to testing.
So what would a user of testing do? Will there be a $codename-volatile[1]
suite for testing users? Or would they directly install unstable wi
> - Should the package begin to migrate to testing again, it must
>be moved to stable-backports.
>
> - Using the same ~bpo version namespace
Both of these poitns are there to *not* change anything about backports.
If a package stops qualifying for -volatile, and starts qualifying for
-backp
Dominik George wrote:
> Jonathan Nieder wrote:
>> 2. I am happy with the current charter of backports and I think it's
>> possible to move forward with fastpaced without having to change
>> that charter.
>
> Yep. That's exactly why the proposal changes nothing about -backports. I
> am sti
> > - The package must not be in testing, and care must be taken for the
> > package not to migrate to testing.
> So what would a user of testing do? Will there be a $codename-volatile[1]
> suite for testing users? Or would they directly install unstable with no
> other pre-release staging gr
Hi,
> 2. I am happy with the current charter of backports and I think it's
> possible to move forward with fastpaced without having to change
> that charter.
Yep. That's exactly why the proposal changes nothing about -backports. I
am still confused why Alex and you keep insisting that an
On 25/12/2018 21:46, Dominik George wrote:
Requirements for a package to go into stable-volatile
=
The new volatile proposal is not intended to ease life for package
maintainers who want to bypass the migration and QA requirements of the
regula
On Wed, 26 Dec 2018, Dominik George wrote:
> > >If there are other issues to solve than the lifespan of the package
> > >version, they must be solved in another way.
> >
> > I agree with you, it is the best outcome. But when people with power
> > (-backports ftp masters) are not willing to consid
Hi,
Pirate Praveen wrote:
> I agree with you, it is the best outcome. But when people with power
> (-backports ftp masters) are not willing to consider it, we have to
> go with plan B, which is less than ideal, but can move things
> forward.
Just to avoid this being thought of as an idiosyncrasy
On Wed, 26 Dec 2018, Pirate Praveen wrote:
>
>
> On 2018, ഡിസംബർ 26 10:15:35 PM IST, Dominik George
> wrote:
> >No. The dpendencies of gitlab not being accepted into backports right
> >now is an entirely different issue. I am repeating myself: This
> >proposal
> >is not intended to ease the li
> >If there are other issues to solve than the lifespan of the package
> >version, they must be solved in another way.
>
> I agree with you, it is the best outcome. But when people with power
> (-backports ftp masters) are not willing to consider it, we have to go
> with plan B, which is less than
On 2018, ഡിസംബർ 26 10:15:35 PM IST, Dominik George
wrote:
>No. The dpendencies of gitlab not being accepted into backports right
>now is an entirely different issue. I am repeating myself: This
>proposal
>is not intended to ease the life of maintainers whose packages qulify
>for -backports. Th
On Wed, 26 Dec 2018, Dominik George wrote:
> > I don't want backports to contain things are are not suited for a
> > release.
>
> That's why we are doing all this. It is NOT about anything to backports.
> It is about adding something new that uses the same RULES as backports,
> with a slight dive
> I don't want backports to contain things are are not suited for a
> release.
That's why we are doing all this. It is NOT about anything to backports.
It is about adding something new that uses the same RULES as backports,
with a slight diversion, and thus can also make use of infrastructure
alre
On Wed, 26 Dec 2018, Dominik George wrote:
> Hi,
>
> On Wed, Dec 26, 2018 at 03:05:55PM +0100, gregor herrmann wrote:
> > (Can we keep this on one mailing list, please? /me restricts this to
> > -devel)
>
> No. This has the potential of keeping people who are directly impacted
> by this proposal
Hi,
On Wed, Dec 26, 2018 at 03:05:55PM +0100, gregor herrmann wrote:
> (Can we keep this on one mailing list, please? /me restricts this to
> -devel)
No. This has the potential of keeping people who are directly impacted
by this proposal out of the loop.
> And besides that, I think the more univ
On Wed, 26 Dec 2018, Pirate Praveen wrote:
>
>
> On 2018, ഡിസംബർ 26 2:16:07 AM IST, Dominik George
> wrote:
> >Heisann, alle sammen,
> >
> >as announced in the recent thread about maintaining, I hereby propose a
> >repository that allows making “backports” of packages available to
> >users
> >
On Wed, Dec 26, 2018 at 02:35:19PM +0100, Dominik George wrote:
> >volatile is a very bad name for this because we've used it already for
> >something else.
> Well, I consider it more or less the same basic idea. The old and new ideas
> have more in common than not, with the only difference being
[As requested, keeping it to -devel only]
On 12/26/18 7:35 PM, Antonio Terceiro wrote:
> On Wed, Dec 26, 2018 at 01:04:44PM +0530, Pirate Praveen wrote:
>> If it has to be completely separate from -backports, it means some packages
>> will need to be maintained twice, even when they meet the crit
On 2018-12-26 15:05, gregor herrmann wrote:
> (Can we keep this on one mailing list, please? /me restricts this to
> -devel)
Agreed.
> And besides that, I think the more universal answer is
> bikesheds/PPAs/you-name-it instead of yet-another-suite.
IMHO, this is not the same. Both "volatile/fast
On Wed, 26 Dec 2018 13:07:07 +, Holger Levsen wrote:
(Can we keep this on one mailing list, please? /me restricts this to
-devel)
> On Wed, Dec 26, 2018 at 12:07:42AM +0100, Dominik George wrote:
> > I actually think volatile is a good name. After all, it's not so far from
> > the previous v
On Wed, Dec 26, 2018 at 01:04:44PM +0530, Pirate Praveen wrote:
> If it has to be completely separate from -backports, it means some packages
> will need to be maintained twice, even when they meet the criteria for
> backports fully, just because a package in volatile declare a dependency on
> t
>> I actually think volatile is a good name. After all, it's not so far
>from the previous volatile.
>
>volatile is a very bad name for this because we've used it already for
>something else.
Well, I consider it more or less the same basic idea. The old and new ideas
have more in common than not,
On Wed, Dec 26, 2018 at 12:07:42AM +0100, Dominik George wrote:
> I actually think volatile is a good name. After all, it's not so far from the
> previous volatile.
volatile is a very bad name for this because we've used it already for
something else.
--
cheers,
Holger
---
On 2018, ഡിസംബർ 26 2:16:07 AM IST, Dominik George
wrote:
>Heisann, alle sammen,
>
>as announced in the recent thread about maintaining, I hereby propose a
>repository that allows making “backports” of packages available to
>users
>of the stable distribution, if those packages cannot be maintai
> - no need to keep a volatile package out of testing
Oh, and yes. Having a package in testing means it will be supported for a
stable lifecycle - a full contradiction to volatile!
-nik
Hi,
>I would, however, completely separate it from backports. I.e.
>
> - separate NEW queue
> - different suffix
> - no need to keep a volatile package out of testing
>
>Why?
>
> - volatile is a different beast from backports, this should be
> very clear to both package maintainers and our users
Hi all,
I like the idea of having a volatile archive and I agree with
almost all what Dominik wrote about the motivation.
I would, however, completely separate it from backports. I.e.
- separate NEW queue
- different suffix
- no need to keep a volatile package out of testing
Why?
- volatil
>Just to make things a bit clearer for people who may not have followed
>some of the discussions on d-bp-users lately: the point is to be able
>to
>support fast-moving software with not-so-fast moving dependencies;
>the dependencies may easily be backported without too large a burden
>(their versio
On Tue, Dec 25, 2018 at 11:52:07PM +0100, Dominik George wrote:
> Hi,
>
> >having read the whole Gitlab discussion, I still don't get how/why the
> >new repository depends or relates to backports. Instead it could be
> >self-contained, except for stuff already available in stable. Couldn't
> >you
Hi,
I like the general direction, but there are some aspects of your
>proposal
>which should be improved.
Thanks!
>> Other ideas: fastlane, unsupported
>
>Or maybe something like "fastpaced", after all this repo would not be
>unsupported at all, the very point is to provide actual support after
Hi all,
having read the whole Gitlab discussion, I still don't get how/why the new
repository depends or relates to backports. Instead it could be self-contained,
except for stuff already available in stable. Couldn't you roll the new
repository entirely independent of any backports? Even if yo
Hi,
>having read the whole Gitlab discussion, I still don't get how/why the
>new repository depends or relates to backports. Instead it could be
>self-contained, except for stuff already available in stable. Couldn't
>you roll the new repository entirely independent of any backports? Even
>if you
> In short: This proposal addresses the exact concerns you raised before
> )although I am not the person you expressed them towards).
Well, sure, I was involved in that thread, but only in the way that I
announced a proposal (this one). Not in any of the stuff concerning
adding something to -backp
On Tue, Dec 25, 2018 at 10:11:43PM +0100, Alexander Wirt wrote:
> https://lists.debian.org/debian-backports/2018/12/msg00028.html
>
> This wasn't about gitlab.
Oh. I must have misread the "gitlab" in the subject, along withthe mail
being sent to the gitlab maintainer, a gitlab bugreport in the B
On Tue, 25 Dec 2018, Dominik George wrote:
> > We already told you to build your own repo.
>
> You should probably start with identifying the senders of mail
> correctly ☺. I am not the gitlab maintainer (and will never be).
https://lists.debian.org/debian-backports/2018/12/msg00028.html
This wa
> We already told you to build your own repo.
You should probably start with identifying the senders of mail
correctly ☺. I am not the gitlab maintainer (and will never be).
> Imho you should start the same way backports started - outside of
> debian.
> Prove that it works and integrate into Debi
On Tue, 25 Dec 2018, Dominik George wrote:
> Heisann, alle sammen,
>
> as announced in the recent thread about maintaining, I hereby propose a
> repository that allows making “backports” of packages available to users
> of the stable distribution, if those packages cannot be maintained in
> testi
Heisann, alle sammen,
as announced in the recent thread about maintaining, I hereby propose a
repository that allows making “backports” of packages available to users
of the stable distribution, if those packages cannot be maintained in
testing and backported in the usual way. If you are intereste
68 matches
Mail list logo
