Re: On init in Debian
On 03/16/2012 06:54 AM, Josselin Mouette wrote: > Le vendredi 16 mars 2012 à 14:26 +0100, Marco d'Itri a écrit : >> How are the upstart developers controversial? Did I miss something? > > Canonical contributor agreement. Hypothetically, if this went away, would it have a substantial impact on the decision? [NOTE: I don't work for Canonical, and don't have a magic wand to poof it away.] I'm curious what the discussion would look like if the only obstacles were technical. And how difficult those technical obstacles would be to solve. Allison -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f637f5c.2090...@lohutok.net
Re: On init in Debian
On 03/16/2012 06:50 PM, Ben Finney wrote: > > Which decision in particular, and by who? Anthropologically speaking, folkmoot is a very different system than top-down rule, but both are among a large variety of systems humans use to collaboratively build things larger than a single individual. In this case, the options I see being weighed are whether to support sysvinit, upstart, or systemd, or some combination. Open discussion is an important part of the moot process (one of the great strengths of having many brains, to examine all angles), but I'd say the "decision" is more a matter of who volunteers to do what. Does that sound about right? > If the Canonical contributor agreement were no longer required for > contributions to a work, then depending on that work for core Debian > features would be significantly less controversial, IMO. Does that > answer your question? Yes, thanks. So, the contributor agreement is a factor, but not the only factor (or even the primary factor). Other parts of the thread explore the technical obstacles more deeply. The paradox is, if the contributor agreement *were* the only obstacle for adoption of upstart, there would be a stronger case for no longer requiring it. > Thanks for explicitly raising the possibility for discussion. Thanks, Allison -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f642ff9.4040...@lohutok.net
Re: On init in Debian
On 03/17/2012 05:20 AM, Ben Finney wrote: > > I don't know what you're asking, which is why I asked you for > clarification of what you mean. > > You asked “if this [requirement for the Canonical contributor agreement > before accepting contributions in ‘upstart’] went away, would it have a > substantial impact on the decision?” and I don't know what “the > decision” you're referring to is. > > There are several being discussed, to be decided by different parties, > as summarized by Lars Wirzenius. Which one are you asking about? Ah, got it. I was asking about any of the variations involving upstart. But, I think Philip's right, that there's a significant difference between supporting it as an alternative and choosing it as a default. > I'm only pointing out that the contributor agreement requirement imposed > by Canonical is, as you asked, IMO a significant part of the > controversy. Okay, thanks, that's useful. Allison -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f64d931.8030...@lohutok.net
Re: On init in *Debian*
On 03/21/2012 09:22 AM, Russ Allbery wrote: > > The primary problem with supporting systemd on kFreeBSD is that it uses > Linux-specific facilities for discovering system events and hence knowing > when to start or stop particular services, and for tracking services so > that it knows when they're started and whether they're still running. > (There may be a few other things as well, but that seems to be the two > major, broad areas of non-trivial Linux-specific functionality.) > > Those are both core to the whole init system and can't be easily done > without by just disabling parallelism or a similar simple fix. > > It's certainly *possible* to implement the same on kFreeBSD and Hurd; I > don't think anyone is questioning that, just the level of work and whether > it will happen. I recall this as one of the key differences: systemd is tightly coupled to the Linux kernel, while upstart is not. I was curious, so asked Scott James Remnant (upstart's creator), and he says it wouldn't be much effort to port upstart to kFreeBSD and Hurd. It would be informative to try the port. Treat it as a pilot project, see how far we can get in a short period of time. Debian has people with extensive experience in porting software to kFreeBSD and Hurd. If a couple of them are interested, we can connect them with with a couple of the upstart core developers and it could move quite quickly. I'd be happy to help, Allison -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f6a0e88.2040...@lohutok.net
Re: Bug#643469: ITP: nqp -- Not Quite Perl compiler
On 09/27/2011 04:38 PM, Alessandro Ghedini wrote: > On Tue, Sep 27, 2011 at 04:04:00PM +0200, Dominique Dumont wrote: >> On Tuesday 27 September 2011 14:39:22 Alessandro Ghedini wrote: >>> * Package name: nqp >> >> This "nqp" name is a bit terse. > > That's how it's called. We have many three-letters-acronym packages and I > may be wrong, but "nqp" doesn't sound like a frequently used trio of > letters. > > Anyway, perl-nqp seems quite misleading (perl not quite perl??), > not-quite-perl, may be ok, but still, I'd rather use the upstream name if > possible. It seems like 'libparrot-nqp' or 'parrot-nqp' might be the best fit. NQP is a parsing/matching library, written for Parrot, intended to be used as part of the compiler tool chain for languages implemented on top of Parrot. Otherwise, 'libperl-nqp'. The 'parrot-devel' package currently Provides 'parrot-nqp', which will have to change if NQP is moving out of the Parrot distribution into a separate distributed tarball and separate source package. Allison -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e81f8b0.4000...@lohutok.net
Re: Bug#643469: ITP: nqp -- Not Quite Perl compiler
On 09/27/2011 06:39 PM, Alessandro Ghedini wrote: > On Tue, Sep 27, 2011 at 05:24:16PM +0100, Allison Randal wrote: > Quoting from the nqp README: >> is focused on being a high-level way to create compilers and libraries >> for virtual machines (such as the Parrot Virtual Machine) > > It doesn't really sound as intended *only* for Parrot (ok, as of now it > does support only parrot, but in the future this may change). The project leads have the intention to port it to other VMs. But, if/when they do, the packaging will need to distinguish between the libraries for Parrot and the libraries for other languages. Maybe the solution is a source package named nqp, with different binary packages libparrot-nqp, libmono-nqp, etc... It's worth talking to Patrick about his plans. > Also, aren't parrot-nqp and nqp different things? (parrot-nqp is currently > used to build nqp). NQP has been through several major refactors. This is just the latest one. It's a bootstrapping compiler, so using a version of itself to build itself is normal. Allison -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e823e47.3020...@lohutok.net
Re: Linux Mint 12 in Debian?
On 11/28/2011 10:56 AM, Svante Signell wrote: > Hi, > > As many people (including me) are very disappointed in gnome3, switching > from a very configurable desktop environment in gnome2 to a almost not > configurable tablet one, is there any chance that Debian could supply > the Mint version too, with many goodies from gnome3 and a gnome2 > look-and-feel? > > Thank you for your time and efforts with Debian. Maybe this mail is more > appropriate in the debian-gtk-gnome mailing list, but as I am currently > subscribed to debian-devel, not the other one, please just tell me to > use the other list, and I'll subscribe and move my question there. I'd suggest it needs to go one step further upstream, and contribute the Linux Mint extensions for gnome3 to the GNOME project. I have already put the MATE developers in touch with GNOME, happy to do the same for Linux Mint if they don't already have contacts there. Allison -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ed3e69e.9080...@lohutok.net
Re: The end of OpenStack packages in Debian?
On 02/15/2017 07:42 AM, Thomas Goirand wrote: > I will continue to maintain OpenStack Newton during the lifetime of > Debian Stretch though, but I don't plan on doing anything more. This > means that maybe, Newton will be the last release of OpenStack in > Debian. If things continue this way, I probably will ask for the removal > of all OpenStack packages from Debian Sid after Stretch gets released > (unless I know that someone will do the work). I'm happy to volunteer for this. TBH, my goal would be to minimize the delta on these packages to Ubuntu's versions of the packages, so we can maintain them collaboratively. But, there's certainly no need to drop the packages from Debian. > As a consequence, the following projects wont get packages even in > Ubuntu (as they were "community maintained", which means done by me and > later sync into Ubuntu...): > > - congress > - gnocchi > - magnum > - mistral > - murano > - sahara > - senlin > - watcher > - zaqar These are more "nice to have" packages, not really critical. We can ask around to see if anyone is using the packaged versions, but if not we should just drop them from Debian. > Hopefully, Canonical will continue to maintain the other 15 (more > core...) projects in UCA. Canonical doesn't have a large team for this work, but I imagine we can handle it just fine between their team and a few volunteers. Allison
Re: [openstack-dev] The end of OpenStack packages in Debian?
On 02/21/2017 12:57 PM, Ritesh Raj Sarraf wrote: > Hello Thomas, > > Sad to see this. But with so much free loading trend, these are bound to > happen. > > For the LIO-fb target in Debian, we've been depending on the rtslib-fb > package, > which you've maintained so far. Should we pick it up under the > pkg-linux-target > team ? Hi Ritesh, For the sake of consistency, it probably makes more sense to maintain rtslib-fb within the Debian Python Modules Team. If you'd like to chat in more detail about which Debian team is the best fit, we can narrow this thread down to just the PKG OpenStack mailing list. Thanks, Allison signature.asc Description: OpenPGP digital signature
Re: [PKG-Openstack-devel] [openstack-dev] The end of OpenStack packages in Debian?
On 02/24/2017 06:25 AM, Ritesh Raj Sarraf wrote: > rtslib-fb is a core component for the LIO(-fb) project. We already maintain > configshell-fb and targetcli-fb under pkg-linux-target group. Nod, that makes sense. I'd say you should take on maintenance of the rtslib-fb packages, as long as you're willing to integrate with the global Debian Python transitions and policy, and to handle the fact that other projects (like the OpenStack Debian packagers) also use the module. For OpenStack, we may occasionally need to update the rtslib-fb packages to specific versions for compatibility with specific OpenStack releases. Allison signature.asc Description: OpenPGP digital signature
