Mailinglist Archive: opensuse (1495 mails)

[Jim Henderson <hendersj@xxxxxxxxx>]

On Wed, 01 Apr 2009 20:30:44 +0200, Carlos E. R. wrote:

> > >    I'd like this post to go to the project list, where the right
> > >    audience is, but I leave that to you.
> >
> > Feel free to send along to whomever you feel is appropriate - I'm not
> > subscribed to the project list myself; as a new user (I see it is on
> > gmane and am adding it to my list now), I wouldn't want to seem
> > presumptuous on that list to come in and start off with this message.
> > :-)
>
> Ah, then, we'll leave it for some other time :-)

PGNet has offered to do so, with my permission.

I just don't like to make a huge splash as my first post in a community 
I'm not established at all in.  I like to get a feel for it first.

> The community is big, but surely, bugs have to be handled by the
> maintainer, or somebody with that kind of knowledge. I can't, for
> instance. I can report bugs, do complicated tests, perhaps some scripts,
> but that's about all. Ah, yes, I do part of the translation to Spanish.
> I can't "repair" bugs.

Patches for the bugs and testing doesn't necessarily have to be handled 
by the maintainer.  The maintainer has to just accept the patch and 
coordinate testing.

I don't know if this is how it's done, but it seems to me that the 
maintainer is kinda like a product/project manager.  For smaller packages/
distros this function could be rolled into a single person who does the 
coding/testing/patching, but for larger package groups, distros, etc, it 
seems that the build-test-fix cycle could be handled by anyone who the 
maintainer trusts to do the job correctly.

Otherwise you fall back into a monolithic design process, which isn't 
very nimble.  For some projects that lack of agility is fine, but for a 
large distro like openSUSE, I would think the ability to react quickly 
would be desirable.

Not saying that the team doesn't react quickly - I don't want the team to 
think I'm knocking them.  That's not my intention.  They've put out an 
excellent distro, as I said before.  But there's no system of processes 
that cannot be improved upon.

> at fault, beagle simply used a function that was there, but faulty,
> unknown to all. In the great scheme of things, it was a good thing that
> beagle provoked the fault so that it could be cleared.
>
> Meaning, it could have happened with some other program.

Interesting, thanks for that tidbit.

> > Weird, I have an external USB drive on my x86_64 system that is
> > reiserfs and seems to work OK.  I even export it over NFS.  Is there a
> > bug that I should be looking at that talks about this issue?
>
> Maybe only 32bit systems are affected, or there is something special in
> my hardware. No idea. It is bug 460020, if you are curious.

Thanks, I'll have a look, if only just to see if my data might be 
affected.  I'll also, if appropriate, tack a note on to say whether or 
not I'm affected on the 64-bit system, in the event that helps narrow the 
problem down.

Though now I think of it, I have a 32-bit laptop in the office that I 
also use external USB on and I don't see any corruption, but I use that 
drive mostly so I have a local copy of some data when I'm working from 
home, so it gets written more than read by a longshot.

> > I understand your frustration - as you probably guessed.  At the same
> > time, though, these particular issues would seem to affect even
> > potentially a small group of users.  Things like zypper creating huge
> > log files potentially affect everyone - or boost breaking encfs (encfs
> > has some popularity from what I've seen).
>
> True. But it seems that users of 11.0 are not usually affected by this
> huge log issue :-?
>
> The encfs trouble I haven't seen myself, I don't use it.

It was very easy to reproduce.  Use encfs to create an encrypted 
filesystem.  fusermount -u it.  Try to remount it.  No go.

> > I understand the need to prioritise the issues and work on the most
> > serious ones, and fully support that of course....
>
> That's right.
>
> But what preoccupies me, is that things that should be rock solid, as
> the filesystem, are not so solid. I found some "holes", there are
> probably more, lurking there. That scares me a lot: just imagine we bump
> into something that destroys data in big chunks, the nightmare!

I've seen that happen with commercial software as well.  There was a 
patch for a version of NetWare (my server OS background) that in some 
circumstances would lead to volume corruption.  Wasn't caught in testing, 
and required very specific hardware and even firmware revisions to 
duplicate (hence why it wasn't caught in system test).  Data loss is 
almost always a nasty proposition.

> My troubles might then be just the tip of the iceberg.

Could be.

> Maybe some effort should be given to do a... full review? of the entire
> filesystem code, specially the lest used ones. Sharks could be lurking
> there. I guess that a lot of patches are going on bits over here or
> there, and that the code is becoming "unclean". It is a feeling, I don't
> know how to explain it. I hope to be wrong.

Maybe, but that would be something for the kernel team to decide on, I 
think.

> > > Effort seem to concentrate on highly visible features, like kde4.
> >
> > ...but things like KDE4 (which, like it or not, for 11.0 was something
> > of a disaster from a PR standpoint at the very least) do distract from
> > things that affect all users.  KDE4 issues don't affect me because I'm
> > a GNOME user.  Core issues in KDE4, though, are best addressed IMHO by
> > the KDE team and not the openSUSE team.  The encfs/boost issue is a
> > packaging/ build issue for the distro.  KDE4's usability problems
> > aren't, so I'd consider that a different class of issue to be addressed
> > by a different group of people.
>
> Correct.

:-)

Jim
-- 
 Jim Henderson
 Please keep on-topic replies on the list so everyone benefits

-- 
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx