FreeBSD has serious problems with focus, longevity, and lifecycle

vermaden vermaden at interia.pl
Tue Jan 24 11:24:25 UTC 2012


"Mark Linimon" <linimon at lonesome.com> pisze:
> On Thu, Jan 19, 2012 at 08:07:43AM +0100, vermaden wrote:
> > I submit PRs and try to help test them as some developer/committer
> > will pick up the PR, submit a patch to test, but it was MANY times
> > that the response from developer/committer was way too long that
> > I even DID NOT HAVE THE HARDWARE anymore ...
> 
> I don't have a magic wand to solve this problem.  I've spent a lot
> of time thinking about it and it's just a hard problem to solve in
> general.  There are several aspects:
> 
>  - so many computers are very broken (specifically, horrible BIOS
>    bugs).
> 
>  - most committers only have one or two computers that they work with.
> 
>  - most committers have their own tasklist, and "support users" is
>    something they never have time to get around to.
> 
> "support users" is, in general, something Open Source OSes do not
> do very well (at least without a paid support staff, as is the case
> in some of the Linux distros.)
> 
> But what's discouraging for the people that try to clean up the stale
> PRs is that they get yelled at when they try to do so.  Thus, they
> tend to get demotivated as well.
> 
> Support/bug triage is hard and unrewarding work.  People can tend to
> feel that they're being blamed for bugs that they had nothing to do
> with creating, and burn out.


Hi,

I do not have anything against You, or any other commiter/developer,
maybe the answer to that PR should be 'I have checked that and that,
but I do not have that hardware so no luck ...'

It would be also great to have FreeBSD base system tool, that would
collect all system data, dmesg, uname, hardware configuration,
literally EVERYTHING, that would provide some useful input for a
commiter/developer.

It would also be good to have some wiki.freebsd.org page that
would describe what information is needed to fill a good PR
if such tool is not going to 'happen', I could write a simple SH
script myself, that would collect dmesg/dmidecode/uname
and more output from other commands, but I do not know
what knowledge You need, so that simple program to get all
that useful data can help a little, at least in theory.


> > Here is one of the messages that I sent by then to the mailing lists:
> > http://lists.freebsd.org/pipermail/freebsd-doc/2007-May/012507.html
> > 
> > ... and NOTHING HAPPENED, no one told me what to do next,
> > should I sent a SGML version or anything ... or just GTFO.
> 
> I'm sorry that nothing happened, but unfortunately that's common.
> Submitters sometimes have to be persistent, and maybe even catch
> new committers when they sign up.  Our documentation is certainly
> in need of updating.


I still was (or at least felt) that was a FreeBSD newbie that time,
so I did not knew if my 'handbook part' was just rubbish, or stupid,
or ... whatever, no one responded, so I assumed that its not
needed/useless and moved along.

It would be also good to have a wiki.freebsd.org page describing
what is needed and in what format a user should send the
documentation changes, currently its just wasting developers'
time for asking them how to do that and that, what format,
where to send it ...


> > What I have done about these 'Ports issues'? I contacted these
> > ports maintainers and said that both RC script and AIO support for
> > samba should be enabled by default by linking to several threads
> > at FreeBSD Forums that the problem is known and exists ... and I
> > did not get ANY RESPONSE till this very day, not even a GTFO
> > (which would probably be better then nothing).
> 
> When you don't get a response from a maintainer, your best bet is to
> file a PR against the port.  If the maintainer doesn't respond, then
> after 2 weeks any FreeBSD ports committer is free to work on the PR
> and, if they agree with you, commit it via maintainer-timeout.
> 
> We don't have a way to track emails that various users send to individual
> maintainers.  With a PR open, we have a way to do that.  We also track
> maintainer-timeouts, and these can eventually lead to a maintainer reset.


I have now filled these PR's here:

http://www.freebsd.org/cgi/query-pr.cgi?pr=164431
http://www.freebsd.org/cgi/query-pr.cgi?pr=164432


> > It's not that people does not try to help, a lot tried (and I am still
> > trying), but its VERY unpleasant to have awareness, that you dedicated
> > your time, tried to help as much as possible, made some steps to achieve
> > that ... and no one even cares about that.
> 
> I think it's not "don't care", I think it's that "unable to cope with
> number of incoming PRs and other requests for changes and support".
> As I type this, there are 1122 ports PRs (6272 total PRs).  On most
> days, around 40 come in.  It would take a few dozen more volunteers
> to be able to keep up with them all.
> 
> mcl


So its time for another article/page on wiki.freebsd.org, how to become
a commiter and help to solve PRs', how to add your mirror to FreeBSD
project, etc, etc ...

Regards and have a nice day,
vermaden








































...


More information about the freebsd-hackers mailing list