Re: Request for Adding Ubuntu Kylin Archive
It's not really clear to me whether the software intended for this archive is free or not? What exactly does commercial mean in this context? /Soren On Apr 1, 2014 7:38 PM, jac...@ubuntukylin.com wrote: Hi Technical Board, I'm writing to request to add an archive for Ubuntu Kylin flavor. This archive mainly includes Chinese commercial packages co-developed by Ubuntu Kylin team and commercial companies. We also developed a software center client that supports both Ubuntu archive and Ubuntu Kylin archive. This request have already been supported by Jason, Leonard, Anthony, etc. from Canonical team. We know that in the rules of Ubuntu, flavors are not allowed to add archives. However, Ubuntu Kylin is a little special since it mainly focuses on Chinese users. Our partners (Such as Sogou, King soft) want to locate their apps in China. Do you have any comments on this? Thanks in advance. -- Regards, Jack Yu UbuntuKylin Team -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Retiring from TB at end of term
2013/7/9 Colin Watson cjwat...@ubuntu.com: I'd like to give advance notice that I intend to retire from the Ubuntu Technical Board at the end of my current term (2013-10-06 according to Launchpad), and do not intend to seek re-election. Let me be the first to thank you for the time and effort you've put into the Technical Board over these four years. It's been an honour serving with you. Your successor has big shoes to fill. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Apologies: Monday's meeting
Yikes, me too. I'm in Portland and hadn't thought of the timezone change impact on this meeting time. Sorry for the *very* late notice. 2013/4/15 Kees Cook k...@ubuntu.com: On Wed, Apr 10, 2013 at 03:00:16PM -0700, Matt Zimmerman wrote: I won't be able to make it to the meeting Monday due to a work conflict. I'll also be unavailable. Sorry for the late notice! -Kees -- Kees Cook -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board -- Soren Hansen | http://linux2go.dk/ Senior Software Engineer | http://www.cisco.com/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: needing to add engineering management to UDS Organizers
2013/3/21 kevin gunn kevin.g...@canonical.com: Hi, Can we please have the following people added to the UDS Organizers team ? Kevin Gunn lp id: kgunn72 Thomas Voss lp id: thomas-voss Thomas Strehl lp id: strehl-t Oliver Ries lp id: ories Done. -- Soren Hansen | http://linux2go.dk/ Senior Software Engineer | http://www.cisco.com/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies for this evening
I'm afraid I also can't make the meeting this evening. Sorry about the short notice. -- Soren Hansen | http://linux2go.dk/ Senior Software Engineer | http://www.cisco.com/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Updated release management straw man for TB consideration
2013/3/12 Mark Shuttleworth m...@ubuntu.com: Am writing to ask you to weigh in on an updated release management proposal. Details are on Planet Ubuntu, salient portion of the proposal is: Thanks for raising these points here, Mark. optional newer versions of major, fast-moving and important platform components. For example, during the life of 12.04 LTS we are providing as optional updates newer versions of OpenStack, so it is always possible to deploy 12.04 LTS with the latest OpenStack in a supported configuration, and upgrade to newer versions of OpenStack in existing clouds without upgrading from 12.04 LTS itself. People have generally suggested that using PPAs for this is the right path forward. However, this is not how it's done with the updated OpenStack packages. I would love to hear from the server team about the rationale for this and whether -- after having used the process for around a year now, IIRC -- they find that the benefits outweigh the cost of divergence. That should give us better grounds for working out if 1) using PPAs really is perfectly sufficient or 2) if we should look into improving PPAs to make it so or perhaps 3) make the system used for the OpenStack packages available to maintainers of other software stacks. 2. Reducing the amount of release management, and duration of support, for interim releases. Very few end users depend on 18 months support for interim releases. The proposal is to reduce the support for interim releases to 7 months, thereby providing constant support for those who stay on the latest interim release, or any supported LTS releases. Like most everyone else, I feel that 7 months is a bit on the aggressive side and that 8 months would be more appropriate. I'd be perfectly happy with that, too. Our working assumption is that the latest interim release is used by folks who will be involved, even if tangentially, in the making of Ubuntu, and LTS releases will be used by those who purely consume it. Do we have any data to support this or is it a gut feeling? 3. Designating the tip of development as a Rolling Release. Building on current Daily Quality practices, to make the tip of the development release generally useful as a ‘daily driver’ for developers who want to track Ubuntu progress without taking significant risk with their primary laptop. We would ask the TB to evaluate whether it’s worth changing our archive naming and management conventions so that one release, say ‘raring’, stays the tip release so that there is no need to ‘upgrade’ when releases are actually published. We would encourage PPA developers to target the edge release, so that we don’t fragment the ‘extras’ collection across interim releases. The best policy years ago may not be the best policy now (and vice versa), so I'm totally ready to explore this suggestion. I'm having trouble visualising how this would work in practice, though. Specifically, it's not clear to me what the relationship is between the rolling release and the LTS release (for the sake of this argument I'm assuming that the non-LTS releases are no more). Do you see the LTS release a simple snapshot of what's in the rolling release? If not, how will they be split? -- Soren Hansen | http://linux2go.dk/ Senior Software Engineer | http://www.cisco.com/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: SRU Minor Release Exception for Ceph
2013/2/27 James Page james.p...@ubuntu.com: If not, have you given any thought to how you'll handle the situation where our release cycle doesn't line up well with upstream's LTS releases? If this does happen we would just stick with the most recent LTS release available. Ok, works for me. Ubuntu Ceph Testing - --- In addition, we are currently setting up regular testing of Ceph 'standalone' in multi-node configurations to support more in-depth testing of ceph itself. This will include basic smoke testing of key components to start with and may expand to include executing upstream regression tests on the packages we publish/propose for inclusion in the Ubuntu archive. I think this is a must-have. If upstream already has a good test suite, we should as far as possible be using that in our testing as well. Agreed - I will work on this. Would basic smoke testing be sufficient for a provisional MRE? If doing the whole thing would cause a significant delay, then yes, basic smoke testing is ok, as long as there's a genuine effort afterwards to get the full test suite added. -- Soren Hansen | http://linux2go.dk/ Senior Software Engineer | http://www.cisco.com/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: SRU Minor Release Exception for Ceph
2013/2/8 James Page james.p...@ubuntu.com: Background - -- Ceph was included in Ubuntu main during the 12.04 release cycle; since then upstream Ceph have started maintaining LTS releases of Ceph; Quantal shipped with the 'argonaut' LTS release and Raring will ship the 'bobtail' LTS release. What does LTS mean for Ceph? How long do they expect to support it for? Are the bobtail and argonaut releases indicative of the frequency of LTS releases? In other words, can we reasoably expect to have a fresh LTS in each Ubuntu release? If not, have you given any thought to how you'll handle the situation where our release cycle doesn't line up well with upstream's LTS releases? Ubuntu Ceph Testing - --- [...] In addition, we are currently setting up regular testing of Ceph 'standalone' in multi-node configurations to support more in-depth testing of ceph itself. This will include basic smoke testing of key components to start with and may expand to include executing upstream regression tests on the packages we publish/propose for inclusion in the Ubuntu archive. I think this is a must-have. If upstream already has a good test suite, we should as far as possible be using that in our testing as well. -- Soren Hansen | http://linux2go.dk/ Senior Software Engineer | http://www.cisco.com/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Fwd: Apologies
Best regards, Soren. Sent from my phone. Please pardon my brevity. -- Forwarded message -- From: Soren Hansen so...@linux2go.dk Date: Feb 4, 2013 9:48 PM Subject: Apologies To: Technical Board technical-board@lists.ubuntu.com Cc: Hi, guys. I've contracted some variant of FOSDEM flu, so I'm going to skip the meeting today and try to get some rest instead. Sorry about the short notice. Best regards, Soren. Sent from my phone. Please pardon my brevity. -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies
Hi, guys. I've contracted some variant of FOSDEM flu, so I'm going to skip the meeting today and try to get some rest instead. Sorry about the short notice. Best regards, Soren. Sent from my phone. Please pardon my brevity. -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Meeting reminder - Technical Board meeting 2013-01-21 2100 UTC
Just a friendly reminder that we have our regular scheduled Technical Board meeting tomorrow evening at 2100 UTC. The agenda so far: * Action review * SRU MAAS and its dependencies - AndresRodriguez (roaksoax) * Scan the mailing list archive for anything we missed (standing item) * Check up on community bugs (standing item) * Select a chair for the next meeting See you then! -- Soren Hansen Ubuntu Developerhttp://www.ubuntu.com/ OpenStack Developer http://www.openstack.org/ -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Mythbuntu LTS plan
2012/5/9 Mario Limonciello supe...@ubuntu.com: What does the tech board think of this proposal? I have nothing further to add other than it sounds like an interesting experiment, so a +1 from me. -- Soren Hansen | http://linux2go.dk/ Senior Software Engineer | http://www.cisco.com/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Meeting time set at 2100 UTC every other Monday
Just to fill everyone in: At the last meeting, we decided to keep the current meeting time as defined in UTC. Specifically, the meeting will stay at 2100 UTC and will be held every other Monday (i.e. nothing has changed). Sorry for not pointing this out sooner. -- Soren Hansen Ubuntu Developer http://www.ubuntu.com/ OpenStack Developer http://www.openstack.org/ -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Harmonizing DMB membership expiring dates
2012/1/20 Martin Pitt martin.p...@ubuntu.com: Benjamin Drung [2012-01-09 20:40 +0100]: What do you think? Are we allowed to adjust the membership expiration dates? While it technically does not match the letter of what people voted on, I can't imagine anyone seriously complaining. Let's not be overly bureaucratic here, IMHO :-) Let's see what the other TB members think. Yeah, this doesn't even give me a reading at all on my controversial-o-meter :) Fine with me. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Build-in DNS cache support
It's true that there is no built-in DNS cache support as we don't have a name resolution *service*, but simply a name resolution library (in libc). Is far as I'm aware, though, Firefox and Chromium both have built-in DNS caches, so most (if not all) interactive Internet usage already benefits from a DNS cache. That is not to say that a DNS cache wouldn't be handy, though. I just don't think it's a great concern for the general user experience. 2011/12/3 Mark Shuttleworth m...@canonical.com Any merit to this suggestion? Original Message Subject: Build-in DNS cache support Date: Sat, 03 Dec 2011 06:51:24 - From: xiangxw 963632...@qq.com Reply-To: xiangxw 963632...@qq.com To: Mark Shuttleworth m...@canonical.com As far as I know, Ubuntu does not have build-in DNS cache support, while Windows does. Beginners with static IP network sometimes will suffer from it, for Internet surfing will be very slow without DNS cache. This can be solved by install a DNS cache software such as dnsmaq, but I think this should be done before user get Ubuntu. Ubuntu should think more about common users. Think about it, a businessman use Ubuntu for the first time, but Internet is so slow in Ubuntu, he may quit right away and try Windows or Mac. Sorry for my English. -- This message was sent from Launchpad by xiangxw (https://launchpad.net/~963632192-m) using the Contact this team's owner link on the Ubuntu Desktop team page (https://launchpad.net/~ubuntu-desktop). For more information see https://help.launchpad.net/YourAccount/ContactingPeople -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board -- Soren Hansen Ubuntu Developer http://www.ubuntu.com/ OpenStack Developer http://www.openstack.org/ -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Unable to make the meeting today
Sounds good to me. Regards, Soren. Sent from my phone. Please pardon my brevity. -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Unable to make the meeting today
Hi, guys. As I mentioned a while ago, the current meeting time does not work for me, so I'm going to have to pass on our meeting today. I hope we'll decide on a better meeting time today. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
