openSUSE Project June 2012

project@lists.opensuse.org

58 participants
35 discussions

[opensuse-project] Thoughts on the UEFI fee?

by C

Swapnil has written an interesting blog post about the whole RedHat and UEFI thing that has been floating in the last day or so... http://www.muktware.com/3699/secure-boot-uefi-fedora-red-hat-99-ubuntu-micr… What are we as openSUSE going to do here? Do we pony up the $99 for the key registration fee? (my vote would be yes) Do we ignore it? Has anyone thought about this yet? C. -- openSUSE 12.1 x86_64, KDE 4.8.3 -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

8 years, 6 months

[opensuse-project] The languished meaning of "maintainer" (was: Calling for a new openSUSE development model)

by Jan Engelhardt

Robert Schweikert wrote in http://lists.opensuse.org/opensuse-factory/2012-06/msg00489.html : > >I believe that an underlying issue to the overall state is the package >maintenance model. Look at any perl or python package in the devel >projects and you'll find tons of people listed as "maintainers" but >almost non of them is a "true" maintainer. Everyone of the listed >"maintainers" is inherited from some parent project and in the end no >one really feels responsible. Indeed - but: it is the way it is represented in the webui that is misleading. If you use the command line client, `osc meta pkg`, you get a *much* more useful and concise set of people - and usually the people who *really are* responsible. If the so-obtained list is empty, you can consider the package abandoned already. >That this is an issue is also evident in the increased mail traffic on >the list about lingering SRs. The problem with lingering SRs has more to do with the "maintainer"-called role being overloaded - *in prj context*. I concur with your observation. 22 "maintainers" in games, 42 in devel:libraries:c_c++ don't paint a good picture. But server:irc's list of 8 also sports the linger problem. There are a handful of prj-level actions: - the true maintainer, IOW, "I maintain indeed all packages in here". This only makes sense for a limited set of develprjs, predominantly those that deal with a single "software stack" (a group of obviously related packages). Examples are network:mail:zarafa, network:telephony:asterisk*. But not games, not d:l:c_c++. - fallback maintainer: responsibility to accept lingering SRs not having been accepted by the bspkg maintainer in a handful of days (3/5/7? maybe settable within the pkgmeta?), provided they meet best judgment. - mentor: responsibility to 1. decline *new* packages - sorting out unsuitable license, ...; 2. approve new packages and perhaps send corrections immediately afterwards, ...; These extra roles are merely for self-description of users, and should simply have the same commit permissions as the current "maintainer" role do now. -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

8 years, 6 months

[opensuse-project] COSCUP

by Jos Poortvliet

Heya all, You might know we've got COSCUP coming - and the CfP is officially closed but we can surely still use a few more proposals to have something to choose from. So if you want to talk about openSUSE at COSCUP in Taiwan, submit a proposal! http://news.opensuse.org/?p=13126 Send proposals to cfp(a)opensuse.org please. I also want to mention that you can ask the openSUSE Travel Committee for financial support for going there - it's why we have a OTC! Especially speakers are very likely to receive travel sponsorship. See http://en.opensuse.org/openSUSE:Travel_Support_Program /Jos

8 years, 6 months

[opensuse-project] Improving the bug management lifecycle/process

by Jim Henderson

OK, so this is something I'd like to start trying to get my arms around so we can have a more comprehensive approach to dealing with bug reports and increase the rate of resolution as well as the follow-up rate when additional information is needed. It seems that we have a few areas that we should be looking at: 1. There should be some sort of "screening" that takes place before a bug is accepted - to ensure that the devs aren't seeing multiple copies of the same bugs. I think it's fair to say that those who write code would far rather *write code* than try to sort through duplicate bug entries. While it's likely there still would be dupes with a screening process, the incidence should be reduced. 2. There needs to be more of a "human" reply, especially on older bugs, that are being addressed. Looking at the current Bugzilla stats, I see that (for example) 12.1 has 183 bugs in a "NEEDINFO" state - there needs to be some sort of consistent follow-up to ensure that the info needed to fix the issues is provided, and if it isn't and the information can't be obtained (because the issue cannot be duped, those looking at it don't have the necessary hardware, etc), then the bug needs to be closed. 3. For older bugs, (such as on 10.3-11.3, which there are still open bugs on), a determination needs to be made as to whether the current supported releases have those issues, and if they do, the bugs need to be updated. If they don't, then the bugs need to be flagged in an appropriate way. 4. It would be extremely useful, I think - especially for the non-techie audience - to put some specific training together on things like (a) how to submit a bug and include the relevant information, (b) what to expect with your bug and how to monitor progress, (c) how to provide additional information when requested (and what to do if you've upgraded/moved to another version/changed distributions/decided to go back to Windows/MacOS/ whatever) so the bug can continue to be evaluated by those evaluating it. Ultimately, the goal of this project is to increase resolution rates, reduce the time to resolution as much as possible, and to visibly improve the bug resolution process so more people don't perceive (correct or not) that reporting bugs is useless because they don't get resolved (and actually, looking at the stats on bug status, I think it's pretty unfair to say bugs aren't getting resolved. I see, for example, that of the reported bugs on 11.1, for example, over 3/4 of the bugs are marked as resolved.) And overall across all releases of openSUSE, and SUSE Linux Professional/ SUSE Linux from 8.2 on, the bugs marked resolved are 13026/18285, which is nearly 3/4. 75% isn't bad (the Pareto rule is 80/20, and on 11.1 we're actually around 78% "resolved"), but I'm sure that if we can guide the process and streamline it, we can increase that. Of course those are just rough statistics and the reason bugs are marked as 'resolved' isn't included in that - and there is a further breakdown that can be done that might help identify trends that would be useful. There's clearly more that we should be looking at, but these four areas are a good place to start. For my own part, I'm willing to do more than talk and discuss the ideas, but it's going to take more than just one person working in his spare time to move this along. I also think something similar to this should be done for FATE, but that's perhaps a topic for another day. :) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

8 years, 6 months

[opensuse-project] [gsoc] osc2 client - summary of week 3 and 4

by Marcus Hüwe

Hi, here's a small summary of the 3rd and 4th (coding) week . First of all I wasn't able to do lots of work in week 3 and 4 so I'm still working on the new build module for the osc2 library. The initial plan was to copy/reuse some of the existing modules from the (old) "osc" like the cpio [1] and packagequery modules. But I decided to refactor/rewrite cpio module for the following reasons: - "save" disc space: In our scenario we retrieve a cpio archive from the api (which contains binary packages for example). The old cpio module expects a filename in order to "unpack" the archive - that is the file has to be stored on disc first. Consequently approximately 2 * <archive size> of free disc space is needed. The new idea is that we pass a file-like object (in our case an object which inherits from "AbstractHTTPResponse") to the cpio module and unpack the archive "on the fly" (without storing the http response on disc first). - have testcases: The old cpio module has no testcases (because some time ago I didn't follow the TDD approach;) ). For nearly all modules in osc2 there exist testcases (white-box tests) thus it would be nice if we have some testcases for the cpio module, too (theoretically we could add some black-box tests (the current methods aren't really testable thus white-box tests aren't possible)). - have a nice pythonic interface: The new interface will look like this: from cpio import cpio_open # let "f" be a file-like object (for instance a http response) with cpio_open(fobj=f) as cpio_archive: for a_file in cpio_archive: # store file (with correct permissions etc.) in os.curdir a_file.write(os.curdir) # alternatively it's also possible to read some data (instead of # writing it to disc) via a_file.read(len) We will also support a plain filename in cpio_open. Currently the cpio module will only support the "new ascii" (ascii SVR4 no CRC) format and regular files (that's sufficient for our needs). But it will be possible to simply pass in a class for a different format (that is no code has to be altered in order to support a new format). Finally this will be finished by the end of this week. If you have any questions or suggestions please tell me:) Marcus [1] https://github.com/openSUSE/osc/blob/master/osc/util/cpio.py -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

8 years, 7 months

[opensuse-project] 12.3 timing?

by Greg Freemyer

Coolo (or other), If 12.2 does slip by a couple months, what happens to the timing for 12.3? Does is stay where it was, or slip to 8 months after the 12.2 release? fyi: I'm more curious than pushing for one answer or the other. It just seems that how you handle the freeze will impact how the above works out. Thanks Greg -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

8 years, 7 months

[opensuse-project] fdisk project - GSoC weekly report 4

by Davidlohr Bueso

Hi, So, what's been done this week: - Sent out a patchset that adds MBR buffer support to the API - Sent out a patchset that adds device geometry support to the API. This also maintains the legacy CHS addressing for flexibility/compatibility, yet the fdisk program will only use LBA as of next year. - General cleanups Thanks, Davidlohr -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

8 years, 7 months

[opensuse-project] Deployments in North/Central America

by Bryen M Yunashko

Hi folks, For the upcoming openSUSE Summit in September (see http://summit.opensuse.org), we are considering setting up a panel with guest speakers from companies/organizations that have deployed openSUSE in their environments. We have a small list of organizations that we know of in the U.S. It would be nice to get a larger list to determine who to ping to invite. If you know of deployments, please feel free to contact me so I can add it to the list and determine if an invitation is warranted. Thanks! Bryen M Yunashko openSUSE Project -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

8 years, 7 months

[opensuse-project] Announce: Delaying 12.2

by Stephan Kulow

Hi, Those of you who read opensuse-factory mailing list too, will already be aware, but for those who aren't, I would like to make it more official: We won't be able to release 12.2 in time. We didn't catch up with the slip of the milestones and beta, so I can't release RC1 now - and delaying RC1 means delay of 12.2 too. As I don't want to move 12.2 release into august due to vacation time, my thinking about rescheduling is this: - next week I will release what I have as 12.2-Beta2 - after that we will split away openSUSE:12.2 from factory to put it under deep freeze for pure bug fixes. - Mid of July we can have RC1 - August will see more updates, but no real action - Release mid of September Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

8 years, 7 months

[opensuse-project] Re: [opensuse-factory] openSUSE 12.2 deserving of attention?

by Jos Poortvliet

On Tuesday 12 June 2012 18:20:24 Genix Info wrote: > IPv6 and DNS: > > http://lists.opensuse.org/opensuse/2012-06/msg00010.html > > I understand. But you said that there needed to be developed to help, I > thought my suggestions of features and bugs would be forwarded to the > developers. This IS the developer list and feature requests go to openFate - fate.opensuse.org or in case of bugs, bugzilla. In any case, sorry if I was unclear. I was looking for input from the developers on what has changed in the release, not asking from users what they would like to see as we're way too close to release to be able to do any of that. ;-)

8 years, 7 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openSUSE Project June 2012