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, 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
(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
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 able to get them uploaded to
unstable.
So i decided to build th
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
> - 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
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 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:
> > >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 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 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
46 matches
Mail list logo
