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
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
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
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
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
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
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
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
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
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.
;-)