headers
John Kozubik | 16 Jan 2012 23:28

FreeBSD has serious problems with focus, longevity, and lifecycle


Friends,

I was disappointed to see that 8.3-RELEASE is now slated to come out in 
March of 2012.  This will be ~13 months since 8.2-RELEASE and is typical 
of a trend towards longer gaps between minor releases.

I also see that undercutting the current release before wide deployment 
and maturity is continuing.  7.0 came (barely) after 6.3, which was bad 
enough, but not as bad as 8.0 arriving with 7.2, and now 9.0 with 8.2.

Finally, the culture of "that's fixed in CURRENT" or "we built those 
changes into (insert next major release)" continues to get worse.  It's 
difficult to escape the notion that FreeBSD is becoming an operating 
system by, and for, FreeBSD developers.

The Problems:

Between JohnCompanies and rsync.net, we have nearly one thousand full 
blown FreeBSD systems running on three continents.  We've been deploying 
these systems since 2001 and since "the rift"[1] have been increasingly 
subject to the following major issues, listed from most general to most 
specific:

1) A widening gap of understanding between the developers and the end 
users.  Not everyone has a fantastic tool chain and build environment that 
allows them to jump around from one snapshot to the next, cost free. 
We've got a thousand of these things, and not only are we going to run 
RELEASE software ONLY, but we're going to do everything we can to match 
that environment up across as large of an installed base as possible.
(Continue reading)

Permalink | Reply |
headers
William Bentley | 17 Jan 2012 00:32

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

I also echo John's sentiments here. Very excellent points made here.
Thank you for voicing your opinion. I was beginning to think I was the
only one who felt this way.

I also have several FreeBSD installations spread across different
development/production systems and it is not feasible to always upgrade
to the latest and greatest. Part of why FreeBSD is difficult to adopt
into more of the commercial/government sectors is because of this fast
paced release cycle and most of the important patches/fixes are not
backported far enough. This is why most of my customers decide to use
Solaris or RedHat and not FreeBSD. (Not looking to start a flame war
about the OS choice/etc just pointing out the Release cycle model). I
would love to push FreeBSD harder but it is becoming increasingly
difficult as of late.

We seem to have lost our way around the release of FreeBSD 7. I am all
in favor of new features but not at the risk of stability and proper
life cycle management.

Are me and John the only people that feel this way or are we among the
minority?

-Will

On Mon, 2012-01-16 at 14:28 -0800, John Kozubik wrote:
> Friends,
> 
> I was disappointed to see that 8.3-RELEASE is now slated to come out in 
> March of 2012.  This will be ~13 months since 8.2-RELEASE and is typical 
> of a trend towards longer gaps between minor releases.
(Continue reading)

Permalink | Reply |
headers
Julian Elischer | 17 Jan 2012 01:02
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 1/16/12 3:32 PM, William Bentley wrote:
> I also echo John's sentiments here. Very excellent points made here.
> Thank you for voicing your opinion. I was beginning to think I was the
> only one who felt this way.
[...]

> We seem to have lost our way around the release of FreeBSD 7. I am all
> in favor of new features but not at the risk of stability and proper
> life cycle management.
>
> Are me and John the only people that feel this way or are we among the
> minority?
>
>
> -Will
>
>
It pretty much boils down to one thing..  man power..

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
John Kozubik | 17 Jan 2012 01:13

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


Julian,

On Mon, 16 Jan 2012, Julian Elischer wrote:

> It pretty much boils down to one thing..  man power..

Wouldn't there be more manpower available for more frequent minor releases 
if the project were not undertaking two simultaneous "production" 
releases ?  Specifically, wouldn't it have been feasible to be at 8.4 
right now if much of 2011 had not been spent breaking ground on 9.0 ?

Further, isn't the lack of focus, or "polish" of the current release also 
impacted by these decisions ?

Of course there is a limited amount of manpower, but for the points I 
raised that was a symptom, not a cause...
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
richo | 17 Jan 2012 02:02
Favicon
Gravatar

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 16/01/12 16:13 -0800, John Kozubik wrote:
>
>Julian,
>
>On Mon, 16 Jan 2012, Julian Elischer wrote:
>
>>It pretty much boils down to one thing..  man power..
>
>
>Wouldn't there be more manpower available for more frequent minor
>releases if the project were not undertaking two simultaneous
>"production" releases ?  Specifically, wouldn't it have been feasible
>to be at 8.4 right now if much of 2011 had not been spent breaking
>ground on 9.0 ?
>
>Further, isn't the lack of focus, or "polish" of the current release
>also impacted by these decisions ?
>
>Of course there is a limited amount of manpower, but for the points I
>raised that was a symptom, not a cause...

This would be a different argument if all the devs were paid a salary.

In many instances the devs in question wouldn't have the motivation to work
on the maintenence release, in others the work is sponsored but is moving in
a direction that is fundamentally incompatible with the 8.x release.

I'm not trying to refute your input, just offering some insight about how it
may not be strictly accurate.
(Continue reading)

Permalink | Reply |
headers
Igor Mozolevsky | 17 Jan 2012 03:21
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 17 January 2012 01:02, richo <richo <at> psych0tik.net> wrote:

> This would be a different argument if all the devs were paid a salary.

Isn't this a bit of a cyclical argument: developers don't work because
they are not paid a salary, the end-user base shrinks, BigCo doesn't
want to pay for someone to put extra work in getting fBSD to do
something that it can get elsewhere (eg Linux), fewer still developers
work on fBSD, end-user base shrinks, BigCo is even more reluctant,
even fewer....

--
Igor M. :-)
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
richo | 17 Jan 2012 03:25
Favicon
Gravatar

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 17/01/12 02:21 +0000, Igor Mozolevsky wrote:
>On 17 January 2012 01:02, richo <richo <at> psych0tik.net> wrote:
>
>> This would be a different argument if all the devs were paid a salary.
>
>Isn't this a bit of a cyclical argument: developers don't work because
>they are not paid a salary, the end-user base shrinks, BigCo doesn't
>want to pay for someone to put extra work in getting fBSD to do
>something that it can get elsewhere (eg Linux), fewer still developers
>work on fBSD, end-user base shrinks, BigCo is even more reluctant,
>even fewer....

Potentially, but it doesn't invalidate it, imo.

I'm very aware that the code I produce for $WORK is very different to code I
write in my own time. Code for $WORK is wrapped in test cases, clean, neat
and well documented.

code I write in my own time tends to be hackish, incomplete totally
undocumented and ludicrously easy to break because I'm intrigued by
implementing a single interesting figure that has my attention, or to see
whether or not a concept is technically feasible.

This is a shortcoming of mine that I should work to overcome, but I feel that
the same thing would likely extend to other developers, though in most cases
to a lesser degree. Without some other motivation most people naturally
gravitate towards newer "cool" features, rather than doing the relatively
boring maintenence and backporting.

Note though, that recognising this highlights my respect for the people who
(Continue reading)

Permalink | Reply |
headers
Igor Mozolevsky | 17 Jan 2012 03:43
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 17 January 2012 02:25, richo <richo <at> psych0tik.net> wrote:
> On 17/01/12 02:21 +0000, Igor Mozolevsky wrote:
>>
>> On 17 January 2012 01:02, richo <richo <at> psych0tik.net> wrote:
>>
>>> This would be a different argument if all the devs were paid a salary.
>>
>>
>> Isn't this a bit of a cyclical argument: developers don't work because
>> they are not paid a salary, the end-user base shrinks, BigCo doesn't
>> want to pay for someone to put extra work in getting fBSD to do
>> something that it can get elsewhere (eg Linux), fewer still developers
>> work on fBSD, end-user base shrinks, BigCo is even more reluctant,
>> even fewer....
>
>
> Potentially, but it doesn't invalidate it, imo.
>
> I'm very aware that the code I produce for $WORK is very different to code I
> write in my own time. Code for $WORK is wrapped in test cases, clean, neat
> and well documented.
>
> code I write in my own time tends to be hackish, incomplete totally
> undocumented and ludicrously easy to break because I'm intrigued by
> implementing a single interesting figure that has my attention, or to see
> whether or not a concept is technically feasible.
>
> This is a shortcoming of mine that I should work to overcome, but I feel
> that
> the same thing would likely extend to other developers, though in most cases
(Continue reading)

Permalink | Reply |
headers
Mark Linimon | 20 Jan 2012 09:29

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Tue, Jan 17, 2012 at 02:43:21AM +0000, Igor Mozolevsky wrote:
> To be realistic, I think any serious developer should expect to spend
> 70% of their development time on maintenance

s/developer/paid developer/ and you've got a correct model of how commercial
software companies work.

mcl
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Atom Smasher | 17 Jan 2012 07:20
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Tue, 17 Jan 2012, richo wrote:

> I'm very aware that the code I produce for $WORK is very different to 
> code I write in my own time. Code for $WORK is wrapped in test cases, 
> clean, neat and well documented.
>
> code I write in my own time tends to be hackish, incomplete totally 
> undocumented and ludicrously easy to break because I'm intrigued by 
> implementing a single interesting figure that has my attention, or to 
> see whether or not a concept is technically feasible.
====================

code i write for work is (typically) under pressure of time and money. 
sometimes good documentation is more important than good code, sometimes 
documentation is irrelevant. at work i've been complimented for getting 
things done on time and under budget, but NEVER for getting it done right.

code i write in my own time is art. i wouldn't write a sloppy song in my 
spare time, and i don't write sloppy code in my spare time.

--

-- 
         ...atom

  ________________________
  http://atom.smasher.org/
  762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
  -------------------------------------------------

 	A student asked his old Sufi Master if he should tie up
 	his camel for the night, so that it wouldn't wander
(Continue reading)

Permalink | Reply |
headers
Adrian Chadd | 17 Jan 2012 23:55
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 16 January 2012 18:21, Igor Mozolevsky <igor <at> hybrid-lab.co.uk> wrote:
> On 17 January 2012 01:02, richo <richo <at> psych0tik.net> wrote:
>
>> This would be a different argument if all the devs were paid a salary.
>
> Isn't this a bit of a cyclical argument: developers don't work because
> they are not paid a salary, the end-user base shrinks, BigCo doesn't
> want to pay for someone to put extra work in getting fBSD to do
> something that it can get elsewhere (eg Linux), fewer still developers
> work on fBSD, end-user base shrinks, BigCo is even more reluctant,
> even fewer....

Right, so some people need to stand up and actually push their agenda
forward by agreeing to take on (and then completing) contributions
towards the project that furthers their goals.

OP - if you'd like to see FreeBSD's stable release schedule pushed
forward a bit quicker then please, step up and offer to assist. No-one
is going to say no. Everyone will appreciate the extra help.

Adrian
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Atom Smasher | 17 Jan 2012 07:32
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Tue, 17 Jan 2012, richo wrote:

> This would be a different argument if all the devs were paid a salary.
==============

what percentage of linux devs are on salary to develop linux?

--

-- 
         ...atom

  ________________________
  http://atom.smasher.org/
  762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
  -------------------------------------------------

 	"Patriotism is the willingness to kill
 	 and be killed for trivial reasons."
 		-- Bertrand Russell

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Ivan Voras | 17 Jan 2012 14:44
Picon
Favicon
Gravatar

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 17/01/2012 07:32, Atom Smasher wrote:
> On Tue, 17 Jan 2012, richo wrote:
>
>> This would be a different argument if all the devs were paid a salary.
> ==============
>
> what percentage of linux devs are on salary to develop linux?

Apparently, 3/4: http://apcmag.com/linux-now-75-corporate.htm

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Igor Mozolevsky | 17 Jan 2012 14:49
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 17 January 2012 13:44, Ivan Voras <ivoras <at> freebsd.org> wrote:
> On 17/01/2012 07:32, Atom Smasher wrote:
>>
>> On Tue, 17 Jan 2012, richo wrote:
>>
>>> This would be a different argument if all the devs were paid a salary.
>>
>> ==============
>>
>> what percentage of linux devs are on salary to develop linux?
>
> Apparently, 3/4: http://apcmag.com/linux-now-75-corporate.htm

Actually, you're misrepresenting the facts: according to the headline,
75% of the code came from paid developers, *not* 75% of developers are
paid... See the difference?..

--
Igor M.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Chris Rees | 17 Jan 2012 17:05
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 17 Jan 2012 13:38, "Atom Smasher" <atom <at> smasher.org> wrote:
>
> On Tue, 17 Jan 2012, richo wrote:
>
>> This would be a different argument if all the devs were paid a salary.
>
> ==============
>
> what percentage of linux devs are on salary to develop linux?
>

You're not comparing like with like.

Linux is not an OS; FreeBSD is.

Are you talking about Linux? Debian? Red Hat?

Chris
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Atom Smasher | 17 Jan 2012 21:30
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Tue, 17 Jan 2012, Chris Rees wrote:

> > what percentage of linux devs are on salary to develop linux?
> >
> 
> You're not comparing like with like.
> 
> Linux is not an OS; FreeBSD is.
> 
> Are you talking about Linux? Debian? Red Hat?
================

linux is, in fact, an operating system.

debian, red hat, ubuntu, gentoo, etc are distributions of that OS.

--

-- 
         ...atom

  ________________________
  http://atom.smasher.org/
  762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
  -------------------------------------------------

 	"Facts change from time to time."
 		-- Donald Rumsfeld

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
(Continue reading)

Permalink | Reply |
headers
Mark Felder | 17 Jan 2012 21:32
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Tue, 17 Jan 2012 14:30:20 -0600, Atom Smasher <atom <at> smasher.org> wrote:

> linux is, in fact, an operating system.
>  debian, red hat, ubuntu, gentoo, etc are distributions of that OS.

It's not really worth getting into this argument, but I'll reiterate that  
no, it's not an OS -- it's a kernel. Without the userland utilities the  
distros provide it's not very usable. Linus and co don't maintain the  
shell or the rc subsystem or anything like that. They only work on the  
kernel and in-tree drivers. We need to be comparing FreeBSD to a full  
blown distro.

Cheers
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Atom Smasher | 17 Jan 2012 22:03
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Tue, 17 Jan 2012, Mark Felder wrote:

>> linux is, in fact, an operating system. debian, red hat, ubuntu, 
>> gentoo, etc are distributions of that OS.
>
> It's not really worth getting into this argument, but I'll reiterate 
> that no, it's not an OS -- it's a kernel. Without the userland utilities 
> the distros provide it's not very usable. Linus and co don't maintain 
> the shell or the rc subsystem or anything like that. They only work on 
> the kernel and in-tree drivers. We need to be comparing FreeBSD to a 
> full blown distro.
================

if it makes you feel better, then pick a distribution of linux, and 
compare it's successes and/or failings to freeBSD.

whether or not linux is an OS or "just a kernel" is irrelevant here, but 
at the same time an interesting distinction (and let's not debate it here, 
just acknowledge that it's been pointed out) since freeBSD is both a 
kernel and a collection of core utilities. in some ways freeBSD is like 
the linux kernel, in other ways it's more like a distribution of linux. 
would freeBSD benefit from breaking up those things into explicitly 
different projects? like linux & GNU?

--

-- 
         ...atom

  ________________________
  http://atom.smasher.org/
  762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
(Continue reading)

Permalink | Reply |
headers
Chris Rees | 17 Jan 2012 22:10
Picon
Favicon
Gravatar

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 17 January 2012 20:30, Atom Smasher <atom <at> smasher.org> wrote:
> On Tue, 17 Jan 2012, Chris Rees wrote:
>
>> > what percentage of linux devs are on salary to develop linux?
>> >
>>
>> You're not comparing like with like.
>>
>> Linux is not an OS; FreeBSD is.
>>
>> Are you talking about Linux? Debian? Red Hat?
>
> ================
>
> linux is, in fact, an operating system.
>
> debian, red hat, ubuntu, gentoo, etc are distributions of that OS.

No.  Linux is, in fact, not an operating system.  It is a kernel.

You can't compare a *project* with a kernel.

You could compare a *distribution* with a project, hence my email.

Chris
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
(Continue reading)

Permalink | Reply |
headers
Adrian Chadd | 17 Jan 2012 23:56
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 16 January 2012 22:32, Atom Smasher <atom <at> smasher.org> wrote:
> On Tue, 17 Jan 2012, richo wrote:
>
>> This would be a different argument if all the devs were paid a salary.
>
> ==============
>
> what percentage of linux devs are on salary to develop linux?

That's the wrong question.

The question is "what is a good minimum threshold for the number of
paid developers on ${PROJECT} (which is project-specific!) to create a
sustainable project, given the requirements of developers and users."

Then you see whether the number of developers meets this threshold.

Adrian
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Doug Barton | 17 Jan 2012 04:35
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 01/16/2012 16:02, Julian Elischer wrote:
> It pretty much boils down to one thing..  man power..

If the basic design of the system is wrong, it doesn't matter how many
person-hours you throw at it (or don't).

--

-- 

	It's always a long day; 86400 doesn't fit into a short.

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Robert Watson | 18 Jan 2012 11:44
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


On Mon, 16 Jan 2012, Julian Elischer wrote:

> On 1/16/12 3:32 PM, William Bentley wrote:
>> I also echo John's sentiments here. Very excellent points made here. Thank 
>> you for voicing your opinion. I was beginning to think I was the only one 
>> who felt this way.
> [...]
>
>> We seem to have lost our way around the release of FreeBSD 7. I am all in 
>> favor of new features but not at the risk of stability and proper life 
>> cycle management.
>> 
>> Are me and John the only people that feel this way or are we among the 
>> minority?
>
> It pretty much boils down to one thing..  man power..

I disagree.  Resourcing is an issue, but it is not *the* issue.  The real 
issue here is a failure by the release engineering team (which includes me) to 
concurrently perform major and minor releases.  Given that minor releases run 
like clockwork in most cases, this is disappointing.  In the past, there have 
been a lot of good technical and structural obstacles to trying to do 
clockwork releases for both major and minor releases:

- Tight synchronisation of the ports and base release schedule means that the
   base release schedule limits ports productivity.

- Long freezes forced on us by poor revision control support for branching.
(Continue reading)

Permalink | Reply |
headers
Andriy Gapon | 18 Jan 2012 11:58
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

on 18/01/2012 12:44 Robert Watson said the following:
> My view is therefore that we have a "social" -- which is to say structural --
> problem.  Regardless of ".0" releases, we should be forcing out minor releases,
> which are morally similar to "service packs" in the vocabulary of other vendors:
> device driver improvements, new CPU support, steady of conservative feature
> development, etc, required to keep older major releases viable on contemporary
> hardware and with contemporary applications.  One known problem is using a
> single "head" release engineer in steering all releases. I think this is a
> mistake, as it makes the whole project's release schedule subject to individual
> unavailability, burnout, etc, as well as increasing the risks associated with
> low bus factor.  I'd like to see us move to a model where new release engineers
> are mentored in from the developer community for point releases, ensuring that
> we increase our expertise, share knowledge about release engineering in the
> broader community, and get new eyes on the process which can lead more readily
> to process improvements.  The role of the "head" release engineer shouldn't be
> hands-on prodution of every release, but rather, steering of the overall team.
> 
> I'd like to see this begin with 8.3, drawing a per-release lead from the
> developer community, and continue with a fixed schedule release of 8.4.  Yes,
> more staffing is needed, but first, what is needed is an improvement in model.

Robert,

I think that in addition to what you suggest above it would also be useful to
have some sort of branch meisters.  The current model when every developer
decides whether and when and where to do an MFC does not seem to be the proper
one.  Developers often forget to do an MFC.  Or decide against an MFC when there
is no reason to do so.  Or sometimes do an MFC where the stable branch users
would rather prefer that it is not done.
There needs to be someone who "owns" a branch and who want to make it perfect.
(Continue reading)

Permalink | Reply |
headers
Daniel Eischen | 18 Jan 2012 18:13
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Wed, 18 Jan 2012, Andriy Gapon wrote:

> on 18/01/2012 12:44 Robert Watson said the following:
>> My view is therefore that we have a "social" -- which is to say structural --
>> problem.  Regardless of ".0" releases, we should be forcing out minor releases,
>> which are morally similar to "service packs" in the vocabulary of other vendors:
>> device driver improvements, new CPU support, steady of conservative feature
>> development, etc, required to keep older major releases viable on contemporary
>> hardware and with contemporary applications.  One known problem is using a
>> single "head" release engineer in steering all releases. I think this is a
>> mistake, as it makes the whole project's release schedule subject to individual
>> unavailability, burnout, etc, as well as increasing the risks associated with
>> low bus factor.  I'd like to see us move to a model where new release engineers
>> are mentored in from the developer community for point releases, ensuring that
>> we increase our expertise, share knowledge about release engineering in the
>> broader community, and get new eyes on the process which can lead more readily
>> to process improvements.  The role of the "head" release engineer shouldn't be
>> hands-on prodution of every release, but rather, steering of the overall team.
>>
>> I'd like to see this begin with 8.3, drawing a per-release lead from the
>> developer community, and continue with a fixed schedule release of 8.4.  Yes,
>> more staffing is needed, but first, what is needed is an improvement in model.
>
> Robert,
>
> I think that in addition to what you suggest above it would also be useful to
> have some sort of branch meisters.  The current model when every developer
> decides whether and when and where to do an MFC does not seem to be the proper
> one.  Developers often forget to do an MFC.  Or decide against an MFC when there
> is no reason to do so.  Or sometimes do an MFC where the stable branch users
(Continue reading)

Permalink | Reply |
headers
Andriy Gapon | 18 Jan 2012 18:56
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

on 18/01/2012 19:13 Daniel Eischen said the following:
> "someone who owns a branch..." - If you cut release N.0, do not
> move -current to N+1.  Keep -current at N for a while, prohibiting
> ABI changes, and any other risky changes.  If a developer wants to
> do possibly disruptive work, they can do it from their own repo.

I am totally against this.

--

-- 
Andriy Gapon
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Igor Mozolevsky | 18 Jan 2012 20:09
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 18 January 2012 17:56, Andriy Gapon <avg <at> freebsd.org> wrote:
> on 18/01/2012 19:13 Daniel Eischen said the following:
>> "someone who owns a branch..." - If you cut release N.0, do not
>> move -current to N+1.  Keep -current at N for a while, prohibiting
>> ABI changes, and any other risky changes.  If a developer wants to
>> do possibly disruptive work, they can do it from their own repo.
>
> I am totally against this.

I was thinking about this and I'm with Andriy on this: such solution
has no long term potential and will only serve to stagnate the
innovation. This has been repeated over and over in this thread, but
it's worth another mention, currently, there are effectively four
tracks: 7.4, 8.2, 9.0 and -HEAD, which understandably poses a lot of
difficulty for in terms of maintenance. Whatever historical reason for
that is, I think a lot of people would agree that this needs changing
in the near future to have a single -RELEASE branch and a single -HEAD
branch, but with the understanding by the devs that just because
-RELEASE has been cut, it doesn't mean that everyone, en mass, drops
development on that and hops on the -HEAD bandwagon...

--
Igor M.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
John Kozubik | 18 Jan 2012 20:46

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


On Wed, 18 Jan 2012, Igor Mozolevsky wrote:

> I was thinking about this and I'm with Andriy on this: such solution
> has no long term potential and will only serve to stagnate the
> innovation. This has been repeated over and over in this thread, but
> it's worth another mention, currently, there are effectively four
> tracks: 7.4, 8.2, 9.0 and -HEAD, which understandably poses a lot of
> difficulty for in terms of maintenance. Whatever historical reason for
> that is, I think a lot of people would agree that this needs changing
> in the near future to have a single -RELEASE branch and a single -HEAD
> branch, but with the understanding by the devs that just because
> -RELEASE has been cut, it doesn't mean that everyone, en mass, drops
> development on that and hops on the -HEAD bandwagon...

And as long as we're repeating ... :)

Since 9.0 is already out of the bag, I think a decent approach would be to 
fizzle out 8.x on the current timeline/trajectory (maybe 8.4 in 6-8 
months, and maybe 8.5 in a year or so), then:

- EOL 7
- mark 8 as legacy
- mark 9 as the _only_ production release
- release 10.0 in January 2017

And in the meantime, begin the every 4-6 month minor releases that we all 
agree can occur with 9.  By Jan 2017, you get to 9.12 or 9.14 or so.

This is nice because no upheaval needs to happen with 7 and 8, and
(Continue reading)

Permalink | Reply |
headers
Mark Felder | 18 Jan 2012 21:20
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Wed, 18 Jan 2012 13:46:45 -0600, John Kozubik <john <at> kozubik.com> wrote:

>
> And as long as we're repeating ... :)
>
> Since 9.0 is already out of the bag, I think a decent approach would be  
> to fizzle out 8.x on the current timeline/trajectory (maybe 8.4 in 6-8  
> months, and maybe 8.5 in a year or so), then:
>
> - EOL 7
> - mark 8 as legacy
> - mark 9 as the _only_ production release
> - release 10.0 in January 2017
>
> And in the meantime, begin the every 4-6 month minor releases that we  
> all agree can occur with 9.  By Jan 2017, you get to 9.12 or 9.14 or so.
>
> This is nice because no upheaval needs to happen with 7 and 8, and  
> interested developers do not get kneecapped vis a vis 9 - they can just  
> keep going where they were going with it, and the only real change is  
> that 10 is pushed out a long ways, and people[1] get to really sink  
> their teeth into 9.
>

What are the policies for changes though? Are we stuck with 9.0's feature  
set for 5 years? Will we have to wait 5 years to get a stable release of  
FreeBSD with KMS/GEM? That work is unfinished and didn't make 9.0; it's  
also a huge changeset. How will things like this be dealt with? Five years  
is a long time for the next stable release if we have a policy to not  
import major changes from -CURRENT. It would be devastating to so many
(Continue reading)

Permalink | Reply |
headers
Matthew D. Fuller | 19 Jan 2012 00:39

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Wed, Jan 18, 2012 at 02:20:56PM -0600 I heard the voice of
Mark Felder, and lo! it spake thus:
> On Wed, 18 Jan 2012 13:46:45 -0600, John Kozubik <john <at> kozubik.com> wrote:
> > This is nice because no upheaval needs to happen with 7 and 8, and
> > interested developers do not get kneecapped vis a vis 9 - they can
> > just  keep going where they were going with it, and the only real
> > change is  that 10 is pushed out a long ways, and people[1] get to
> > really sink  their teeth into 9.
> >
> 
> What are the policies for changes though? Are we stuck with 9.0's
> feature  set for 5 years? Will we have to wait 5 years to get a
> stable release of  FreeBSD with KMS/GEM? That work is unfinished and
> didn't make 9.0; it's  also a huge changeset. How will things like
> this be dealt with? Five years  is a long time for the next stable
> release if we have a policy to not  import major changes from
> -CURRENT. It would be devastating to so many  users.

This is where the problem comes in.

As I read it, John's problem in a sentence is "I just got onto 8.x,
and it's already shutting down!"  If the problem is "stable trains
don't live long enough", why, the solution's simple; make stable
trains live longer!

The problem is, there are unpleasant tradeoffs every direction we try
to go with that.  We can:

1) Just make each one live longer.  Of course, that means that pretty
   soon we're maintaining 3 and 4 -STABLE branches all the time.
(Continue reading)

Permalink | Reply |
headers
Mike Meyer | 19 Jan 2012 01:00
Gravatar

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Wed, 18 Jan 2012 17:39:31 -0600
"Matthew D. Fuller" <fullermd <at> over-yonder.net> wrote:
> Or there's another option, a variant of (1), where we extend the
> lifetime of some major release trains, but not all.  Every second, or
> every third.  Then we can have a longer life, without ballooning out
> the number of trains being supported.  But that has big drawbacks too;
> the problems of backporting aren't just the number of branches to port
> too, but how far back they are.  Backporting from -CURRENT to 9 right
> now is almost trivial.  Going to 8 isn't too bad for most things.  To
> 7, it's getting to be a much bigger deal.  If 7 were an "extended
> support" train, with 2 years of active support left on it, not only
> would backporting things get inordinately expensive from accumulated
> differences, but they'd get very _risky_ too.  They slip from
> "backport" into "rewrite for", and now we've seriously compromised the
> stability of the branch, undermining our own goals.

Let's look at this again. And look at why people want longer term
support. In my experience, they want this because they want security
updates/bug fixes for production systems. If LTS changes that were
limited to that after the normal support period, and restricted to
cases where the effort was warranted by the severity of the issue, it
would seriously mitigate the backporting issues.

Of course, from reading this discussion, it's clear that there are
people who want both long term support *and* new features (at least in
the form of new device drivers).

It may well be that you get to choose any two of:

- Software that is very cheap or free.
(Continue reading)

Permalink | Reply |
headers
Doug Barton | 18 Jan 2012 21:27
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 01/18/2012 11:46, John Kozubik wrote:
> - mark 9 as the _only_ production release

While I understand your motivation, I am not sure this is a workable
goal when combined with the goal that others have expressed of longer
timelines for the support of a given branch. Speaking from personal
experience, once a service is released on a given platform the costs of
migration can be significant. And if what I have is working well and
only needs the occasional bug/security fix my motivations for migration
are near zero. So the tradeoffs then become more frequent major releases
to get new features, vs. longer support for a given release branch.

Let's take 5 years as a reasonable time period for supporting a branch.
Waiting that long between major releases would significantly stifle the
ability to add new features that require breaks to the [AK][BP]I. It
would also inhibit our ability to do revolutionary architectural changes
such as moving to clang as the primary supported compiler.

What I've proposed instead is a new major release every 2 1/2 years,
where the new release coincides with the EOL of the oldest production
release. That way we have a 5-year cycle of support for each major
branch, and no more than 2 production branches extant at one time.

History tells us that 2 production branches is a goal we can achieve,
with the focus shifting more heavily towards only bug/security fixes in
the oldest branch after the new production release branch is cut. If we
combine that with the ideas that are being put forward about teams that
"own" a production branch, and a more frequent stripped-down release
process, I think this is a very workable model.
(Continue reading)

Permalink | Reply |
headers
Freddie Cash | 19 Jan 2012 01:00
Picon
Gravatar

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Wed, Jan 18, 2012 at 12:27 PM, Doug Barton <dougb <at> freebsd.org> wrote:
> On 01/18/2012 11:46, John Kozubik wrote:
>> - mark 9 as the _only_ production release
>
> What I've proposed instead is a new major release every 2 1/2 years,
> where the new release coincides with the EOL of the oldest production
> release. That way we have a 5-year cycle of support for each major
> branch, and no more than 2 production branches extant at one time.
>
> History tells us that 2 production branches is a goal we can achieve,
> with the focus shifting more heavily towards only bug/security fixes in
> the oldest branch after the new production release branch is cut. If we
> combine that with the ideas that are being put forward about teams that
> "own" a production branch, and a more frequent stripped-down release
> process, I think this is a very workable model.

This is similar to how Debian works (the other OS we use the most often).

They have "testing" (aka -CURRENT) where all the new development takes
place, that will eventually become the next major release; "stable"
(aka production -RELEASE) which sees minor (actually, point) releases
every few months; and "oldstable" (aka legacy -RELEASE) which sees no
development beyond major security/bug fixes.

There's approximately 2 years between major releases, at which time
"oldstable" is EOL'd, "stable" becomes "oldstable", "testing" becomes
"stable", and development continue with the new "testing".

I can see something like that working for FreeBSD, as you've outlined
it above.  It seems to work well for them, although it's not a perfect
(Continue reading)

Permalink | Reply |
headers
John Kozubik | 19 Jan 2012 23:14

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


Hi Doug,

On Wed, 18 Jan 2012, Doug Barton wrote:

> On 01/18/2012 11:46, John Kozubik wrote:
>> - mark 9 as the _only_ production release
>
> While I understand your motivation, I am not sure this is a workable
> goal when combined with the goal that others have expressed of longer
> timelines for the support of a given branch. Speaking from personal
> experience, once a service is released on a given platform the costs of
> migration can be significant. And if what I have is working well and
> only needs the occasional bug/security fix my motivations for migration
> are near zero. So the tradeoffs then become more frequent major releases
> to get new features, vs. longer support for a given release branch.

Agreed.  What I am saying is that that "dial" is currently set 
incorrectly.  I think we should sacrifice new features for longer lived 
releases.

My own experience has been that all of the new features I have benefited 
from did not start being useful until several releases past their 
introduction.  For instance, one or more new releases has been, at least 
partly, justified by ZFS ... and yet it is only now with 8.3 that I'm even 
beginning to think of deploying.  The same is true with the excellent SMP 
code we all now enjoy - it took until 6 to be usable.

That would suggest that the end users don't really lose on features by 
delaying the new releases, since those features typically aren't ready
(Continue reading)

Permalink | Reply |
headers
Doug Barton | 19 Jan 2012 23:39
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Thu, 19 Jan 2012, John Kozubik wrote:

>
> Hi Doug,
>
> On Wed, 18 Jan 2012, Doug Barton wrote:
>
>> On 01/18/2012 11:46, John Kozubik wrote:
>>> - mark 9 as the _only_ production release
>> 
>> While I understand your motivation, I am not sure this is a workable
>> goal when combined with the goal that others have expressed of longer
>> timelines for the support of a given branch. Speaking from personal
>> experience, once a service is released on a given platform the costs of
>> migration can be significant. And if what I have is working well and
>> only needs the occasional bug/security fix my motivations for migration
>> are near zero. So the tradeoffs then become more frequent major releases
>> to get new features, vs. longer support for a given release branch.
>
>
> Agreed.  What I am saying is that that "dial" is currently set incorrectly. 
> I think we should sacrifice new features for longer lived releases.

There are at least 2 problems with that. First, often the new features 
are either really useful, or actually necessary. Second, "getting new 
features into a production release" is one of the motivating factors for 
FreeBSD developers. Yes, I agree with others in this thread that the 
pendulum has swung too far in allowing people free reign with little/no 
responsibility for followup. But we still have to acknowledge that 
reality.
(Continue reading)

Permalink | Reply |
headers
John Kozubik | 19 Jan 2012 23:43

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


Hi Doug,

On Thu, 19 Jan 2012, Doug Barton wrote:

>>> What I've proposed instead is a new major release every 2 1/2 years,
>>> where the new release coincides with the EOL of the oldest production
>>> release. That way we have a 5-year cycle of support for each major
>>> branch, and no more than 2 production branches extant at one time.
>> 
>> 
>> I think that at first glance, 2.5 or 3 years sounds completely reasonable.
>
> You're not following the math. :)  I'm proposing a 5 year support cycle for 
> each production branch.

Yes, you're right - I missed that.

5 year support, and overlapping 2.5 year majors ... provided that minors 
got increased to 3 per year ... would be fantastic.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Adrian Chadd | 19 Jan 2012 23:54
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

.. and people _do_ realise that this is all mostly driven by volunteers,
right?

The companies/individuals that _could_ run this kind of thing do it
internally. So you're left with volunteers doing the public releases
instead of the vendors who are asking for it.

Honestly, I think the re <at>  and ports building teams would _love_ some help.
If you'd like to see this happen, step up and offer your assistance. That's
the most likely way to achieve your goal.

Adrian
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Robert Huff | 22 Jan 2012 15:39
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


Doug Barton writes:

>  > That would suggest that the end users don't really lose on features by 
>  > delaying the new releases, since those features typically aren't ready 
>  > anyway.
>  
>  I think "typically" is stretching it a bit here. As humans we
>  tend to focus our attention on the things that cause us problems,
>  rather than acknowledging (or even being aware of) the things
>  that are working well in the background.

	Also: how many (non-ports) developers out there remember bugs
(including performance issues) that weren't triggered until the code
went live?  One can argue it shouldn't happen ... but it does.

					Robert Huff

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
rank1seeker | 22 Jan 2012 17:01
Picon

Change of ftp download server's dir layout, from 9

Example:
ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/9.0-RELEASE/

Refering to KERNEL:
    8 -> kernels
    9 -> kernel (It was supposed to be 'kernels.txz', in order to preserve naming scheme)

    9 -> manpages is a NO MORE

Where are CHECKSUM.MD5 and CHECKSUM.SHA256 for *.txz ?!?

This confused my script, so I'm all in filling additional IFs statements for >9

PS: I do welcome .txz
;)


Domagoj Smolčić
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Andrey Fesenko | 22 Jan 2012 17:35
Picon

Re: Change of ftp download server's dir layout, from 9

2012/1/22  <rank1seeker <at> gmail.com>:
> Example:
> ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/9.0-RELEASE/
>
> Refering to KERNEL:
>    8 -> kernels
>    9 -> kernel (It was supposed to be 'kernels.txz', in order to preserve naming scheme)
>
>    9 -> manpages is a NO MORE
>
> Where are CHECKSUM.MD5 and CHECKSUM.SHA256 for *.txz ?!?
>
> This confused my script, so I'm all in filling additional IFs statements for >9
>
> PS: I do welcome .txz
> ;)
>

I think now ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/9.0-RELEASE/MANIFEST
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Devin Teske | 22 Jan 2012 17:42

Re: Change of ftp download server's dir layout, from 9


On Jan 22, 2012, at 8:01 AM, <rank1seeker <at> gmail.com> wrote:

> Example:
> ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/9.0-RELEASE/
> 
> Refering to KERNEL:
>    8 -> kernels
>    9 -> kernel (It was supposed to be 'kernels.txz', in order to preserve naming scheme)
> 
>    9 -> manpages is a NO MORE
> 
> Where are CHECKSUM.MD5 and CHECKSUM.SHA256 for *.txz ?!?

You want the new "MANIFEST" file for such info.

Though, it's unclear merely by just looking at the hash what digest it is (looks long enough to be sha256).
--

-- 
Devin

> 
> This confused my script, so I'm all in filling additional IFs statements for >9
> 
> PS: I do welcome .txz
> ;)
> 
> 
> Domagoj Smolčić
> _______________________________________________
> freebsd-hackers <at> freebsd.org mailing list
(Continue reading)

Permalink | Reply |
headers
rank1seeker | 22 Jan 2012 18:11
Picon

Re: Change of ftp download server's dir layout, from 9

----- Original Message -----
From: Devin Teske <devin.teske <at> fisglobal.com>
To: <rank1seeker <at> gmail.com>
Cc: <hackers <at> FreeBSD.org>
Date: Sun, 22 Jan 2012 08:42:00 -0800
Subject: Re: Change of ftp download server's dir layout, from 9

> 
> On Jan 22, 2012, at 8:01 AM, <rank1seeker <at> gmail.com> wrote:
> 
> > Example:
> > ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/9.0-RELEASE/
> > 
> > Refering to KERNEL:
> >    8 -> kernels
> >    9 -> kernel (It was supposed to be 'kernels.txz', in order to preserve naming scheme)
> > 
> >    9 -> manpages is a NO MORE
> > 
> > Where are CHECKSUM.MD5 and CHECKSUM.SHA256 for *.txz ?!?
> 
> You want the new "MANIFEST" file for such info.
> 
> Though, it's unclear merely by just looking at the hash what digest it is (looks long enough to be sha256).
> -- 
> Devin

Yep.
And regarding a manpages ... I have a HUNCH, it is now part of a base.txz
Thou, will know for sure, once I spit it into DESTDIR. ;)
(Continue reading)

Permalink | Reply |
headers
Nathan Whitehorn | 22 Jan 2012 18:17
Picon
Favicon

Re: Change of ftp download server's dir layout, from 9

On 01/22/12 11:11, rank1seeker <at> gmail.com wrote:
> ----- Original Message -----
> From: Devin Teske<devin.teske <at> fisglobal.com>
> To:<rank1seeker <at> gmail.com>
> Cc:<hackers <at> FreeBSD.org>
> Date: Sun, 22 Jan 2012 08:42:00 -0800
> Subject: Re: Change of ftp download server's dir layout, from 9
>
>> On Jan 22, 2012, at 8:01 AM,<rank1seeker <at> gmail.com>  wrote:
>>
>>> Example:
>>> ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/9.0-RELEASE/
>>>
>>> Refering to KERNEL:
>>>     8 ->  kernels
>>>     9 ->  kernel (It was supposed to be 'kernels.txz', in order to preserve naming scheme)
>>>
>>>     9 ->  manpages is a NO MORE
>>>
>>> Where are CHECKSUM.MD5 and CHECKSUM.SHA256 for *.txz ?!?
>> You want the new "MANIFEST" file for such info.
>>
>> Though, it's unclear merely by just looking at the hash what digest it is (looks long enough to be sha256).
>> -- 
>> Devin
> Yep.
> And regarding a manpages ... I have a HUNCH, it is now part of a base.txz
> Thou, will know for sure, once I spit it into DESTDIR. ;)
>
(Continue reading)

Permalink | Reply |
headers
Chris | 20 Jan 2012 22:25
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 18 January 2012 17:13, Daniel Eischen <deischen <at> freebsd.org> wrote:
> On Wed, 18 Jan 2012, Andriy Gapon wrote:
>
>> on 18/01/2012 12:44 Robert Watson said the following:
>>
>>> My view is therefore that we have a "social" -- which is to say
>>> structural --
>>> problem.  Regardless of ".0" releases, we should be forcing out minor
>>> releases,
>>> which are morally similar to "service packs" in the vocabulary of other
>>> vendors:
>>> device driver improvements, new CPU support, steady of conservative
>>> feature
>>> development, etc, required to keep older major releases viable on
>>> contemporary
>>> hardware and with contemporary applications.  One known problem is using
>>> a
>>> single "head" release engineer in steering all releases. I think this is
>>> a
>>> mistake, as it makes the whole project's release schedule subject to
>>> individual
>>> unavailability, burnout, etc, as well as increasing the risks associated
>>> with
>>> low bus factor.  I'd like to see us move to a model where new release
>>> engineers
>>> are mentored in from the developer community for point releases, ensuring
>>> that
>>> we increase our expertise, share knowledge about release engineering in
>>> the
>>> broader community, and get new eyes on the process which can lead more
(Continue reading)

Permalink | Reply |
headers
Roman Kurakin | 17 Jan 2012 12:50
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

Robert Watson wrote:
>
> On Mon, 16 Jan 2012, Julian Elischer wrote:
>
>> On 1/16/12 3:32 PM, William Bentley wrote:
>>> I also echo John's sentiments here. Very excellent points made here. 
>>> Thank you for voicing your opinion. I was beginning to think I was 
>>> the only one who felt this way.
>> [...]
>>
>>> We seem to have lost our way around the release of FreeBSD 7. I am 
>>> all in favor of new features but not at the risk of stability and 
>>> proper life cycle management.
>>>
>>> Are me and John the only people that feel this way or are we among 
>>> the minority?
>>
>> It pretty much boils down to one thing..  man power..
>
> I disagree.  Resourcing is an issue, but it is not *the* issue.  The 
> real issue here is a failure by the release engineering team (which 
> includes me) to concurrently perform major and minor releases.  Given 
> that minor releases run like clockwork in most cases, this is 
> disappointing.  In the past, there have been a lot of good technical 
> and structural obstacles to trying to do clockwork releases for both 
> major and minor releases:
>
> - Tight synchronisation of the ports and base release schedule means 
> that the
>   base release schedule limits ports productivity.
(Continue reading)

Permalink | Reply |
headers
Tim Kientzle | 19 Jan 2012 07:54

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Jan 18, 2012, at 2:44 AM, Robert Watson wrote:
> 
> ... perhaps what is really called for is breaking out our .0 release engineering entirely from .x
engineering, with freebsd-update being in the latter.

This is a great idea!

In particular, it would allow more people to be involved.

There's a practical limit to the number of people that can be
involved in any single release process; having multiple
groups handling separate releases (for example, we
might have a group working just on 8-STABLE releases,
so that 8.3, 8.4, etc, weren't competing for resources
with the more complex 9.0 release).

Tim

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Daniel Gerzo | 19 Jan 2012 14:04
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Wed, 18 Jan 2012 22:54:44 -0800, Tim Kientzle wrote:
> On Jan 18, 2012, at 2:44 AM, Robert Watson wrote:
>>
>> ... perhaps what is really called for is breaking out our .0 release 
>> engineering entirely from .x engineering, with freebsd-update being in 
>> the latter.
>
> This is a great idea!
>
> In particular, it would allow more people to be involved.

I like this idea too.

In a summary to this thread, I'd say that people would love to see:

- more regular minor releases, e.g. 8.3, 8.4 say every 4 months (3x per 
year)
- have max. 2 -STABLE branches under support at any given time (once a 
new -STABLE is created, EOL the oldest supported branch; in a result we 
would release major version a bit less often. However 5 years between 
mayor releases is too much and that would only stagnate the development 
and make switching between mayor releases much more difficult)
- make X.Y.Z releases more common or issue Errata notices for existing 
minor releases more often. I can easily imagine us fixing much more bugs 
by Errata notices than we do now. How much work is  behind issuing an 
errata notice?
- an idea from this thread that I liked is to allow people to 
cherry-pick the patch level (-pX) which would be great if we managed to 
release more errata notices.
(Continue reading)

Permalink | Reply |
headers
Garrett Cooper | 17 Jan 2012 01:06
Picon
Gravatar

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Mon, Jan 16, 2012 at 3:32 PM, William Bentley <William <at> futurecis.com> wrote:
> I also echo John's sentiments here. Very excellent points made here.
> Thank you for voicing your opinion. I was beginning to think I was the
> only one who felt this way.
>
> I also have several FreeBSD installations spread across different
> development/production systems and it is not feasible to always upgrade
> to the latest and greatest. Part of why FreeBSD is difficult to adopt
> into more of the commercial/government sectors is because of this fast
> paced release cycle and most of the important patches/fixes are not
> backported far enough. This is why most of my customers decide to use
> Solaris or RedHat and not FreeBSD. (Not looking to start a flame war
> about the OS choice/etc just pointing out the Release cycle model). I
> would love to push FreeBSD harder but it is becoming increasingly
> difficult as of late.
>
> We seem to have lost our way around the release of FreeBSD 7. I am all
> in favor of new features but not at the risk of stability and proper
> life cycle management.
>
> Are me and John the only people that feel this way or are we among the
> minority?

    You aren't. There are other people like Devin Teske's group that
feel the same (they're upgrading from 4.x to 8.2! Brave man.. and
godspeed to him), along with some development organizations that
depend on long release cycles (IronPort, Isilon, etc).
    That being said. More people, more likelihood to succeed with what
you need, like julian <at>  suggests. I like long release cycles too for
stuff that I find critical and "in production", like my router. My
(Continue reading)

Permalink | Reply |
headers
Devin Teske | 18 Jan 2012 00:09

RE: FreeBSD has serious problems with focus, longevity, and lifecycle


> -----Original Message-----
> From: owner-freebsd-hackers <at> freebsd.org [mailto:owner-freebsd-
> hackers <at> freebsd.org] On Behalf Of Garrett Cooper
> Sent: Monday, January 16, 2012 4:07 PM
> To: WBentley <at> futurecis.com
> Cc: freebsd-hackers <at> freebsd.org
> Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle
> 
> On Mon, Jan 16, 2012 at 3:32 PM, William Bentley <William <at> futurecis.com>
> wrote:
> > I also echo John's sentiments here. Very excellent points made here.
> > Thank you for voicing your opinion. I was beginning to think I was the
> > only one who felt this way.
> >
> > I also have several FreeBSD installations spread across different
> > development/production systems and it is not feasible to always
> > upgrade to the latest and greatest. Part of why FreeBSD is difficult
> > to adopt into more of the commercial/government sectors is because of
> > this fast paced release cycle and most of the important patches/fixes
> > are not backported far enough. This is why most of my customers decide
> > to use Solaris or RedHat and not FreeBSD. (Not looking to start a
> > flame war about the OS choice/etc just pointing out the Release cycle
> > model). I would love to push FreeBSD harder but it is becoming
> > increasingly difficult as of late.
> >
> > We seem to have lost our way around the release of FreeBSD 7. I am all
> > in favor of new features but not at the risk of stability and proper
> > life cycle management.
> >
(Continue reading)

Permalink | Reply |
headers
John Kozubik | 18 Jan 2012 00:52

RE: FreeBSD has serious problems with focus, longevity, and lifecycle


Hi Devin,

On Tue, 17 Jan 2012, Devin Teske wrote:

> I brought this up in last weekend's BAFUG meeting...
>
> We're _very_ interested in replicating the long-lifecycle of the 4-series with a
> newer series. But which one?
>
> Right now, we're jumping to the 8-series, but after seeing that one of the major
> focal points for 9 is McKusick's SU+J (SoftUpdates Journaling -- tunefs -j
> enable), I'm ready to say that the 9-series should instead be the "chosen
> outlier" when it comes to picking one single release to have an ultra-wide
> lifecycle.
>
> The 9-series represents the first release to integrate a journaled filesystem
> by-default into the system (aka boot) filesystem(s). We were pleasantly
> surprised to see that the default installer enabled SU+J by-default when
> choosing "guided" and "auto" for disk partitioning.

There's two parallel suggestions being put forth here, both of which are 
interesting:

- Allow a related party to adopt a release (as I understand it) and 
provide a sub-community taht donates resources to tending and updating 
that release.

- Picking a "chosen" release to really dive into, officially, and polish 
and extend it, like 4.
(Continue reading)

Permalink | Reply |
headers
Devin Teske | 18 Jan 2012 02:38

RE: FreeBSD has serious problems with focus, longevity, and lifecycle

Hi John,

> -----Original Message-----
> From: John Kozubik [mailto:john <at> kozubik.com]
> Sent: Tuesday, January 17, 2012 3:52 PM
> To: Devin Teske
> Cc: 'Garrett Cooper'; WBentley <at> futurecis.com; freebsd-hackers <at> freebsd.org
> Subject: RE: FreeBSD has serious problems with focus, longevity, and lifecycle
> 
> 
> Hi Devin,
> 
> On Tue, 17 Jan 2012, Devin Teske wrote:
> 
> > I brought this up in last weekend's BAFUG meeting...
> >
> > We're _very_ interested in replicating the long-lifecycle of the
> > 4-series with a newer series. But which one?
> >
> > Right now, we're jumping to the 8-series, but after seeing that one of
> > the major focal points for 9 is McKusick's SU+J (SoftUpdates
> > Journaling -- tunefs -j enable), I'm ready to say that the 9-series
> > should instead be the "chosen outlier" when it comes to picking one
> > single release to have an ultra-wide lifecycle.
> >
> > The 9-series represents the first release to integrate a journaled
> > filesystem by-default into the system (aka boot) filesystem(s). We
> > were pleasantly surprised to see that the default installer enabled
> > SU+J by-default when choosing "guided" and "auto" for disk partitioning.
>
(Continue reading)

Permalink | Reply |
headers
Andriy Gapon | 18 Jan 2012 10:38
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

on 18/01/2012 01:09 Devin Teske said the following:
> I'm ready to say that the 9-series should instead be the "chosen
> outlier" when it comes to picking one single release to have an ultra-wide
> lifecycle.

But how can you say that without knowing what will (can) come in 10.  Maybe it
will have something that would be a complete re-write, but something that you
would super-want.
IMO, it's the whole purpose of our present stable branches policy to let users
try/test/use new/advanced features sooner, all while having a choice.

--

-- 
Andriy Gapon
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Steven Hartland | 17 Jan 2012 02:09
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


----- Original Message ----- 
From: "John Kozubik" <john <at> kozubik.com>
To: <freebsd-hackers <at> freebsd.org>
Sent: Monday, January 16, 2012 10:28 PM
Subject: FreeBSD has serious problems with focus, longevity, and lifecycle

> 
> Friends,
> 
> I was disappointed to see that 8.3-RELEASE is now slated to come out in 
> March of 2012.  This will be ~13 months since 8.2-RELEASE and is typical 
> of a trend towards longer gaps between minor releases.

...

I must say as a small company that runs ~200 machines on FreeBSD
I do see where John is coming from, as it is very time consuming to keep
things up to date and new is not always better e.g. we still have boxes
stuck on 6.x as issues introduced in the Linux compat after that caused
problems.

That said I'm in two minds as the features that have been brought in by
the more rapid dev cycle like ZFS have been great.

Where I do see an issue is where it feels like we've just got to a solid
8.2 release with p6 and some addition patches we see things like em driver
updates required to run newer hardware only in 9.

While we might like to push everything to 9 it brings with it a large
(Continue reading)

Permalink | Reply |
headers
John Kozubik | 17 Jan 2012 07:20

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


On Tue, 17 Jan 2012, Steven Hartland wrote:

>> I was disappointed to see that 8.3-RELEASE is now slated to come out in 
>> March of 2012.  This will be ~13 months since 8.2-RELEASE and is typical of 
>> a trend towards longer gaps between minor releases.
>
> ...
>
> I must say as a small company that runs ~200 machines on FreeBSD
> I do see where John is coming from, as it is very time consuming to keep
> things up to date and new is not always better e.g. we still have boxes
> stuck on 6.x as issues introduced in the Linux compat after that caused
> problems.
>
> That said I'm in two minds as the features that have been brought in by
> the more rapid dev cycle like ZFS have been great.

The features are great - nobody doesn't want the features!  Like I said in 
the original post, as wonderful as ZFS on FreeBSD is (and we are deploying 
it this year) it is only now (well, in March) with 8.3 that I feel it is 
finally safe and stable enough to bet the farm on.  I'm not the only one 
that feels this way.

If that's the case, then, ZFS could have been developed just as it has, in 
a development branch, and not been used as justification for (mutiple) 
major releases and all of their disruption.

As I said in the original post - we should be on 6.12 right now, and 
bringing out 7.0, with ZFS v28.
(Continue reading)

Permalink | Reply |
headers
Ivan Voras | 17 Jan 2012 12:47
Picon
Favicon
Gravatar

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 17/01/2012 07:20, John Kozubik wrote:

>  as wonderful as ZFS on FreeBSD is (and we are
> deploying it this year) it is only now (well, in March) with 8.3 that I
> feel it is finally safe and stable enough to bet the farm on. I'm not
> the only one that feels this way.

I must remember to ask you about your experiences with ZFS in about a 
year from now :)

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Julian Elischer | 17 Jan 2012 19:36
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 1/16/12 10:20 PM, John Kozubik wrote:
>
>
> On Tue, 17 Jan 2012, Steven Hartland wrote:
>
>>> I was disappointed to see that 8.3-RELEASE is now slated to come 
>>> out in March of 2012.  This will be ~13 months since 8.2-RELEASE 
>>> and is typical of a trend towards longer gaps between minor releases.
>>
>> ...
>>
>> I must say as a small company that runs ~200 machines on FreeBSD
>> I do see where John is coming from, as it is very time consuming to 
>> keep
>> things up to date and new is not always better e.g. we still have 
>> boxes
>> stuck on 6.x as issues introduced in the Linux compat after that 
>> caused
>> problems.
>>
>> That said I'm in two minds as the features that have been brought 
>> in by
>> the more rapid dev cycle like ZFS have been great.
>
>
> The features are great - nobody doesn't want the features!  Like I 
> said in the original post, as wonderful as ZFS on FreeBSD is (and we 
> are deploying it this year) it is only now (well, in March) with 8.3 
> that I feel it is finally safe and stable enough to bet the farm 
> on.  I'm not the only one that feels this way.
(Continue reading)

Permalink | Reply |
headers
Atom Smasher | 17 Jan 2012 02:03
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

thanks john.

i've been a long-time (10+ years) freeBSD user (desktops, laptops, 
servers, and anywhere else i can run it) and advocate (encouraging others 
to at least check it out) and also a long-time satisfied johnco customer.

my freeBSD days seem to be coming to an end.

i bought myself a LENOVO T510 when it first came out, around early 2010. 
it's got an i5 CPU and Arrandale GPU. it's two years old and on freeBSD i 
STILL can't run xorg properly with it. linux has run fine with it since i 
opened the box. last i checked, freeBSD will be support this GPU in R9... 
or maybe R10...?

i really like freeBSD's robustness, especially compared to linux, among 
other things. i like that freeBSD is genetically a "real" unix... what's 
the real difference between BSD and linux? BSD was developed by unix 
hackers porting the OS to PC hardware; linux was developed by PC hackers 
trying to make their own version of unix. these origins are still very 
apparent, if one knows where to look.

i like that i can set up a freeBSD bare-bones (eg secure) mail-server or 
web-server in an afternoon.

but none of that matters if the damn thing just doesn't work.

over the last two years, and it pains me to say this, i've been running 
linux on that T510. but it gets worse... i've been finding that i'm simply 
more productive on that machine, and spending more time in front of it, 
and more time getting useful things done.
(Continue reading)

Permalink | Reply |
headers
Yuri | 17 Jan 2012 03:44

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 01/16/2012 17:03, Atom Smasher wrote:
>
> i bought myself a LENOVO T510 when it first came out, around early 
> 2010. it's got an i5 CPU and Arrandale GPU. it's two years old and on 
> freeBSD i STILL can't run xorg properly with it. linux has run fine 
> with it since i opened the box. last i checked, freeBSD will be 
> support this GPU in R9... or maybe R10...?

The usual explanation for this is that FreeBSD is the server OS and 
doesn't need to worry about desktop-only hardware. (Not that I agree 
with such position.)
I noticed that FreeBSD overall  isn't too good for laptops (correct me 
if I am wrong). Even if Arrandale GPU worked, there is no working 
network manager in kde or gnome, able to find and setup WiFi networks 
without user typing anything. Also FreeBSD isn't able to enter (and come 
back from) the sleep mode. Also it can't stop the hard drives when the 
system is idle (last time I tried I got system crash). These make it 
very difficult to use FreeBSD on the laptops. Major usability issues.

Yuri
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Atom Smasher | 17 Jan 2012 07:29
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Mon, 16 Jan 2012, Yuri wrote:

> On 01/16/2012 17:03, Atom Smasher wrote:
>> 
>> i bought myself a LENOVO T510 when it first came out, around early 
>> 2010. it's got an i5 CPU and Arrandale GPU. it's two years old and on 
>> freeBSD i STILL can't run xorg properly with it. linux has run fine 
>> with it since i opened the box. last i checked, freeBSD will be support 
>> this GPU in R9... or maybe R10...?
>
> The usual explanation for this is that FreeBSD is the server OS and 
> doesn't need to worry about desktop-only hardware. (Not that I agree 
> with such position.) I noticed that FreeBSD overall isn't too good for 
> laptops (correct me if I am wrong). Even if Arrandale GPU worked, there 
> is no working network manager in kde or gnome, able to find and setup 
> WiFi networks without user typing anything. Also FreeBSD isn't able to 
> enter (and come back from) the sleep mode. Also it can't stop the hard 
> drives when the system is idle (last time I tried I got system crash). 
> These make it very difficult to use FreeBSD on the laptops. Major 
> usability issues.
==================

so i guess that means that i'm tougher than a typical laptop user... and 
instead of making things easier, freeBSD is getting harder.

thing is, when people don't "play" with freeBSD on laptops and desktops, 
then they grow up, get real jobs, and don't know much about it.

if this keeps up, i'll cross a line where i just get more comfortable with 
linux and migrate my freeBSD servers to it.
(Continue reading)

Permalink | Reply |
headers
Julian Elischer | 17 Jan 2012 19:37
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 1/16/12 10:29 PM, Atom Smasher wrote:
>
> so i guess that means that i'm tougher than a typical laptop user... 
> and instead of making things easier, freeBSD is getting harder.
>
> thing is, when people don't "play" with freeBSD on laptops and 
> desktops, then they grow up, get real jobs, and don't know much 
> about it.
>
> if this keeps up, i'll cross a line where i just get more 
> comfortable with linux and migrate my freeBSD servers to it.
>
> this is one of the areas where linux is doing well... people are 
> "playing" with it, but in the process they're getting used to it and 
> comfortable with it. from that background, they can install a linux 
> based server without breaking a sweat. linux's ease of use and 
> hardware support are seeding the next generation of FLOSS and *nix 
> users... and most of them have never installed/used freeBSD.

have a play with PCBSD some time

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Don Lewis | 25 Jan 2012 08:14
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 17 Jan, Atom Smasher wrote:
> thanks john.
> 
> i've been a long-time (10+ years) freeBSD user (desktops, laptops, 
> servers, and anywhere else i can run it) and advocate (encouraging others 
> to at least check it out) and also a long-time satisfied johnco customer.
> 
> my freeBSD days seem to be coming to an end.
> 
> i bought myself a LENOVO T510 when it first came out, around early 2010. 
> it's got an i5 CPU and Arrandale GPU. it's two years old and on freeBSD i 
> STILL can't run xorg properly with it. linux has run fine with it since i 
> opened the box. last i checked, freeBSD will be support this GPU in R9... 
> or maybe R10...?
> 
> i really like freeBSD's robustness, especially compared to linux, among 
> other things. i like that freeBSD is genetically a "real" unix... what's 
> the real difference between BSD and linux? BSD was developed by unix 
> hackers porting the OS to PC hardware; linux was developed by PC hackers 
> trying to make their own version of unix. these origins are still very 
> apparent, if one knows where to look.
> 
> i like that i can set up a freeBSD bare-bones (eg secure) mail-server or 
> web-server in an afternoon.
> 
> but none of that matters if the damn thing just doesn't work.
> 
> over the last two years, and it pains me to say this, i've been running 
> linux on that T510. but it gets worse... i've been finding that i'm simply 
> more productive on that machine, and spending more time in front of it,
(Continue reading)

Permalink | Reply |
headers
Freddie Cash | 17 Jan 2012 07:04
Picon
Gravatar

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

Just a note before everyone goes off on wonderful things were with FreeBSD
4.x going all the way to 4.11:

4.x is an anomoly in the history of FreeBSD major versions,  being the only
release with more than 4? 5? minor releases.

There were only a couple minor versions of 1.x; there were only a couple of
minor versions of 2.x; there were only a couple minor versions of 3.x; and
so on through to 8.x.

IOW, the 'glory days before 5.0' is really no different than the days since
5.0. Looking at the complete history of FreeBSD releases,  4.x is the
outlier that needs to be discarded for the stats to make sense. (Or
something like that, I've failed stats 3 times now.)  :)

When I started with FreeBSD, there were two production releases available:
2.2.something and 3.1. They even came in the same box set from Walnut
Creek? Forget where I ordered them online now. Shortly after, 4.0 was
released, but 3.x was stil developped.

The only difference between pre-5 and post-5 is the switch from
feature-based releases that could take years to develop, to time-based
releases that ship at mostly-regular times, with whatever features are
ready. The latter is actually more useful,  as you can plan ahead of time
as you know the general timeframes between major versions.

So, let's keep a little perspective in the discussion, and not ignore the
past history of FreeBSD releases.

Cheers,
(Continue reading)

Permalink | Reply |
headers
Royce Williams | 17 Jan 2012 08:52
Picon
Gravatar

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

John's trying to manage risk.  Switching from RELEASE to CURRENT adds
a lot of risk and churn, when most folks in this class of use case
just need a few very specific drivers and bugfixes (what some OSes
call "hotfixes".)

John sounds willing to trade a little bit of local risk (and testing
time) in exchange for a way to self-serve a hotfix without abandoning
RELEASE.  How can we enable that?

There are simple cases -- the ones that just need a few files and a
kernel module -- that seem within easy reach.  For example, the eRacks
guys generated these handy binaries for mps(4) for 7.4, 8.0, 8.1 and
8.2:

http://blog.eracks.com/2011/08/lsi-logic-6gbps-mps-driver-for-freebsd-8-2-release/

For me, this was perfect: I got to have my cake (tracking 8.1-RELEASE,
and using freebsd-update) and eat it too (support for specific newer
hardware).  If security updates break my mps(4), I'm on my own -- but
it's still a much better balance of risk for me than switching to
CURRENT.

I know that some fixes are harder than just adding a kernel module.  I
know that the standards for releasing errata are high, and they should
be.  But I wish there was a way to optionally lower that threshold and
say: "Yes, I know this might eat my data.  Let me judge and test that
for myself without otherwise abandoning RELEASE."  If there was a way
to mark hotfixes as "worked for me" (to let the better ones bubble up
to the top), we non-coders could even help manage the list.
(Continue reading)

Permalink | Reply |
headers
Damien Fleuriot | 17 Jan 2012 10:09

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


On 1/16/12 11:28 PM, John Kozubik wrote:
> 
> Friends,
> 
> I was disappointed to see that 8.3-RELEASE is now slated to come out in
> March of 2012.  This will be ~13 months since 8.2-RELEASE and is typical
> of a trend towards longer gaps between minor releases.
> 
> I also see that undercutting the current release before wide deployment
> and maturity is continuing.  7.0 came (barely) after 6.3, which was bad
> enough, but not as bad as 8.0 arriving with 7.2, and now 9.0 with 8.2.
> 
> Finally, the culture of "that's fixed in CURRENT" or "we built those
> changes into (insert next major release)" continues to get worse.  It's
> difficult to escape the notion that FreeBSD is becoming an operating
> system by, and for, FreeBSD developers.
> 

Wholeheartedly agree.

I'm having an increasingly difficult time defending FreeBSD in our
company against the advances of debian kfree which is much easier to
maintain.
Can we get back to the 4.x release style and, hopefully, see some 9.7,
9.8... ?

Check this PR I opened some months ago:
http://www.freebsd.org/cgi/query-pr.cgi?pr=161123&cat=kern
(Continue reading)

Permalink | Reply |
headers
Gleb Smirnoff | 20 Jan 2012 14:38
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

  Damien,

On Tue, Jan 17, 2012 at 10:09:55AM +0100, Damien Fleuriot wrote:
D> I'm having an increasingly difficult time defending FreeBSD in our
D> company against the advances of debian kfree which is much easier to
D> maintain.
D> Can we get back to the 4.x release style and, hopefully, see some 9.7,
D> 9.8... ?
D> 
D> Check this PR I opened some months ago:
D> http://www.freebsd.org/cgi/query-pr.cgi?pr=161123&cat=kern
D> 
D> It was planned for 9.0-RELEASE, there is no mention of 8.x
D> That's just the kind of problem John raises here.
D> 
D> I can't keep on defending FreeBSD when the minor fix to a major bug
D> isn't backported, and only makes it to the next major version, 4 or 5
D> months from now.

Hey, what's the problem here? Fix for kern/161123 has been committed to
stable/8!

You reminded me, and I promptly did merge, w/o any argument, albeit I have
no ability to test it properly on stable/8. I trust you, that you have tested
in on stable/8, but if anything breaks, guess who would be blamed: me or you?

--

-- 
Totus tuus, Glebius.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
(Continue reading)

Permalink | Reply |
headers
Damien Fleuriot | 20 Jan 2012 14:43

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


On 1/20/12 2:38 PM, Gleb Smirnoff wrote:
>   Damien,
> 
> On Tue, Jan 17, 2012 at 10:09:55AM +0100, Damien Fleuriot wrote:
> D> I'm having an increasingly difficult time defending FreeBSD in our
> D> company against the advances of debian kfree which is much easier to
> D> maintain.
> D> Can we get back to the 4.x release style and, hopefully, see some 9.7,
> D> 9.8... ?
> D> 
> D> Check this PR I opened some months ago:
> D> http://www.freebsd.org/cgi/query-pr.cgi?pr=161123&cat=kern
> D> 
> D> It was planned for 9.0-RELEASE, there is no mention of 8.x
> D> That's just the kind of problem John raises here.
> D> 
> D> I can't keep on defending FreeBSD when the minor fix to a major bug
> D> isn't backported, and only makes it to the next major version, 4 or 5
> D> months from now.
> 
> Hey, what's the problem here? Fix for kern/161123 has been committed to
> stable/8!
> 
> You reminded me, and I promptly did merge, w/o any argument, albeit I have
> no ability to test it properly on stable/8. I trust you, that you have tested
> in on stable/8, but if anything breaks, guess who would be blamed: me or you?
> 

Don't be mistaken, I greatly appreciate the work you put into this and
(Continue reading)

Permalink | Reply |
headers
Gleb Smirnoff | 20 Jan 2012 14:59
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Fri, Jan 20, 2012 at 02:43:55PM +0100, Damien Fleuriot wrote:
D> Don't be mistaken, I greatly appreciate the work you put into this and
D> the time you devoted to fixing this issue which was *a real annoyance*
D> in our case.
D> 
D> I'm not saying you didn't merge it Gleb, I'm saying for a loooooooong
D> time I had to manually patch the 8.2-RELEASE boxes, because for some
D> reason that I don't know/understand, the patch couldn't (and still
D> hasn't been, I guess) be merged with 8.2-RELEASE.
D> 
D> Actually, on topic, what prevents patches from being merged with
D> -RELEASE, as opposed to waiting for a new -RELEASE bump ?

It cannot be merged into RELEASE! RELEASE is a point on a branch,
as soon as RELEASE had been released, you can't push anything into
it, unless you have a time machine.

So, the fix has been merged to the branch you reported problem on,
this means that it'll be available in the next release from this
branch - in 8.3-RELEASE.

--

-- 
Totus tuus, Glebius.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Damien Fleuriot | 20 Jan 2012 15:26

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 1/20/12 2:59 PM, Gleb Smirnoff wrote:
> On Fri, Jan 20, 2012 at 02:43:55PM +0100, Damien Fleuriot wrote:
> D> Don't be mistaken, I greatly appreciate the work you put into this and
> D> the time you devoted to fixing this issue which was *a real annoyance*
> D> in our case.
> D> 
> D> I'm not saying you didn't merge it Gleb, I'm saying for a loooooooong
> D> time I had to manually patch the 8.2-RELEASE boxes, because for some
> D> reason that I don't know/understand, the patch couldn't (and still
> D> hasn't been, I guess) be merged with 8.2-RELEASE.
> D> 
> D> Actually, on topic, what prevents patches from being merged with
> D> -RELEASE, as opposed to waiting for a new -RELEASE bump ?
> 
> It cannot be merged into RELEASE! RELEASE is a point on a branch,
> as soon as RELEASE had been released, you can't push anything into
> it, unless you have a time machine.
> 
> So, the fix has been merged to the branch you reported problem on,
> this means that it'll be available in the next release from this
> branch - in 8.3-RELEASE.
> 

Ok good to know (and too bad for us running -RELEASE).

I guess at some point I'll have to study the possibility of us running
-STABLE, perhaps that would be acceptable.

Thanks for ensuring it'll be in 8.3 anyway :)
_______________________________________________
(Continue reading)

Permalink | Reply |
headers
Freddie Cash | 20 Jan 2012 18:58
Picon
Gravatar

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

2012/1/20 Gleb Smirnoff <glebius <at> freebsd.org>:
> On Fri, Jan 20, 2012 at 02:43:55PM +0100, Damien Fleuriot wrote:
> D> Don't be mistaken, I greatly appreciate the work you put into this and
> D> the time you devoted to fixing this issue which was *a real annoyance*
> D> in our case.
> D>
> D> I'm not saying you didn't merge it Gleb, I'm saying for a loooooooong
> D> time I had to manually patch the 8.2-RELEASE boxes, because for some
> D> reason that I don't know/understand, the patch couldn't (and still
> D> hasn't been, I guess) be merged with 8.2-RELEASE.
> D>
> D> Actually, on topic, what prevents patches from being merged with
> D> -RELEASE, as opposed to waiting for a new -RELEASE bump ?
>
> It cannot be merged into RELEASE! RELEASE is a point on a branch,
> as soon as RELEASE had been released, you can't push anything into
> it, unless you have a time machine.

I think he's asking "what's the criteria to push a patch to
RELENG_8_2, the security/fixes branch of -RELEASE?"  IOW, how does one
increase the patch level (8.2-RELEASE-p5 -> 8.2-RELEASE-p6, etc) of a
release?

I believe, and RE/security team can correct me on this, that the
criteria is along the lines of "security issues and major bug fixes
only".  Perhaps that policy should be looked at and loosened slightly
to also include "driver updates"?  Or something along those lines?
Perhaps look at releasing point releases (8.2.1) like DoubB suggested?

--

--
(Continue reading)

Permalink | Reply |
headers
Daniel Gerzo | 21 Jan 2012 02:07
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 20.1.2012 18:58, Freddie Cash wrote:
>> It cannot be merged into RELEASE! RELEASE is a point on a branch,
>> as soon as RELEASE had been released, you can't push anything into
>> it, unless you have a time machine.
>
> I think he's asking "what's the criteria to push a patch to
> RELENG_8_2, the security/fixes branch of -RELEASE?"  IOW, how does one
> increase the patch level (8.2-RELEASE-p5 ->  8.2-RELEASE-p6, etc) of a
> release?
>
> I believe, and RE/security team can correct me on this, that the
> criteria is along the lines of "security issues and major bug fixes
> only".  Perhaps that policy should be looked at and loosened slightly
> to also include "driver updates"?  Or something along those lines?
> Perhaps look at releasing point releases (8.2.1) like DoubB suggested?

I have already said it in this thread - I believe we should consider 
issuing much more errata notices (i.e. -pX); with that I mean we should 
consider more bugs as "major bugs". I don't really see a reason why not. 
And we should also provide some mechanism to allow for cherry-picking 
individual errata notices to be applied on the given release (e.g. p1, 
p2, p5, but not p3, p4).

I don't think it makes sense to issue errata notices for driver updates 
as in support for new devices because we don't ship installation media 
with these patches applied. In those cases we would need to make those 
"point" releases. On the other hand, simply releasing minor releases 
more often would solve that problem too.

--

--
(Continue reading)

Permalink | Reply |
headers
Peter Jeremy | 22 Jan 2012 08:12
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 2012-Jan-21 02:07:35 +0100, Daniel Gerzo <danger <at> FreeBSD.org> wrote:
>I have already said it in this thread - I believe we should consider 
>issuing much more errata notices (i.e. -pX); with that I mean we should 
>consider more bugs as "major bugs". I don't really see a reason why not. 

The problem is that one person's "major bug" is completely unimportant
to another person.  Increasing the number of errata notices would
annoy just as many people as it would please.

>And we should also provide some mechanism to allow for cherry-picking 
>individual errata notices to be applied on the given release (e.g. p1, 
>p2, p5, but not p3, p4).

This is a nice idea and is something you might be able to do yourself
(because the exact list of changes are in the errata notes) but I
don't believe this is practical for the Project to support.  Errata
updates need to be lightweight from the Project's point of - it can't
afford to spend months testing them.  With the current model, p4 can only
be applied on top of p3 so releasing p4 means:
1) verifying that applying the p4 changes to p3 corrects the bug(s) that
   caused p4 to be created.
2) doing regression tests to ensure that adding the p4 change to p3
   doesn't break anything.

With your model, someone can apply p4 on top of any combination of p0,
p1, p2, p3 - 8 possibilities.  This means there's now 8 times the
effort involved in releasing the errata update and it increases
exponentially with the number of errata.  And it gets more complicated
if more than one update affects the same (or related) areas of code.
(Continue reading)

Permalink | Reply |
headers
Andriy Gapon | 17 Jan 2012 10:47
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

on 17/01/2012 00:28 John Kozubik said the following:
> we going to run RELEASE software ONLY

My opinion: you've put yourself in a box that is not very compatible with the
current FreeBSD release strategy.  With your scale and restrictions you probably
should just use the FreeBSD source and roll your own releases from a stable
branch of interest (including testing, etc).  Or have your own "branch" where
you could cherry-pick interesting changes from any FreeBSD branches.  Tools like
e.g. git and mercurial make it easy.  Of course, this strategy is not as easy as
trying to persuade the rest of FreeBSD community/project/thing to change its
ways, but perhaps a little bit more realistic.  You can bond with similarly
minded organizations to share costs/work/etc.  It's a community-driven project
after all.

--

-- 
Andriy Gapon
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Robert Watson | 18 Jan 2012 12:34
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


On Tue, 17 Jan 2012, Andriy Gapon wrote:

> on 17/01/2012 00:28 John Kozubik said the following:
>> we going to run RELEASE software ONLY
>
> My opinion: you've put yourself in a box that is not very compatible with 
> the current FreeBSD release strategy.  With your scale and restrictions you 
> probably should just use the FreeBSD source and roll your own releases from 
> a stable branch of interest (including testing, etc).  Or have your own 
> "branch" where you could cherry-pick interesting changes from any FreeBSD 
> branches.  Tools like e.g. git and mercurial make it easy.  Of course, this 
> strategy is not as easy as trying to persuade the rest of FreeBSD 
> community/project/thing to change its ways, but perhaps a little bit more 
> realistic.  You can bond with similarly minded organizations to share 
> costs/work/etc.  It's a community-driven project after all.

Suppose for a moment we get the .x release process fixed: we start cutting 
regular point releases from -STABLE on a 6-month cycle (just a strawman). 
freebsd-update's update and upgrade features actually make tracking -STABLE at 
release engineered time slices plausible.

One reason that's true is that between 5.x and 6.x, the FreeBSD Project 
underwent a substantive change in our approach to binary interfaces.  In 4.x 
and before, the letters "ABI" rarely hit the mailing lists.  In 6.x and later, 
it's a key topic discussed whenever merges to -STABLE come up.  We now really 
care about keeping applications running as the OS moves under them.  We also 
build packages to better-defined ABIs -- not perfectly, but OK.

I think John gets a lot of what he wants if we just fix our release cycle.
(Continue reading)

Permalink | Reply |
headers
John Kozubik | 18 Jan 2012 20:18

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


On Wed, 18 Jan 2012, Robert Watson wrote:

>
> I think John gets a lot of what he wants if we just fix our release cycle.
>

Agreed.  I still think that having two "production" releases running 
simultaneously really hurts focus and the end product, but that's not 
going to keep us from using FreeBSD.

Not getting a decent five years out of a major release and not getting a 
minor release every 4-6 months *will* keep us from using FreeBSD.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Ivan Voras | 17 Jan 2012 12:41
Picon
Favicon
Gravatar

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

(answering out of order)

On 16/01/2012 23:28, John Kozubik wrote:

> 2) Having two simultaneous production releases draws focus away from
> both of them, and keeps any release from ever truly maturing.

This isn't how things work. The -CURRENT always has (and probably always 
had and always will have) the focus of developers. The "releases" are 
for many people simply a periodical annoyance due to freezes. In no way 
will reducing the number of "production releases" change this. As a 
volunteer effort, backports to stable branches only happen when 1) it's 
in the interest of the developer, e.g. "I've found a bug on my systems, 
want to get it fixed in -STABLE" and 2) when the developer is budged by 
outside forces (users complaining, other developers requesting it) and 
3) they think it's worth doing and have time to do it spontaneously. 
These are in order of likelihood to happen.

You could say the question is: why is it so, but I think you know the 
answer to that: small project, not enough manpower and volunteer-hours. 
However, the situation is actually quite good because the developers are 
usually very responsive to MFC requests...

> going to
> run RELEASE software ONLY

> 4) New code and fixes that people NEED TODAY just sits on the shelf for
> 8 or 10 or (nowadays) 13 months while end users wait for new minor
> releases.
(Continue reading)

Permalink | Reply |
headers
John Kozubik | 17 Jan 2012 18:52

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


Ivan,

On Tue, 17 Jan 2012, Ivan Voras wrote:

>> 2) Having two simultaneous production releases draws focus away from
>> both of them, and keeps any release from ever truly maturing.
>
> This isn't how things work. The -CURRENT always has (and probably always had 
> and always will have) the focus of developers. The "releases" are for many 
> people simply a periodical annoyance due to freezes. In no way will reducing 
> the number of "production releases" change this. As a volunteer effort, 
> backports to stable branches only happen when 1) it's in the interest of the 
> developer, e.g. "I've found a bug on my systems, want to get it fixed in 
> -STABLE" and 2) when the developer is budged by outside forces (users 
> complaining, other developers requesting it) and 3) they think it's worth 
> doing and have time to do it spontaneously. These are in order of likelihood 
> to happen.

I could not have illustrated my point better, RE: FreeBSD becoming an OS 
by, and for, FreeBSD developers.

I wish I could find the quote - it was from one of the FreeBSD core team 
many years ago, and it was something along the lines of "we are holding 
a piece in one of the highest stakes games in the modern world".  Now 
juxtapose that with "The "releases" are for many people simply a 
periodical annoyance".

>> going to
>> run RELEASE software ONLY
(Continue reading)

Permalink | Reply |
headers
John Baldwin | 18 Jan 2012 14:53
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Tuesday, January 17, 2012 6:41:48 am Ivan Voras wrote:
> (answering out of order)
> 
> On 16/01/2012 23:28, John Kozubik wrote:
> 
> > 2) Having two simultaneous production releases draws focus away from
> > both of them, and keeps any release from ever truly maturing.
> 
> This isn't how things work. The -CURRENT always has (and probably always 
> had and always will have) the focus of developers.

This is not strictly true.  At work we are using 8.2-ish, and so right now
much of development happens on 8 and has to be forward ported to HEAD.  I
do think we are cutting stable branches a bit too often and that we could
merge features back to older branches more aggressively.  SVN had made that
much easier (e.g. merging superpages from 8 back to 7).  However, it is more
work for a developer to merge a change back to 2 or 3 branches (e.g. from
HEAD to 9 to 8 to 7).  Developers are more willing to merge things back to
one or two branches.  Right now we have made a design decision to release
new X.0 releases (and cut new branches) at a certain frequency (and we
aren't even keeping up).  We could choose to alter that design and I think
we would end up with longer-lived stable branches as a result.

--

-- 
John Baldwin
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
(Continue reading)

Permalink | Reply |
headers
Mark Felder | 17 Jan 2012 16:39
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

Why is everyone so afraid of running -STABLE? Plenty of stuff gets MFC'd.  
Yeah, I agree -- running -RELEASE is difficult. Hell, it's frustrating to  
us that VMWare only supports -RELEASE and it took until ESX 5 to  
officially support 8.2!

More releases / snapshots of -STABLE helps people on physical servers, but  
anyone who runs VMs on Xen or VMWare won't get any support for those  
versions because they didn't go through the QA process yet. FreeBSD is  
increasingly becoming a third world citizen thanks to virtualization  
efforts being focused on Linux, so I feel that more frequent releases  
won't help as many people as you think.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Damien Fleuriot | 17 Jan 2012 18:36

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


On 1/17/12 4:39 PM, Mark Felder wrote:
> Why is everyone so afraid of running -STABLE? Plenty of stuff gets
> MFC'd. Yeah, I agree -- running -RELEASE is difficult. Hell, it's
> frustrating to us that VMWare only supports -RELEASE and it took until
> ESX 5 to officially support 8.2!
> 
> More releases / snapshots of -STABLE helps people on physical servers,
> but anyone who runs VMs on Xen or VMWare won't get any support for those
> versions because they didn't go through the QA process yet. FreeBSD is
> increasingly becoming a third world citizen thanks to virtualization
> efforts being focused on Linux, so I feel that more frequent releases
> won't help as many people as you think.
>

Running FBSD in a *production* environment means you want something
stable and tested.

-STABLE does not fulfill the requirements I'm afraid.

We've had to downgrade some boxes from 8.2-STABLE to -RELEASE here.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Julian Elischer | 17 Jan 2012 19:59
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 1/17/12 9:36 AM, Damien Fleuriot wrote:
>
> On 1/17/12 4:39 PM, Mark Felder wrote:
>> Why is everyone so afraid of running -STABLE? Plenty of stuff gets
>> MFC'd. Yeah, I agree -- running -RELEASE is difficult. Hell, it's
>> frustrating to us that VMWare only supports -RELEASE and it took until
>> ESX 5 to officially support 8.2!
>>
>> More releases / snapshots of -STABLE helps people on physical servers,
>> but anyone who runs VMs on Xen or VMWare won't get any support for those
>> versions because they didn't go through the QA process yet. FreeBSD is
>> increasingly becoming a third world citizen thanks to virtualization
>> efforts being focused on Linux, so I feel that more frequent releases
>> won't help as many people as you think.
>>
> Running FBSD in a *production* environment means you want something
> stable and tested.
>
> -STABLE does not fulfill the requirements I'm afraid.
>
> We've had to downgrade some boxes from 8.2-STABLE to -RELEASE here.

then you went the wrong way
and your process is flawed.

having run -stable on production systems, the way to do it is:

* follow -stable..
* pick a time that IN RETROSPECT (from 1 month later) looks as though 
it was good.
(Continue reading)

Permalink | Reply |
headers
Mark Saad | 17 Jan 2012 21:11

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

Here are My 2 Cents ,

1. Support each release longer, or develop a better way to MFS ( Merge
from Stable ) bug fixes, and driver updates to RELEASE. It always
seams that there are a number of things in X-STABLE I would love to
have in X.3-RELEASE and X.4-RELEASE, and I do not want all of X-STABLE
just some new drivers and fixes  .

2. Spell out the entire RELEASE road map at the beginning of the
release. So for 9.0-RELEASE set tentative dates for 9.1, 9.2, 9.x etc
.

--

-- 
mark saad | nonesuch <at> longcount.org
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Julian Elischer | 18 Jan 2012 03:28
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 1/17/12 12:11 PM, Mark Saad wrote:
> Here are My 2 Cents ,
>
> 1. Support each release longer, or develop a better way to MFS ( Merge
> from Stable ) bug fixes, and driver updates to RELEASE. It always
> seams that there are a number of things in X-STABLE I would love to
> have in X.3-RELEASE and X.4-RELEASE, and I do not want all of X-STABLE
> just some new drivers and fixes  .
>
> 2. Spell out the entire RELEASE road map at the beginning of the
> release. So for 9.0-RELEASE set tentative dates for 9.1, 9.2, 9.x etc
> .

I think by the ".2" release of a line we should have some idea
as to whether a particular lineage is going to provide a good basis 
for extended life.

if for example we were to declare that 8 is really quite good,
we might decide to declare it as having a longer life and allow 9 to 
die earlier as we go forward.
I  do understand the requirement for a stable basis for work but I
can not say how many of the changes for newer hardware will get ported 
back. or by who.

>

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
(Continue reading)

Permalink | Reply |
headers
Mark Felder | 17 Jan 2012 21:50
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Tue, 17 Jan 2012 12:59:44 -0600, Julian Elischer <julian <at> freebsd.org>  
wrote:

> On 1/17/12 9:36 AM, Damien Fleuriot wrote:
>
> having run -stable on production systems, the way to do it is:
>
> * follow -stable..
> * pick a time that IN RETROSPECT (from 1 month later) looks as though it  
> was good.
> * take a snapshot from that time and test it.
> * if it has problems MOVE FORWARD (not back) to the next candidate  
> snapshot time.
> * repeat until you have one that works for you
>

This is also the way I've had it explained to me. Note, I'm currently not  
running anything -STABLE in production right now simply because I don't  
have that need. I did for a while last year, but not now.

I'm deploying two ZFS SANs based on 9 early February. It might be on  
-RELEASE with manual backports of the gmultipath rewrite (required) and  
also I am considering the fixes for CDROM access (CAM stuff). I've seen  
several other things hit -STABLE right after the freeze ended early  
January which surprise me that they weren't included in -RELEASE and we  
didn't have another RC. I definitely see the frustration being expressed  
here, but I personally am comfortable running -STABLE. Many people are not  
and it is unfortunate that they will be left waiting until 9.1-RELEASE  
(probably late summer?). I hope a compromise will be found. I'm clearly in  
the minority that is OK with the current situation.
(Continue reading)

Permalink | Reply |
headers
Matthew D. Fuller | 17 Jan 2012 23:25

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Tue, Jan 17, 2012 at 02:50:08PM -0600 I heard the voice of
Mark Felder, and lo! it spake thus:
> 
> I've seen  several other things hit -STABLE right after the freeze
> ended early  January which surprise me that they weren't included in
> -RELEASE and we  didn't have another RC.

You mean the 9.0-RELEASE that's scheduled to be done (after having
already slipped a month) at the beginning of Sept 2011?  At some point
(well before those add'l patches you're talking about, IMO) you have
to STOP and release the damn thing already.

--

-- 
Matthew Fuller     (MF4839)   |  fullermd <at> over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Mark Felder | 18 Jan 2012 00:55
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Tue, 17 Jan 2012 16:25:12 -0600, Matthew D. Fuller  
<fullermd <at> over-yonder.net> wrote:

> On Tue, Jan 17, 2012 at 02:50:08PM -0600 I heard the voice of
> Mark Felder, and lo! it spake thus:
>>
>> I've seen  several other things hit -STABLE right after the freeze
>> ended early  January which surprise me that they weren't included in
>> -RELEASE and we  didn't have another RC.
>
> You mean the 9.0-RELEASE that's scheduled to be done (after having
> already slipped a month) at the beginning of Sept 2011?  At some point
> (well before those add'l patches you're talking about, IMO) you have
> to STOP and release the damn thing already.
>
>

Yeah, but how much sense does it make to do a -RELEASE with critical bugs?  
For example, gmultipath guarantees a panic on various hardware just by  
breaking a path. This was fixed in a full rewrite discussed this summer  
and publicized in November. Now anyone with shiny 9.0 (or even 8.2)  
running gmultipath risks a panic. The fix IS the rewrite. But it's s total  
rewrite and so patching that onto 9.0 as errata doesn't really make sense  
(rewrite adds features too), so now the choices for a stable gmultipath is  
-STABLE or patiently waiting for 9.1.

So yeah, 9.0 slipped hard. Perhaps it should have slipped a bit further  
until blockers like gmultipath and the cdrom/CAM stuff were fully  
addressed. But it's impossible to release 100% bug free software.... where  
exactly *do* you draw the line? :-/
(Continue reading)

Permalink | Reply |
headers
Atom Smasher | 17 Jan 2012 22:07
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Tue, 17 Jan 2012, Mark Felder wrote:

> To be fair, it could be worse -- OpenBSD secretly wants you to run 
> snapshots and CURRENT as the RELEASEs are mostly unmaintained outside of 
> the most extreme security concerns. Even the packages are kept at the 
> exact version of the time of release.
=============

and how many corps are running openBSD? talk about an OS that seems to 
exist only as a playground for its developers...

--

-- 
         ...atom

  ________________________
  http://atom.smasher.org/
  762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
  -------------------------------------------------

 	"All censorships exist to prevent anyone from challenging
 	 current conceptions and existing institutions. All progress
 	 is initiated by challenging current conceptions, and executed
 	 by supplanting existing institutions. Consequently, the first
 	 condition of progress is the removal of censorships."
 		-- George Bernard Shaw

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
(Continue reading)

Permalink | Reply |
headers
richo | 18 Jan 2012 05:16
Favicon
Gravatar

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 18/01/12 10:07 +1300, Atom Smasher wrote:
>On Tue, 17 Jan 2012, Mark Felder wrote:
>
>>To be fair, it could be worse -- OpenBSD secretly wants you to run
>>snapshots and CURRENT as the RELEASEs are mostly unmaintained
>>outside of the most extreme security concerns. Even the packages
>>are kept at the exact version of the time of release.
>=============
>
>and how many corps are running openBSD? talk about an OS that seems
>to exist only as a playground for its developers...
>

This is more or less like Debian in regards to their packaging.

Admittedly, OpenBSD is way up there on the paranoia scale, but I know of
plenty of big companies running OpenBSD on large scale routing
infrastructure.

--
richo || Today's excuse:

Your Pentium has a heating problem - try cooling it with ice cold
water.(Do not turn off your computer, you do not want to cool down the
Pentium Chip while he isn't working, do you?)
http://blog.psych0tik.net
Permalink | Reply |
headers
Mark Felder | 18 Jan 2012 05:16
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Tue, 17 Jan 2012 15:07:56 -0600, Atom Smasher <atom <at> smasher.org> wrote:

> and how many corps are running openBSD?

Works amazingly well as an edge router. You get pf, openbgpd, openspfd....  
much higher performance that 50K cisco gear. The bugs we've hit have been  
fixed promptly as well. Pretty decent little setup for a budget. But yeah,  
not many do what we do.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Igor Mozolevsky | 17 Jan 2012 18:48
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 17 January 2012 15:39, Mark Felder <feld <at> feld.me> wrote:

> FreeBSD is increasingly becoming a third world citizen thanks to
> virtualization efforts being focused on Linux, so I feel that more
> frequent releases won't help as many people as you think.

I would guess that for folks like VMWare, the choice of their focus is
essentially determined by their customers and not by them themselves.
So if VMWare choose to focus more on Linux over FreeBSD it is simply
indicative that VMWare's customers demand Linux support more that the
FreeBSD one... Now, why is there more end-user demand for Linux than
FreeBSD? I am guessing that is exactly what John K's original post was
trying to address...

--
Igor M. :-)
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
John Kozubik | 17 Jan 2012 19:12

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


On Tue, 17 Jan 2012, Mark Felder wrote:

> Why is everyone so afraid of running -STABLE? Plenty of stuff gets MFC'd. 
> Yeah, I agree -- running -RELEASE is difficult. Hell, it's frustrating to us 
> that VMWare only supports -RELEASE and it took until ESX 5 to officially 
> support 8.2!
>
> More releases / snapshots of -STABLE helps people on physical servers, but 
> anyone who runs VMs on Xen or VMWare won't get any support for those versions 
> because they didn't go through the QA process yet. FreeBSD is increasingly 
> becoming a third world citizen thanks to virtualization efforts being focused 
> on Linux, so I feel that more frequent releases won't help as many people as 
> you think.

Again, I'm not suggesting more snapshots - I am suggesting more real, bona 
fide releases.  This will help people.

The fact that vmware only works with release software is consistent with 
my own assertions.  They (we) don't care what fancy toolchain and build 
environments you have - we need things that we can defend to customers, 
stockholders, judges, juries, etc.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Warner Losh | 17 Jan 2012 22:09

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


On Jan 17, 2012, at 11:12 AM, John Kozubik wrote:
> Again, I'm not suggesting more snapshots - I am suggesting more real, bona fide releases.  This will help people.

I tend to agree with you.  Our release engineering process isn't serving the needs of users as much as it once
did.  When Walnut Creek was running release engineering, we had releases often because they wanted to make
money from their subscriptions.  This produced reasonably spaced minor releases and except for 4-5,
decently spaced major releases.  Even after the torch passed from walnut creek to others, there was still
either residual pressures to make the releases happen, or inherited mindset that keep on the same pace.

Today we have lost our way.  We have no major vendor pushing the process along to make it happen faster.  We have
no reason to get things done faster or differently than the volunteers are doing it.  So we're languishing. 
9.0 took forever to get out, and we didn't do stop-gap 8.x releases.  Our port collection has also gotten
bigger since those by-gone days so doing a release of the whole ports tree is taking longer to QA, so
pressure to do it more often meets up with resource constraints.  Our binary update tools lag considerably
compared to Linux, and there's a big reluctance to whole-heartedly embrace PBI as a possible solution. 
Maybe pkgng will help there.  Maybe the various attempts to get ABI stability to allow for easier
decoupling of FreeBSD base and FreeBSD ports releases.

But we have a real problem here.  One I don't have easy answers for how to solve.  One that likely has many other
root-causes than the few I've cherry picked for this reply.  The underlying balances that allowed the
early project to succeed have shifted, but we've not shifted with them.

Warner

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
(Continue reading)

Permalink | Reply |
headers
Mark Blackman | 17 Jan 2012 22:27

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 17 Jan 2012, at 21:09, Warner Losh wrote:

> 
> On Jan 17, 2012, at 11:12 AM, John Kozubik wrote:
>> Again, I'm not suggesting more snapshots - I am suggesting more real, bona fide releases.  This will help people.
> 
> I tend to agree with you.  Our release engineering process isn't serving the needs of users as much as it once
did.  When Walnut Creek was running release engineering, we had releases often because they wanted to make
money from their subscriptions.  This produced reasonably spaced minor releases and except for 4-5,
decently spaced major releases.  Even after the torch passed from walnut creek to others, there was still
either residual pressures to make the releases happen, or inherited mindset that keep on the same pace.
> 
> Today we have lost our way.  We have no major vendor pushing the process along to make it happen faster. 

What exactly did the major vendor to push things along? Keep nagging?

I'd have thought PC-BSD and iXsystems are the natural people to to take over that role in any
case.   The FreeBSD foundation seems  less interested in the "for end-users" angle as well.

- Mark_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Matt Olander | 17 Jan 2012 22:55
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Tue, Jan 17, 2012 at 1:27 PM, Mark Blackman <mark <at> exonetric.com> wrote:
> On 17 Jan 2012, at 21:09, Warner Losh wrote:
>
>>
>> On Jan 17, 2012, at 11:12 AM, John Kozubik wrote:
>>> Again, I'm not suggesting more snapshots - I am suggesting more real, bona fide releases.  This will
help people.
>>
>> I tend to agree with you.  Our release engineering process isn't serving the needs of users as much as it
once did.  When Walnut Creek was running release engineering, we had releases often because they wanted
to make money from their subscriptions.  This produced reasonably spaced minor releases and except for
4-5, decently spaced major releases.  Even after the torch passed from walnut creek to others, there was
still either residual pressures to make the releases happen, or inherited mindset that keep on the same pace.
>>
>> Today we have lost our way.  We have no major vendor pushing the process along to make it happen faster.
>
> What exactly did the major vendor to push things along? Keep nagging?
>
> I'd have thought PC-BSD and iXsystems are the natural people to to take over that role in any
> case.   The FreeBSD foundation seems  less interested in the "for end-users" angle as well.

We'd be happy to sponsor a full-time employee at the Mall to handle
rolling -STABLE into release a few more times per year. We might need
a bit of help maintaining a long term release but we think it's a
pretty good idea all the way around.

Cheers,
-matt
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
(Continue reading)

Permalink | Reply |
headers
Mike Meyer | 17 Jan 2012 23:28
Gravatar

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Tue, 17 Jan 2012 21:27:24 +0000
Mark Blackman <mark <at> exonetric.com> wrote:
> I'd have thought PC-BSD and iXsystems are the natural people to to
> take over that role in any case.   The FreeBSD foundation seems  less
> interested in the "for end-users" angle as well.

If that's the case, is there any reason for cutting "FreeBSD"
releases?

No, I'm serious. If FreeBSD is being run by developers for developers
(first rule of organizations: they're run for the benefit of the
people who run them), how do they benefit from a release? If users
move to some other organizations releases, and the developers don't
get any benefit from them, why do them?

On a less radical note, how about taking in the resources suggested
for the "sponsored branch", and using those to reorganize and expand
the role of release engineering?  Maybe get help from PC-BSD and
iXsystems as well?

Make STABLE the "sponsored" branch owned by the expanded RE group. To
justify this, change it to an "always production ready" approach. Set
up a CI system to test it regularly, and back out changes that break
the build or tests. This does *not* include testing ports or anything
else outside the base system.

RELEASES become a snapshot of the new "always production ready" STABLE
that has ports (and anything else included that's outside the base
system) built for it and tested on it. The goal is that doing the work
to keep STABLE production ready will significantly decrease the amount
(Continue reading)

Permalink | Reply |
headers
Julian Elischer | 17 Jan 2012 19:56
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 1/17/12 7:39 AM, Mark Felder wrote:
> Why is everyone so afraid of running -STABLE? Plenty of stuff gets 
> MFC'd. Yeah, I agree -- running -RELEASE is difficult. Hell, it's 
> frustrating to us that VMWare only supports -RELEASE and it took 
> until ESX 5 to officially support 8.2!
>
> More releases / snapshots of -STABLE helps people on physical 
> servers, but anyone who runs VMs on Xen or VMWare won't get any 
> support for those versions because they didn't go through the QA 
> process yet. FreeBSD is increasingly becoming a third world citizen 
> thanks to virtualization efforts being focused on Linux, so I feel 
> that more frequent releases won't help as many people as you think.

I'm going to go both ways on this one.

Where I used to work (Devin Teske is now there)  we used to use
the 'stable' branch and rolll our own releases.
the criticality of those systems was hard to over-emphasize. In 2005 
we worked
out we processed 1.5 trillion dollars of transactions on those systems.

The other side of the coin is that we had the resources to have 
someone (me)
tracking the branch. I only spun a release when I thought it was a 
good time to
do so, but I always had a year or so advance warning of when a new 
release was
likely to be needed so I could select a good moment from over a wide 
range.
Also ran a layer on the top of the sources where I could  add
(Continue reading)

Permalink | Reply |
headers
Ian Lepore | 17 Jan 2012 22:46
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Tue, 2012-01-17 at 10:56 -0800, Julian Elischer wrote:
> If it came to that maybe all the people who are currently saying they 
> need better
> support of the 8.x branch could get together and together, support 
> someone
> to do that job for them..would 1/5th of  a person be too expensive
> for 
> them?
> 
> if not, what is a reasonable cost?  Is it worth 1/20 th of a person?
> 
> 
> Julian
> 

I've got to say, this strikes me as the most interesting idea floated so
far in this conversation.  I've heard of many instances of sponsored
projects; they almost always involve major new features or support for
new hardware or technologies; paying someone for a specific small
focused fix is also common.  

A sponsored branch is... well... just an interesting concept to me. 

Unlike most developers, I have little interest in creating new code from
scratch to implement the fad of the week.  (There's that whole other
opensource OS if fad of the week technology is your thing.)  I live to
find and fix bugs.  Sometimes that means days of frustration to generate
a one-line patch.  Sometimes you find the problem in minutes but the fix
means a painful redesign that touches 342 files and has the potential to
ruin everyone's day when you get it wrong.  But, for me at least, it's
(Continue reading)

Permalink | Reply |
headers
Andriy Gapon | 18 Jan 2012 00:17
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

on 17/01/2012 23:46 Ian Lepore said the following:
> Now, before we're even really completely up and running on 8.2 at work,
> 9.0 hits the street, and developers have moved on to working in the 10.0
> world.  What are the chances that any of the patches I've submitted for
> bugs we fixed in 8.x are ever going to get commited now that 8 is well
> on its way to becoming ancient history in developers' minds?

My opinion is that this will have more to do with your approach to pushing the
patches (and your persistence) rather than with anything else.  As long as
stable/8 is still a supported branch or the bugs are reproducible in any of the
supported branches.

--

-- 
Andriy Gapon
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Ian Lepore | 18 Jan 2012 00:36
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Wed, 2012-01-18 at 01:17 +0200, Andriy Gapon wrote:
> on 17/01/2012 23:46 Ian Lepore said the following:
> > Now, before we're even really completely up and running on 8.2 at work,
> > 9.0 hits the street, and developers have moved on to working in the 10.0
> > world.  What are the chances that any of the patches I've submitted for
> > bugs we fixed in 8.x are ever going to get commited now that 8 is well
> > on its way to becoming ancient history in developers' minds?
> 
> My opinion is that this will have more to do with your approach to pushing the
> patches (and your persistence) rather than with anything else.  As long as
> stable/8 is still a supported branch or the bugs are reproducible in any of the
> supported branches.

Well I submitted a sort of random sample of the patches we're
maintaining at work, 11 of them as formal PRs and 2 posted to the lists
here recently.  So far two have been committed (the most important one
and the most trivial one, oddly enough).  I'm not sure just how pushy
one is supposed to be, I don't want to be a jerk.  Not to mention that I
wouldn't know who to push.  That's actually why I'm now being active on
the mailing lists, I figured maybe patches will be more accepted from
someone the commiters know rather than just as code out of the blue
attached to a PR.

I think it would be great if there were some developers (a team, maybe
something not quite that formal) who concentrated on maintenance of
older code for the user base who needs it.  I'd be happy to contribute
to that effort, both on my own time, and I have a commitment from
management at work to allow me a certain amount of billable work hours
to interface with the FreeBSD community, especially in terms of getting
our work contributed back to the project (both to help the project, and
(Continue reading)

Permalink | Reply |
headers
Andriy Gapon | 18 Jan 2012 01:00
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

on 18/01/2012 01:36 Ian Lepore said the following:
> On Wed, 2012-01-18 at 01:17 +0200, Andriy Gapon wrote:
>> on 17/01/2012 23:46 Ian Lepore said the following:
>>> Now, before we're even really completely up and running on 8.2 at work,
>>> 9.0 hits the street, and developers have moved on to working in the 10.0
>>> world.  What are the chances that any of the patches I've submitted for
>>> bugs we fixed in 8.x are ever going to get commited now that 8 is well
>>> on its way to becoming ancient history in developers' minds?
>>
>> My opinion is that this will have more to do with your approach to pushing the
>> patches (and your persistence) rather than with anything else.  As long as
>> stable/8 is still a supported branch or the bugs are reproducible in any of the
>> supported branches.
> 
> Well I submitted a sort of random sample of the patches we're
> maintaining at work, 11 of them as formal PRs and 2 posted to the lists
> here recently.

Just a note: the next best thing you can to _not_ have a patch committed is to
just open a PR and stop at that.  The best thing being not sharing the patch at
all :-)

> So far two have been committed (the most important one
> and the most trivial one, oddly enough).  I'm not sure just how pushy
> one is supposed to be, I don't want to be a jerk.

Some things that help:
- send a problem description and a patch (or a short description and a link to a
PR) to a relevant mailing list
- maintain a discussion of the patch if it arises
(Continue reading)

Permalink | Reply |
headers
Igor Mozolevsky | 18 Jan 2012 01:16
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 18 January 2012 00:00, Andriy Gapon <avg <at> freebsd.org> wrote:

> Just a note: the next best thing you can to _not_ have a patch committed is to
> just open a PR and stop at that.  The best thing being not sharing the patch at
> all :-)

[snip]

> Some things that help:
> - send a problem description and a patch (or a short description and a link to a
> PR) to a relevant mailing list
> - maintain a discussion of the patch if it arises
> - try to be interesting and keep the interested folks hooked
> - find some folks who recently committed stuff in the area of the patch and
> contact them directly
> - don't just wait for too long, remind about yourself and the patch, try
> different mailing lists/people
> - never give up
> - stay technical, never get bitter or overly emotional
> - don't refuse when offered a commit bit :-)

Seriously, WTF is the point of having a PR system that allows patches
to be submitted??! When I submit a patch I fix *your* code (not yours
personally, but you get my gist). No other project requires a
non-committer to be so ridiculously persistent in order to get a patch
through.

Such system is plainly wrong---it simply discourages people from
sending "this works for me"(TM) fixes. The committers have to realise
three things: they can and do write broken code now and then, most
(Continue reading)

Permalink | Reply |
headers
Eitan Adler | 18 Jan 2012 02:11
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Tue, Jan 17, 2012 at 7:16 PM, Igor Mozolevsky <igor <at> hybrid-lab.co.uk> wrote:

> Seriously, WTF is the point of having a PR system that allows patches
> to be submitted??! When I submit a patch I fix *your* code (not yours
> personally, but you get my gist). No other project requires a
> non-committer to be so ridiculously persistent in order to get a patch
> through.

It takes time to review and test patches. There are a lot of people
that think "it only takes 30 seconds to download the patch, apply, and
commit."  This is just not true.

When I take PRs committers
1) Download the PR
2) Read the surrounding code sufficiently to understand what it does
3) Read the patched code to find the bug
4) Read the patch to see if it fixes the bug
5) Ensure that it is the most appropriate way to fix the bug
6) Apply the patch and test the affected issue.
7) Find the person who wrote the original code (or at least one other
person) and have them review it
    - this person usually goes through steps 1-6 too.
8) Apply the patch to head and commit
9) Verify the changes are correct didn't cause any regressions
10) MFC to stable[789]

And this assumes the patch was perfect, there really was a bug, and
everyone thinks things through properly.  The process take anywhere
from half an hour for obvious fixes to multiple days  in addition to
the committer's work, school, and family obligations..
(Continue reading)

Permalink | Reply |
headers
Igor Mozolevsky | 18 Jan 2012 02:41
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 18 January 2012 01:11, Eitan Adler <lists <at> eitanadler.com> wrote:

> It takes time to review and test patches. There are a lot of people
> that think "it only takes 30 seconds to download the patch, apply, and
> commit."  This is just not true.

I fully understand that and it is not what I was saying, what I was
saying was about the patches that were being plainly ignored/allowed
to go stale. What you said below is perfectly reasonable once a
committer is actively involved in dealing with a patch, then I, and
anyone else for that matter, would be very reasonably expected to be
involved in the process and understands that someone else is working
on the issue you've address. The problem, however, lies in the time
between a patch is submitted and is "picked up", if the latter ever
occurs!.. That is where the discouragement occurs.

[snip]

> And this assumes the patch was perfect, there really was a bug, and
> everyone thinks things through properly.  The process take anywhere
> from half an hour for obvious fixes to multiple days  in addition to
> the committer's work, school, and family obligations..

I hope I've address what you say here just above :-) and
wholeheartedly agree with everything else you've said, but you are
addressing the problem from a different angle: nobody is ever going to
disagree that _once_ someone has picked up a patch it will take them
time to get it through whatever steps necessary. But, as I said above,
it's getting to *this* stage that is the lengthy and a disheartening
process...
(Continue reading)

Permalink | Reply |
headers
Matthew D. Fuller | 18 Jan 2012 03:48

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Wed, Jan 18, 2012 at 01:41:53AM +0000 I heard the voice of
Igor Mozolevsky, and lo! it spake thus:
> 
> The problem, however, lies in the time between a patch is submitted
> and is "picked up", if the latter ever occurs!.. That is where the
> discouragement occurs.

Quite.  For instance, we're now well past the 3 year mark since I
submitted docs/127908, which fixes 1 sentence in a manpage.  So far, I
can't see that anybody but me has ever looked at it.  That doesn't
serve to encourage me to nibble at anything substantial.

(In fairness, I should note that I also maintain several ports, and so
submit a steady trickle of PR's there.  Almost none of them take more
than a week from submission to application and closing, and it's
fairly common for it to be less than 24 hours.  I know the ports team
carries a huge load with such things, but they're carrying it well.)

--

-- 
Matthew Fuller     (MF4839)   |  fullermd <at> over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Eitan Adler | 18 Jan 2012 14:11
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Tue, Jan 17, 2012 at 8:41 PM, Igor Mozolevsky <igor <at> hybrid-lab.co.uk> wrote:
> On 18 January 2012 01:11, Eitan Adler <lists <at> eitanadler.com> wrote:
>
>> It takes time to review and test patches. There are a lot of people
>> that think "it only takes 30 seconds to download the patch, apply, and
>> commit."  This is just not true.
>
> I fully understand that and it is not what I was saying, what I was
> saying was about the patches that were being plainly ignored/allowed
> to go stale. What you said below is perfectly reasonable once a
> committer is actively involved in dealing with a patch, then I, and
> anyone else for that matter, would be very reasonably expected to be
> involved in the process and understands that someone else is working
> on the issue you've address.

Often times people don't do this part and submit a "drive by patch."
Nothing is wrong with that, but it does make it harder to verify that
a fix is correct (especially for hardware support PRs).

> The problem, however, lies in the time
> between a patch is submitted and is "picked up", if the latter ever
> occurs!.. That is where the discouragement occurs.

I guess I didn't follow through on all the above. My point was that
who wants to spend 3, 4, 7, 10 hours fixing a bug report when they can
be working on a shiny new feature (or play games, or anything else but
work!)?

> I hope I've address what you say here just above :-) and
> wholeheartedly agree with everything else you've said, but you are
(Continue reading)

Permalink | Reply |
headers
Igor Mozolevsky | 18 Jan 2012 14:31
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 18 January 2012 13:11, Eitan Adler <lists <at> eitanadler.com> wrote:
> On Tue, Jan 17, 2012 at 8:41 PM, Igor Mozolevsky <igor <at> hybrid-lab.co.uk> wrote:

>> One way to
>> "encourage" people to fix their code would be to prevent them from
>> committing to -CURRENT once they pass a certain threshold of
>> "unattended" patches. Of course then, committers will be whinging that
>> they'd be resigning if they can't commit to -CURRENT, but quite
>> frankly, why should anyone have the commit privilege if they can't be
>> bothered to address the bugs, are those people just using the FreeBSD
>> project to boost their CV (with great powers comes great
>> responsibility!)?
>
> Wouldn't this discourage even more people from helping?

Would this not separate people who have a genuine interest in
contributing from "tinker-monkeys"?

--
Igor M. :-)
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Robert Huff | 19 Jan 2012 17:35
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


Igor Mozolevsky writes:

>  > Wouldn't this discourage even more people from helping?
>  
>  Would this not separate people who have a genuine interest in
>  contributing from "tinker-monkeys"?

	Did I miss a previous definition of "tinker-monkey"?

				Robert Huff

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Mark Saad | 19 Jan 2012 18:47

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

I just want to chime in here, what is the deal with killing off a
potential 7.5-RELEASE ? Having a few  7.3-RELEASE and 7.4-RELEASE
servers  I would like to see a 7.5-RELEASE that is supported to 2015
to prevent another major upgrade cycle . There are still freebsd
developers working on 7-STABLE and its been reliable and working for
me and I am sure a few other people.

What could I do to help make 7.5-RELEASE a reality ?

--

-- 
mark saad | nonesuch <at> longcount.org
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Adrian Chadd | 19 Jan 2012 22:33
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 19 January 2012 09:47, Mark Saad <nonesuch <at> longcount.org> wrote:

> I just want to chime in here, what is the deal with killing off a
> potential 7.5-RELEASE ? Having a few  7.3-RELEASE and 7.4-RELEASE
> servers  I would like to see a 7.5-RELEASE that is supported to 2015
> to prevent another major upgrade cycle . There are still freebsd
> developers working on 7-STABLE and its been reliable and working for
> me and I am sure a few other people.
>
> What could I do to help make 7.5-RELEASE a reality ?
>

Put your hand up and volunteer to run the 7.5-RELEASE release cycle.

Adrian
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
John Baldwin | 26 Jan 2012 15:37
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Thursday, January 19, 2012 4:33:40 pm Adrian Chadd wrote:
> On 19 January 2012 09:47, Mark Saad <nonesuch <at> longcount.org> wrote:
> 
> > I just want to chime in here, what is the deal with killing off a
> > potential 7.5-RELEASE ? Having a few  7.3-RELEASE and 7.4-RELEASE
> > servers  I would like to see a 7.5-RELEASE that is supported to 2015
> > to prevent another major upgrade cycle . There are still freebsd
> > developers working on 7-STABLE and its been reliable and working for
> > me and I am sure a few other people.
> >
> > What could I do to help make 7.5-RELEASE a reality ?
> >
> 
> Put your hand up and volunteer to run the 7.5-RELEASE release cycle.

That's not actually true or really fair.  There has to be some buy-in from the 
project to do an official release; it is not something that a single person
can do off in a corner and then have the Project bless the bits as an official 
release.

--

-- 
John Baldwin
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Mark Blackman | 26 Jan 2012 17:49

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


On 26 Jan 2012, at 14:37, John Baldwin wrote:

> On Thursday, January 19, 2012 4:33:40 pm Adrian Chadd wrote:
>> On 19 January 2012 09:47, Mark Saad <nonesuch <at> longcount.org> wrote:
>>> 
>>> 
>>> What could I do to help make 7.5-RELEASE a reality ?
>>> 
>> 
>> Put your hand up and volunteer to run the 7.5-RELEASE release cycle.
> 
> That's not actually true or really fair.  There has to be some buy-in from the 
> project to do an official release; it is not something that a single person
> can do off in a corner and then have the Project bless the bits as an official 
> release.

And raises the interesting question for an outsider of 

a) who is "the project" in this case
and
b) what does it take for a release to be a release?

Wasn't there a freebsd-releng (or similar) mailing list ages ago?

I didn't spot an active one at http://docs.freebsd.org/mail/

- Mark_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
(Continue reading)

Permalink | Reply |
headers
John Baldwin | 26 Jan 2012 19:22
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Thursday, January 26, 2012 11:49:22 am Mark Blackman wrote:
> 
> On 26 Jan 2012, at 14:37, John Baldwin wrote:
> 
> > On Thursday, January 19, 2012 4:33:40 pm Adrian Chadd wrote:
> >> On 19 January 2012 09:47, Mark Saad <nonesuch <at> longcount.org> wrote:
> >>> 
> >>> 
> >>> What could I do to help make 7.5-RELEASE a reality ?
> >>> 
> >> 
> >> Put your hand up and volunteer to run the 7.5-RELEASE release cycle.
> > 
> > That's not actually true or really fair.  There has to be some buy-in from the 
> > project to do an official release; it is not something that a single person
> > can do off in a corner and then have the Project bless the bits as an official 
> > release.
> 
> And raises the interesting question for an outsider of 
> 
> a) who is "the project" in this case
> and
> b) what does it take for a release to be a release?

I'll answer the two together.  The project is the entity that "owns"
freebsd.org and a release is not a release unless it is present on
ftp.freebsd.org and has a signed announcement e-mail with hashes, etc.
on the freebsd-announce <at>  mailing list.  Without those things there is
no reason for a user to believe that a particular set of bits is a
legitimate FreeBSD release.  Additionally, a release should be available
(Continue reading)

Permalink | Reply |
headers
Mark Blackman | 26 Jan 2012 23:23

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


On 26 Jan 2012, at 18:22, John Baldwin wrote:

> On Thursday, January 26, 2012 11:49:22 am Mark Blackman wrote:
>> a) who is "the project" in this case
>> and
>> b) what does it take for a release to be a release?
> 
> I'll answer the two together.  The project is the entity that "owns"
> freebsd.org and a release is not a release unless it is present on
> ftp.freebsd.org and has a signed announcement e-mail with hashes, etc.
> on the freebsd-announce <at>  mailing list.  Without those things there is
> no reason for a user to believe that a particular set of bits is a
> legitimate FreeBSD release.  Additionally, a release should be available
> via the appropriate tags in the CVS and SVN repositories available from
> freebsd.org machines.

Thanks. I wonder who that "entity" is? Everyone with a commit bit,
or perhaps just the RE team? Anyway, it's not very important in this
context.

I also tracked this down, but might be out of date.

http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/release-proc.html

"New releases of FreeBSD are released from the -STABLE branch at approximately four month intervals."

To be honest, I'm sure we all agree this sort of discussion is not useful on hackers 
and obviously at some point needs to turn into work rather than points of view. Mostly it just
boils down, "lets see if we can do -STABLE point releases a bit more frequently".
(Continue reading)

Permalink | Reply |
headers
Mark Linimon | 26 Jan 2012 23:49

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Thu, Jan 26, 2012 at 10:23:43PM +0000, Mark Blackman wrote:
> http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/release-proc.html
> 
> "New releases of FreeBSD are released from the -STABLE branch at
> approximately four month intervals."

That was our intention at one point.  Obviously we've not stuck to that.
(IMHO doing releases quite that frequently is probably beyond what we can
do with volunteer staffing, but I'm not on re <at>  so take it as you will.)

In any case, various people within the project have now absorbed the
lesson that "10 months between releases is too long", and are trying to
figure out what to do about it.

mcl
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Mark Blackman | 26 Jan 2012 23:52

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 26 Jan 2012, at 22:49, Mark Linimon wrote:

> On Thu, Jan 26, 2012 at 10:23:43PM +0000, Mark Blackman wrote:
>> http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/release-proc.html
>> 
>> "New releases of FreeBSD are released from the -STABLE branch at
>> approximately four month intervals."
> 
> That was our intention at one point.  Obviously we've not stuck to that.
> (IMHO doing releases quite that frequently is probably beyond what we can
> do with volunteer staffing, but I'm not on re <at>  so take it as you will.)
> 
> In any case, various people within the project have now absorbed the
> lesson that "10 months between releases is too long", and are trying to
> figure out what to do about it.

Indeed, I was just reviewing the last couple of years of release and the thing
that struck me was the number of BETAs and RCs for each point release.

I suspect poor old RE is putting too much work into BETAs and RCs for
point releases. 

- Mark_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Mark Linimon | 27 Jan 2012 04:26

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Thu, Jan 26, 2012 at 10:52:44PM +0000, Mark Blackman wrote:
> I suspect poor old RE is putting too much work into BETAs and RCs for
> point releases. 

The counter-argument is that we have a lot more leeway to make mistakes
on a .0 release.  We're not going to be cut any slack at all for shipping
a badly regressed point release.

Some minor regressions are inevitable in software, but they do indeed
need to be minor.

For how we're doing with regressions in general, see:

  http://people.freebsd.org/~linimon/studies/prs/prs_for_tag_regression.html

Now, it's true that many of the recent PRs are against 9.0, and many of
the ones that aren't may be stale (certainly most of the pre-2010 ones),
but these are the types of things that users really notice and become
unhappy about.

mcl
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Mark Blackman | 27 Jan 2012 13:01

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


On 27 Jan 2012, at 03:26, Mark Linimon wrote:

> On Thu, Jan 26, 2012 at 10:52:44PM +0000, Mark Blackman wrote:
>> I suspect poor old RE is putting too much work into BETAs and RCs for
>> point releases. 
> 
> The counter-argument is that we have a lot more leeway to make mistakes
> on a .0 release.  We're not going to be cut any slack at all for shipping
> a badly regressed point release.
> 
> Some minor regressions are inevitable in software, but they do indeed
> need to be minor.
> 
> For how we're doing with regressions in general, see:
> 
>  http://people.freebsd.org/~linimon/studies/prs/prs_for_tag_regression.html
> 
> Now, it's true that many of the recent PRs are against 9.0, and many of
> the ones that aren't may be stale (certainly most of the pre-2010 ones),
> but these are the types of things that users really notice and become
> unhappy about.

All good points, although I'd guess there's some diminishing returns argument
for progressive RCs/BETAs, however probably only the RE team have a good feeling
for the sweet spot.

- Mark

_______________________________________________
(Continue reading)

Permalink | Reply |
headers
Rick Macklem | 27 Jan 2012 03:18
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

Mark Blackman wrote:
> On 26 Jan 2012, at 14:37, John Baldwin wrote:
> 
> > On Thursday, January 19, 2012 4:33:40 pm Adrian Chadd wrote:
> >> On 19 January 2012 09:47, Mark Saad <nonesuch <at> longcount.org> wrote:
> >>>
> >>>
> >>> What could I do to help make 7.5-RELEASE a reality ?
> >>>
> >>
> >> Put your hand up and volunteer to run the 7.5-RELEASE release
> >> cycle.
> >
> > That's not actually true or really fair. There has to be some buy-in
> > from the
> > project to do an official release; it is not something that a single
> > person
> > can do off in a corner and then have the Project bless the bits as
> > an official
> > release.
> 
> And raises the interesting question for an outsider of
> 
> a) who is "the project" in this case
> and
> b) what does it take for a release to be a release?
> 
> Wasn't there a freebsd-releng (or similar) mailing list ages ago?
> 
I am going to avoid the above question, since I don't know the answer
(Continue reading)

Permalink | Reply |
headers
Devin Teske | 19 Jan 2012 20:19

RE: FreeBSD has serious problems with focus, longevity, and lifecycle


> -----Original Message-----
> From: owner-freebsd-hackers <at> freebsd.org [mailto:owner-freebsd-
> hackers <at> freebsd.org] On Behalf Of Robert Huff
> Sent: Thursday, January 19, 2012 8:35 AM
> To: freebsd-hackers <at> freebsd.org
> Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle
> 
> 
> Igor Mozolevsky writes:
> 
> >  > Wouldn't this discourage even more people from helping?
> >
> >  Would this not separate people who have a genuine interest in
> > contributing from "tinker-monkeys"?
> 
> 	Did I miss a previous definition of "tinker-monkey"?
> 

And is it anything like a "tinker-tailor"?
--

-- 
Devin

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended
recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the
message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons other than the intended
recipient. Thank you.
_______________________________________________
(Continue reading)

Permalink | Reply |
headers
Igor Mozolevsky | 19 Jan 2012 22:59
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 19 January 2012 16:35, Robert Huff <roberthuff <at> rcn.com> wrote:
>
> Igor Mozolevsky writes:
>
>>  > Wouldn't this discourage even more people from helping?
>>
>>  Would this not separate people who have a genuine interest in
>>  contributing from "tinker-monkeys"?
>
>        Did I miss a previous definition of "tinker-monkey"?

Coders who attempt to repair or improve something in a way that lacks
a plan, purpose, or enthusiasm, often to no useful effect. First
coined by me in this thread :-)

Cheers,
--
Igor M. :-)
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Andriy Gapon | 18 Jan 2012 10:25
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

on 18/01/2012 02:16 Igor Mozolevsky said the following:
> Seriously, WTF is the point of having a PR system that allows patches
> to be submitted??! When I submit a patch I fix *your* code (not yours
> personally, but you get my gist).

Let me pretend that I don't get it.  It is as much your code as it is mine if
you are a user of FreeBSD.  I just happen to have a commit bit at this point in
time.

> No other project requires a
> non-committer to be so ridiculously persistent in order to get a patch
> through.

There are about 5000 open PRs for FreeBSD base system, maybe more.
There are only a few dozens of active FreeBSD developers.  Maybe less for any
given particular point in time (as opposed to a period of time).
And dealing with PRs is not always exciting.
Need I continue?

P.S. Using GNATS for the PR database doesn't help either, in some technical ways.
--

-- 
Andriy Gapon
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Igor Mozolevsky | 18 Jan 2012 11:54
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 18 January 2012 09:25, Andriy Gapon <avg <at> freebsd.org> wrote:
> on 18/01/2012 02:16 Igor Mozolevsky said the following:
>> Seriously, WTF is the point of having a PR system that allows patches
>> to be submitted??! When I submit a patch I fix *your* code (not yours
>> personally, but you get my gist).
>
> Let me pretend that I don't get it.  It is as much your code as it is mine if
> you are a user of FreeBSD.  I just happen to have a commit bit at this point in
> time.

Actually that is not true at all, it is in no way "my" code because
there is absolutely nothing I can do to change it (evidently, even if
I do submit patches ;-) )---I'm, at best, an involved bystander!..

>> No other project requires a
>> non-committer to be so ridiculously persistent in order to get a patch
>> through.
>
> There are about 5000 open PRs for FreeBSD base system, maybe more.
> There are only a few dozens of active FreeBSD developers.  Maybe less for any
> given particular point in time (as opposed to a period of time).
> And dealing with PRs is not always exciting.
> Need I continue?

Is that because there are so many bugs that need fixing or is it
because PRs get ignored/become staled? From the preceding discussion
it appears to be more of the latter than the former. While I
appreciate the excitement in churning out new "edge" code, pretending
that old bugs do not exist will not simply make them go away... In
fact, given the large number of PRs (and thus presumably ones
(Continue reading)

Permalink | Reply |
headers
Andriy Gapon | 18 Jan 2012 12:08
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

on 18/01/2012 12:54 Igor Mozolevsky said the following:
> On 18 January 2012 09:25, Andriy Gapon <avg <at> freebsd.org> wrote:
>> on 18/01/2012 02:16 Igor Mozolevsky said the following:
>>> Seriously, WTF is the point of having a PR system that allows patches
>>> to be submitted??! When I submit a patch I fix *your* code (not yours
>>> personally, but you get my gist).
>>
>> Let me pretend that I don't get it.  It is as much your code as it is mine if
>> you are a user of FreeBSD.  I just happen to have a commit bit at this point in
>> time.
> 
> Actually that is not true at all, it is in no way "my" code because
> there is absolutely nothing I can do to change it (evidently, even if
> I do submit patches ;-) )---I'm, at best, an involved bystander!..

In a philosophical sense you are what you chose to be.
If you really want to change the code you can make it happen.
Fork being an ultimate option, but there are many less dramatic ways.

>>> No other project requires a
>>> non-committer to be so ridiculously persistent in order to get a patch
>>> through.
>>
>> There are about 5000 open PRs for FreeBSD base system, maybe more.
>> There are only a few dozens of active FreeBSD developers.  Maybe less for any
>> given particular point in time (as opposed to a period of time).
>> And dealing with PRs is not always exciting.
>> Need I continue?
> 
> Is that because there are so many bugs that need fixing or is it
(Continue reading)

Permalink | Reply |
headers
Igor Mozolevsky | 18 Jan 2012 12:54
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 18 January 2012 11:08, Andriy Gapon <avg <at> freebsd.org> wrote:
> on 18/01/2012 12:54 Igor Mozolevsky said the following:

[snip]

>>> There are about 5000 open PRs for FreeBSD base system, maybe more.
>>> There are only a few dozens of active FreeBSD developers.  Maybe less for any
>>> given particular point in time (as opposed to a period of time).
>>> And dealing with PRs is not always exciting.
>>> Need I continue?
>>
>> Is that because there are so many bugs that need fixing or is it
>> because PRs get ignored/become staled?
>
> Sorry for saying the obvious, but it is because the PRs are fixed at slower rate
> than they are opened.

That may be the case, but we are not talking about PRs as a whole, but
PRs that already contain fixes...

>> From the preceding discussion
>> it appears to be more of the latter than the former.
>
> Impressions can be deceiving.
> Honestly, do you believe that all committers are willfully ignoring the PRs just
> to cause pain to the users?  Or do you consider a possibility that there is an
> objective reason why the things are the way they are?

I was not suggesting malice on behalf of the developers at all, what I
was saying is that there is an *appearance* that developers prefer to
(Continue reading)

Permalink | Reply |
headers
Andriy Gapon | 18 Jan 2012 13:18
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

on 18/01/2012 13:54 Igor Mozolevsky said the following:
> On 18 January 2012 11:08, Andriy Gapon <avg <at> freebsd.org> wrote:
>> on 18/01/2012 12:54 Igor Mozolevsky said the following:
> 
> [snip]
> 
>>>> There are about 5000 open PRs for FreeBSD base system, maybe more.
>>>> There are only a few dozens of active FreeBSD developers.  Maybe less for any
>>>> given particular point in time (as opposed to a period of time).
>>>> And dealing with PRs is not always exciting.
>>>> Need I continue?
>>>
>>> Is that because there are so many bugs that need fixing or is it
>>> because PRs get ignored/become staled?
>>
>> Sorry for saying the obvious, but it is because the PRs are fixed at slower rate
>> than they are opened.
> 
> That may be the case, but we are not talking about PRs as a whole, but
> PRs that already contain fixes...

They get lost in the noise quite easily.
And probably not many people start their days with browsing through the PRs
looking for a gem.

>>> From the preceding discussion
>>> it appears to be more of the latter than the former.
>>
>> Impressions can be deceiving.
>> Honestly, do you believe that all committers are willfully ignoring the PRs just
(Continue reading)

Permalink | Reply |
headers
Mark Linimon | 22 Jan 2012 06:56

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Wed, Jan 18, 2012 at 02:18:50PM +0200, Andriy Gapon wrote:
> So software can already send the reminders, but the real problem is to
> assign the PRs in the first place.  Currently most assignment are self-
> assignments.

My experience has been that assigning PRs to people who have not
specifically requested that PRs related to that subject be assigned
to them, almost always results in the PRs languishing.  This is why
I (with bugmeister hat on) discourage the bugbusters from doing so.

mcl
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Garrett Cooper | 18 Jan 2012 16:35
Picon
Gravatar

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

[snip]

> For starters, what would be much more appreciated is for devs to be
> much more involved from the start once someone does submit the patch.
> I appreciate that people a fallible and from time to time are bound to
> forget that they have a PR with a patch assigned to them, but there's
> no reason why the PR handling system can't email reminders...

GNATS already emails periodic reminders to bug owners (be the owners individual devs or mailing lists, eg
freebsd-rc, etc).
-Garrett_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Robert Watson | 18 Jan 2012 12:32
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Wed, 18 Jan 2012, Andriy Gapon wrote:

> on 18/01/2012 02:16 Igor Mozolevsky said the following:
>> Seriously, WTF is the point of having a PR system that allows patches to be 
>> submitted??! When I submit a patch I fix *your* code (not yours personally, 
>> but you get my gist).
>
> Let me pretend that I don't get it.  It is as much your code as it is mine 
> if you are a user of FreeBSD.  I just happen to have a commit bit at this 
> point in time.
>
>> No other project requires a non-committer to be so ridiculously persistent 
>> in order to get a patch through.
>
> There are about 5000 open PRs for FreeBSD base system, maybe more. There are 
> only a few dozens of active FreeBSD developers.  Maybe less for any given 
> particular point in time (as opposed to a period of time). And dealing with 
> PRs is not always exciting. Need I continue?
>
> P.S. Using GNATS for the PR database doesn't help either, in some technical 
> ways.

The structural problem around the PR system for the base system is that there 
isn't a whole lot of incentive for most developers to use it.  I think we can 
reasonably categorise developers into three classes -- some move between or 
span them, of course:

(1) Volunteers.  Due to childhood trauma, they have a desperate urge to write
     operating systems.  Not much incentive to do PRs here, as most refer to
     versions of FreeBSD before their time, aren't great characterisations,
(Continue reading)

Permalink | Reply |
headers
Julian Elischer | 18 Jan 2012 18:49
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 1/18/12 3:32 AM, Robert Watson wrote:
>
> Another possibility is to get some combination of {The FreeBSD 
> Foundation, iX Systems, ...} to trawl the bug report database in a 
> more official capacity. The problem there is that this will be a 
> high burn-out job.  I'll bring it up at the next Foundation board 
> meeting, especially after a bumper year of fund-raising, and see 
> what we can do.

we really need a bud-submitting-user advocate..

Someone (need not have a commit bit) who doesn't take charge of the 
patch, but, rather,
acts as a project manager in hte process of getting it in.
i.e. finding, and then pinging the approriate developer, and 
occasionally nagging them or
finding an alternate dev if the first choice is unresponsive.

diplomatic skill would be important..  maybe a woman might be best in
this job as the developers tend to not want to be rude to women :-)  .

>
> Robert
> _______________________________________________
>

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
(Continue reading)

Permalink | Reply |
headers
Adam Vande More | 18 Jan 2012 19:27
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Wed, Jan 18, 2012 at 11:49 AM, Julian Elischer <julian <at> freebsd.org>wrote:

>
> we really need a bud-submitting-user advocate..
>
> Someone (need not have a commit bit) who doesn't take charge of the patch,
> but, rather,
> acts as a project manager in hte process of getting it in.
> i.e. finding, and then pinging the approriate developer, and occasionally
> nagging them or
> finding an alternate dev if the first choice is unresponsive.
>
> diplomatic skill would be important..  maybe a woman might be best in
> this job as the developers tend to not want to be rude to women :-)  .
>

I've suggested this before without much response, but since this thread
seems to be encouraging repetition I'll give it another go.  ;)

I think a bounty system would be very effective(e.g. micro-donations of
recent political campaigns) in getting many of these problems resolved.
The main problem with a bounty system is getting people to pay since
certain needs/desires lose their urgency over time.  To address this, the
system needs to be an escrow type setup where money is pooled until project
is complete, then payment in full is given.

There are large barriers to entry in setting up such a system though such
as legal and financial hurdles.  I don't believe the technical hurdles are
over-whelming and I would be willing develop a web front end for such a
system.  Because of the barriers I believe such a system should be setup
(Continue reading)

Permalink | Reply |
headers
Matt Olander | 18 Jan 2012 20:03
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Wed, Jan 18, 2012 at 10:27 AM, Adam Vande More <amvandemore <at> gmail.com> wrote:
> I've suggested this before without much response, but since this thread
> seems to be encouraging repetition I'll give it another go.  ;)
>
> I think a bounty system would be very effective(e.g. micro-donations of
> recent political campaigns) in getting many of these problems resolved.
> The main problem with a bounty system is getting people to pay since
> certain needs/desires lose their urgency over time.  To address this, the
> system needs to be an escrow type setup where money is pooled until project
> is complete, then payment in full is given.
>
> There are large barriers to entry in setting up such a system though such
> as legal and financial hurdles.  I don't believe the technical hurdles are
> over-whelming and I would be willing develop a web front end for such a
> system.  Because of the barriers I believe such a system should be setup
> and spun off by the FreeBSD Foundation and I don't want to do any dev
> unless there is some momentum.

Hi Adam,

I went down this road sometime ago and went so far as to create a
portal so that iXsystems could manage the transactions (collect the
funds and make sure everyone got paid). We put a bit of work into it
and we would be happy to hand the keys over to the Foundation if it's
useful at all.

http://sponsorbsd.org/

Let me know off-list if you'd like access to look at the code. It's a
simple CakePHP app and needs a little bit of love but worked
(Continue reading)

Permalink | Reply |
headers
Garrett Cooper | 18 Jan 2012 20:05
Picon
Gravatar

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Wed, Jan 18, 2012 at 10:27 AM, Adam Vande More <amvandemore <at> gmail.com> wrote:
> On Wed, Jan 18, 2012 at 11:49 AM, Julian Elischer <julian <at> freebsd.org>wrote:
>
>>
>> we really need a bud-submitting-user advocate..
>>
>> Someone (need not have a commit bit) who doesn't take charge of the patch,
>> but, rather,
>> acts as a project manager in hte process of getting it in.
>> i.e. finding, and then pinging the approriate developer, and occasionally
>> nagging them or
>> finding an alternate dev if the first choice is unresponsive.
>>
>> diplomatic skill would be important..  maybe a woman might be best in
>> this job as the developers tend to not want to be rude to women :-)  .
>>
>
> I've suggested this before without much response, but since this thread
> seems to be encouraging repetition I'll give it another go.  ;)
>
> I think a bounty system would be very effective(e.g. micro-donations of
> recent political campaigns) in getting many of these problems resolved.
> The main problem with a bounty system is getting people to pay since
> certain needs/desires lose their urgency over time.  To address this, the
> system needs to be an escrow type setup where money is pooled until project
> is complete, then payment in full is given.
>
> There are large barriers to entry in setting up such a system though such
> as legal and financial hurdles.  I don't believe the technical hurdles are
> over-whelming and I would be willing develop a web front end for such a
(Continue reading)

Permalink | Reply |
headers
Igor Mozolevsky | 18 Jan 2012 20:06
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 18 January 2012 18:27, Adam Vande More <amvandemore <at> gmail.com> wrote:

> I've suggested this before without much response, but since this thread
> seems to be encouraging repetition I'll give it another go.  ;)
>
> I think a bounty system would be very effective(e.g. micro-donations of
> recent political campaigns) in getting many of these problems resolved.  The
> main problem with a bounty system is getting people to pay since certain
> needs/desires lose their urgency over time.  To address this, the system
> needs to be an escrow type setup where money is pooled until project is
> complete, then payment in full is given.

This has a lot of problems in itself: people would just turn around
and say that bugs will not get fixed unless they get hard cash for the
fix, or FreeBSD might end up in the situation where devs get paid to
fix the bugs they introduced, deliberately or innocently, essentially
getting paid to fix their own sloppy code, which is not that great
either.

--
Igor M.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Mike Meyer | 18 Jan 2012 20:02
Gravatar

Bug triage (Was: FreeBSD has serious problems with focus, longevity, and lifecycle)

On Wed, 18 Jan 2012 09:49:23 -0800
Julian Elischer <julian <at> freebsd.org> wrote:

> On 1/18/12 3:32 AM, Robert Watson wrote:
> >
> > Another possibility is to get some combination of {The FreeBSD 
> > Foundation, iX Systems, ...} to trawl the bug report database in a 
> > more official capacity. The problem there is that this will be a 
> > high burn-out job.  I'll bring it up at the next Foundation board 
> > meeting, especially after a bumper year of fund-raising, and see 
> > what we can do.
> we really need a bug-submitting-user advocate..

The word you're looking for here is "triage". One of the two common
denominators of the good support organizations I've worked with is
good triage (the other is good metrics).

> Someone (need not have a commit bit) who doesn't take charge of the 
> patch, but, rather,
> acts as a project manager in the process of getting it in.
> i.e. finding, and then pinging the approriate developer, and 
> occasionally nagging them or
> finding an alternate dev if the first choice is unresponsive.
> 
> diplomatic skill would be important..  maybe a woman might be best in
> this job as the developers tend to not want to be rude to women :-)  .

Actually, there's a second half to this that you're overlooking. The
person doing this job should make sure the PR's have everything the
developer needs before they assign them to a developer. I suspect the
(Continue reading)

Permalink | Reply |
headers
Julian Elischer | 18 Jan 2012 03:41
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 1/17/12 3:36 PM, Ian Lepore wrote:
> On Wed, 2012-01-18 at 01:17 +0200, Andriy Gapon wrote:
>> on 17/01/2012 23:46 Ian Lepore said the following:
>>> Now, before we're even really completely up and running on 8.2 at work,
>>> 9.0 hits the street, and developers have moved on to working in the 10.0
>>> world.  What are the chances that any of the patches I've submitted for
>>> bugs we fixed in 8.x are ever going to get commited now that 8 is well
>>> on its way to becoming ancient history in developers' minds?
>> My opinion is that this will have more to do with your approach to pushing the
>> patches (and your persistence) rather than with anything else.  As long as
>> stable/8 is still a supported branch or the bugs are reproducible in any of the
>> supported branches.
> Well I submitted a sort of random sample of the patches we're
> maintaining at work, 11 of them as formal PRs and 2 posted to the lists
> here recently.  So far two have been committed (the most important one
> and the most trivial one, oddly enough).  I'm not sure just how pushy
> one is supposed to be, I don't want to be a jerk.  Not to mention that I
> wouldn't know who to push.  That's actually why I'm now being active on
> the mailing lists, I figured maybe patches will be more accepted from
> someone the commiters know rather than just as code out of the blue
> attached to a PR.

you are supposed to be as pushy as you need to be..
If you really want your patches in I'd suggest teh following method:

1/ post a summary email explaining all teh bugs and patches
2/ see if anyone takes them up
3/ for the remaining problems, find the names of developers who
have committed to that code and contact them asking for their assistance.
4/ report back here ;-)
(Continue reading)

Permalink | Reply |
headers
Devin Teske | 18 Jan 2012 01:18

RE: FreeBSD has serious problems with focus, longevity, and lifecycle


> -----Original Message-----
> From: owner-freebsd-hackers <at> freebsd.org [mailto:owner-freebsd-
> hackers <at> freebsd.org] On Behalf Of Julian Elischer
> Sent: Tuesday, January 17, 2012 10:56 AM
> To: Mark Felder
> Cc: freebsd-hackers <at> freebsd.org
> Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle
> 
> On 1/17/12 7:39 AM, Mark Felder wrote:
> > Why is everyone so afraid of running -STABLE? Plenty of stuff gets
> > MFC'd. Yeah, I agree -- running -RELEASE is difficult. Hell, it's
> > frustrating to us that VMWare only supports -RELEASE and it took until
> > ESX 5 to officially support 8.2!
> >
> > More releases / snapshots of -STABLE helps people on physical servers,
> > but anyone who runs VMs on Xen or VMWare won't get any support for
> > those versions because they didn't go through the QA process yet.
> > FreeBSD is increasingly becoming a third world citizen thanks to
> > virtualization efforts being focused on Linux, so I feel that more
> > frequent releases won't help as many people as you think.
> 
> I'm going to go both ways on this one.
> 
> Where I used to work (Devin Teske is now there)  we used to use the 'stable'
> branch and rolll our own releases.

We still do this today, but have only further enhanced the procedure.

Within FreeBSD announcing a new release, we can be ready to ship said-release within 3-6 weeks.
(Continue reading)

Permalink | Reply |
headers
Devin Teske | 18 Jan 2012 18:06

RE: FreeBSD has serious problems with focus, longevity, and lifecycle


> -----Original Message-----
> From: owner-freebsd-hackers <at> freebsd.org [mailto:owner-freebsd-
> hackers <at> freebsd.org] On Behalf Of Julian Elischer
> Sent: Tuesday, January 17, 2012 10:56 AM
> To: Mark Felder
> Cc: freebsd-hackers <at> freebsd.org
> Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle
> 
[snip]

> Where I used to work (Devin Teske is now there)  we used to use the 'stable'
> branch and rolll our own releases.
> the criticality of those systems was hard to over-emphasize. In 2005 we worked
> out we processed 1.5 trillion dollars of transactions on those systems.
> 

Got new stats. In 2011 we ran $1.61T USD through FreeBSD.

Separately, we ran another $0.05T USD through Linux in the same year.

Kinda says something about, doesn't it?
--

-- 
Devin

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended
recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the
message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons other than the intended
(Continue reading)

Permalink | Reply |
headers
Igor Mozolevsky | 18 Jan 2012 18:11
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 18 January 2012 17:06, Devin Teske <devin.teske <at> fisglobal.com> wrote:
>
>
>> -----Original Message-----
>> From: owner-freebsd-hackers <at> freebsd.org [mailto:owner-freebsd-
>> hackers <at> freebsd.org] On Behalf Of Julian Elischer
>> Sent: Tuesday, January 17, 2012 10:56 AM
>> To: Mark Felder
>> Cc: freebsd-hackers <at> freebsd.org
>> Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle
>>
> [snip]
>
>> Where I used to work (Devin Teske is now there)  we used to use the 'stable'
>> branch and rolll our own releases.
>> the criticality of those systems was hard to over-emphasize. In 2005 we worked
>> out we processed 1.5 trillion dollars of transactions on those systems.
>>
>
> Got new stats. In 2011 we ran $1.61T USD through FreeBSD.
>
> Separately, we ran another $0.05T USD through Linux in the same year.
>
> Kinda says something about, doesn't it?

Sorry to burst your bubble but this is utterly meaningless statistic.
You show nothing but correlation and in no way a causation. Back in
the days when the UK banks ran ATMs, &c on Windows NT (I have no idea
what they are running now) they went through a lot more "value" than
that---means absolutely nothing...
(Continue reading)

Permalink | Reply |
headers
Chris Rees | 18 Jan 2012 18:30
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 18 Jan 2012 17:12, "Igor Mozolevsky" <igor <at> hybrid-lab.co.uk> wrote:
> On 18 January 2012 17:06, Devin Teske <devin.teske <at> fisglobal.com> wrote:
> >> -----Original Message-----
> >> From: owner-freebsd-hackers <at> freebsd.org [mailto:owner-freebsd-
> >> hackers <at> freebsd.org] On Behalf Of Julian Elischer
> >> Sent: Tuesday, January 17, 2012 10:56 AM
> >> To: Mark Felder
> >> Cc: freebsd-hackers <at> freebsd.org
> >> Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle
> >>
> > [snip]
> >
> >> Where I used to work (Devin Teske is now there)  we used to use the 'stable'
> >> branch and rolll our own releases.
> >> the criticality of those systems was hard to over-emphasize. In 2005 we worked
> >> out we processed 1.5 trillion dollars of transactions on those systems.
> >>
> >
> > Got new stats. In 2011 we ran $1.61T USD through FreeBSD.
> >
> > Separately, we ran another $0.05T USD through Linux in the same year.
> >
> > Kinda says something about, doesn't it?
>
> Sorry to burst your bubble but this is utterly meaningless statistic.
> You show nothing but correlation and in no way a causation. Back in
> the days when the UK banks ran ATMs, &c on Windows NT (I have no idea
> what they are running now) they went through a lot more "value" than
> that---means absolutely nothing...
>
(Continue reading)

Permalink | Reply |
headers
Igor Mozolevsky | 18 Jan 2012 18:35
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 18 January 2012 17:30, Chris Rees <utisoft <at> gmail.com> wrote:
> On 18 Jan 2012 17:12, "Igor Mozolevsky" <igor <at> hybrid-lab.co.uk> wrote:

>> Back in the days when the UK banks ran ATMs, &c on Windows NT (I
>> have no idea what they are running now)

> Well.... I've not seen any BSOD'd cashpoints around for a while, so
> I'd like to suggest they may have switched.

That, or they found "reboot after crash" tick box... ;-)

--
Igor M.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Devin Teske | 18 Jan 2012 18:56

RE: FreeBSD has serious problems with focus, longevity, and lifecycle


> -----Original Message-----
> From: mozolevsky <at> gmail.com [mailto:mozolevsky <at> gmail.com] On Behalf Of Igor
> Mozolevsky
> Sent: Wednesday, January 18, 2012 9:12 AM
> To: Devin Teske
> Cc: Julian Elischer; Mark Felder; freebsd-hackers <at> freebsd.org
> Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle
> 
> On 18 January 2012 17:06, Devin Teske <devin.teske <at> fisglobal.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: owner-freebsd-hackers <at> freebsd.org [mailto:owner-freebsd-
> >> hackers <at> freebsd.org] On Behalf Of Julian Elischer
> >> Sent: Tuesday, January 17, 2012 10:56 AM
> >> To: Mark Felder
> >> Cc: freebsd-hackers <at> freebsd.org
> >> Subject: Re: FreeBSD has serious problems with focus, longevity, and
> >> lifecycle
> >>
> > [snip]
> >
> >> Where I used to work (Devin Teske is now there)  we used to use the 'stable'
> >> branch and rolll our own releases.
> >> the criticality of those systems was hard to over-emphasize. In 2005
> >> we worked out we processed 1.5 trillion dollars of transactions on those
> systems.
> >>
> >
(Continue reading)

Permalink | Reply |
headers
Victor Balada Diaz | 17 Jan 2012 18:10

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Mon, Jan 16, 2012 at 02:28:09PM -0800, John Kozubik wrote:
> 
> Friends,
> 
> I was disappointed to see that 8.3-RELEASE is now slated to come out in 
> March of 2012.  This will be ~13 months since 8.2-RELEASE and is typical 
> of a trend towards longer gaps between minor releases.
> 
> I also see that undercutting the current release before wide deployment 
> and maturity is continuing.  7.0 came (barely) after 6.3, which was bad 
> enough, but not as bad as 8.0 arriving with 7.2, and now 9.0 with 8.2.
> 
> Finally, the culture of "that's fixed in CURRENT" or "we built those 
> changes into (insert next major release)" continues to get worse.  It's 
> difficult to escape the notion that FreeBSD is becoming an operating 
> system by, and for, FreeBSD developers.
> 

Hello John,

With my sysadmin hat on i can echo your feelings, but i guess that your
proposals are more focused on a company environment than a collaborative
environment.

First i would like to remember the last stage of FreeBSD 4.x for those
people (not you) who are arguing in the thread about long "stable" releases.
Those of us who used FreeBSD 4.x on the late release cycle will remember
a few of this problems:

	- New hardware didn't work because no ACPI support was in 4.x until
(Continue reading)

Permalink | Reply |
headers
Adrian Chadd | 18 Jan 2012 00:01
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

.. I'm replying to the OP because honestly, this thread has gotten a
bit derailed.

If you'd like to see:

... more frequent releases? then please step up and help with all the
infrastructure needed to roll out test releases, including building
_all_ the ports. A lot of people keep forgetting that a "release" is
"build all the ports for all the supported platforms".

... longer lifecycle? Then please step up and contribute patches for
features for your favourite branch. As a developer doing this in my
spare time I'm only really working on new features on -HEAD and maybe
backporting fixes to 9.x. What _I_ would like is someone to take on
the task of testing and backporting net80211/ath fixes to 8.x and 7.x.

... longer branch lifecycle? Same as above. None of the developers are
going to reject bugfixes and backported drivers to a legacy, stable
branch. We may be a bit against the idea of porting entire new
subsystems to legacy, stable branches - but if there's a good enough
reason _and_ it's been tested _and_ there's a need for it - _I_
wouldn't say no.

If you care this much to comment on it, please consider caring enough
to step up and assist. Or, pay a company like ixSystems for FreeBSD
support and get them to do this for you. Otherwise you're just
re-iterating the same stuff I'm sure all the developers know but are
just out of manpower/time/money/resources to do anything about.

Adrian
(Continue reading)

Permalink | Reply |
headers
Igor Mozolevsky | 18 Jan 2012 00:16
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 17 January 2012 23:01, Adrian Chadd <adrian <at> freebsd.org> wrote:

> If you'd like to see:
>
> ... more frequent releases? then please step up and help with all the
> infrastructure needed to roll out test releases, including building
> _all_ the ports. A lot of people keep forgetting that a "release" is
> "build all the ports for all the supported platforms".

I don't know this so I'm asking: does fixing a port to work on a
pending release involve substantial changes (as in functionality cf.
cosmetic) to the "core" or just patching the port to work with the
core? If latter, maybe it's worthwhile uncoupling the two (core OS and
ports)?

--
Igor M. :-)
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Daniel Eischen | 18 Jan 2012 00:45
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Tue, 17 Jan 2012, Igor Mozolevsky wrote:

> On 17 January 2012 23:01, Adrian Chadd <adrian <at> freebsd.org> wrote:
>
>> If you'd like to see:
>>
>> ... more frequent releases? then please step up and help with all the
>> infrastructure needed to roll out test releases, including building
>> _all_ the ports. A lot of people keep forgetting that a "release" is
>> "build all the ports for all the supported platforms".
>
> I don't know this so I'm asking: does fixing a port to work on a
> pending release involve substantial changes (as in functionality cf.
> cosmetic) to the "core" or just patching the port to work with the
> core? If latter, maybe it's worthwhile uncoupling the two (core OS and
> ports)?

IMHO, the two are already uncoupled too much.  The problem I have
with ports is that there is not a -stable branch that tracks with
-stable core.  I don't need the latest and greatest ports, just
security and bug fixes.  It doesn't even have to be every port,
just the commonly used ports.  There's not enough man power for
this, unfortunately, but I'm still happy that at least we _do_
have _a_ ports system :-)

--

-- 
DE
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
(Continue reading)

Permalink | Reply |
headers
Mark Linimon | 20 Jan 2012 09:58

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Tue, Jan 17, 2012 at 06:45:17PM -0500, Daniel Eischen wrote:
> The problem I have with ports is that there is not a -stable branch
> that tracks with -stable core.

We've been working for 18 months to try to get the hardware infrastructure
in place to be able to consider such approaches.

> It doesn't even have to be every port, just the commonly used ports.

That's easy in theory, but extremely difficult in practice.  The infra-
sturcture is far more heavyweight (because of demand for features) than
most people give it credit for.

There's no concept of "subset of ports tree".  Go examine the hierarchy
and it will become apparent why.

Even a "server-only" concept doesn't get you as far as you might think.

Again, "the general problem is hard".

mcl
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Andriy Gapon | 18 Jan 2012 00:27
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

on 18/01/2012 01:01 Adrian Chadd said the following:
> .. I'm replying to the OP because honestly, this thread has gotten a
> bit derailed.
> 
> If you'd like to see:
> 
> ... more frequent releases? then please step up and help with all the
> infrastructure needed to roll out test releases, including building
> _all_ the ports. A lot of people keep forgetting that a "release" is
> "build all the ports for all the supported platforms".
> 
> ... longer lifecycle? Then please step up and contribute patches for
> features for your favourite branch. As a developer doing this in my
> spare time I'm only really working on new features on -HEAD and maybe
> backporting fixes to 9.x. What _I_ would like is someone to take on
> the task of testing and backporting net80211/ath fixes to 8.x and 7.x.
> 
> ... longer branch lifecycle? Same as above. None of the developers are
> going to reject bugfixes and backported drivers to a legacy, stable
> branch. We may be a bit against the idea of porting entire new
> subsystems to legacy, stable branches - but if there's a good enough
> reason _and_ it's been tested _and_ there's a need for it - _I_
> wouldn't say no.

And another 2 cents from me: we also have this KPI/KBI stability policy for the
stable branches.  So if anyone would like to have a "stable" branch but with
some super wanted/needed/requested change added, then that would be a bit harder
to arrange.  I personally would call that a custom branch.  And that of course
can also be done, even as an "official" custom branch, but interested people
would need either to take the job upon themselves or find (motivate, interest)
(Continue reading)

Permalink | Reply |
headers
Doug Barton | 18 Jan 2012 00:50
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

First, let's do away with the whole, "If you step up to help, your help
will be accepted with open arms" myth. That's only true if the project
leadership agrees with your goals.

We also need to take a step back and ask if throwing more person-hours
at the problem is the right solution, or if redesigning the system to
better meet the needs of the users *as a first step* is the right answer?

On 01/17/2012 15:01, Adrian Chadd wrote:
> .. I'm replying to the OP because honestly, this thread has gotten a
> bit derailed.
> 
> If you'd like to see:
> 
> ... more frequent releases? then please step up and help with all the
> infrastructure needed to roll out test releases, including building
> _all_ the ports. A lot of people keep forgetting that a "release" is
> "build all the ports for all the supported platforms".

Does it need to be? I've been pushing a long time now to have a branched
ports tree. If we have a "stable" version of the ports where only
known-good changes are promoted then that frees us up quite a bit to
redefine what a "release" is.

> ... longer lifecycle? Then please step up and contribute patches for
> features for your favourite branch. As a developer doing this in my
> spare time I'm only really working on new features on -HEAD and maybe
> backporting fixes to 9.x. What _I_ would like is someone to take on
> the task of testing and backporting net80211/ath fixes to 8.x and 7.x.
(Continue reading)

Permalink | Reply |
headers
John Kozubik | 18 Jan 2012 00:59

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


Hi Doug,

Thanks a lot for these comments and insight - response below...

On Tue, 17 Jan 2012, Doug Barton wrote:

> I tried to make the point back in June that there was no reason to cut
> 9.0-RELEASE yet because we don't have solid support for clang in either
> the base, or ports (amongst several other reasons) and that the delay
> for getting that working would be a great "excuse" for slipping the
> support schedule for 8 so that we could release 9.0 not-too-long before
> 7 was about to go EOL, and make the 8/9/10 release schedules fit the
> new, (hopefully) more rational model. Perhaps we can reconsider that
> idea for 10.0.

Just previously in this thread, I suggested the following:

<quote>
You could progress 8.x along its current trajectory, possibly 
building 8.4 a year or so from now and then be done with it, and then that 
would be the last short/unfocused release.

Then you postpone 10.0-RELEASE until January 2017.

Instead of having a legacy branch and two production branches, you would 
have legacy (8) production (9) and ... nothing.  Or if you need to have it 
out there, 10 is the development branch.

Minor releases come out 2-3 times per year, which gets you to 9.10 or 9.15
(Continue reading)

Permalink | Reply |
headers
Julian Elischer | 18 Jan 2012 03:57
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 1/17/12 3:50 PM, Doug Barton wrote:
> First, let's do away with the whole, "If you step up to help, your help
> will be accepted with open arms" myth. That's only true if the project
> leadership agrees with your goals.
"leadership" doesn't really control development here. action does.
> We also need to take a step back and ask if throwing more person-hours
> at the problem is the right solution, or if redesigning the system to
> better meet the needs of the users *as a first step* is the right answer?
>

careful, you are starting to sound reasonable there..

> On 01/17/2012 15:01, Adrian Chadd wrote:
>> .. I'm replying to the OP because honestly, this thread has gotten a
>> bit derailed.
>>
>> If you'd like to see:
>>
>> ... more frequent releases? then please step up and help with all the
>> infrastructure needed to roll out test releases, including building
>> _all_ the ports. A lot of people keep forgetting that a "release" is
>> "build all the ports for all the supported platforms".
> Does it need to be? I've been pushing a long time now to have a branched
> ports tree. If we have a "stable" version of the ports where only
> known-good changes are promoted then that frees us up quite a bit to
> redefine what a "release" is.
that's another 'man hours' problem (branched ports)
>> ... longer lifecycle? Then please step up and contribute patches for
>> features for your favourite branch. As a developer doing this in my
>> spare time I'm only really working on new features on -HEAD and maybe
(Continue reading)

Permalink | Reply |
headers
Robert Watson | 18 Jan 2012 12:47
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


On Tue, 17 Jan 2012, Doug Barton wrote:

> The other thing I think has been missing (as several have pointed out in 
> this thread already) is any sort of planning for what should be in the next 
> release. The current time-based release schedule is (in large part) a 
> reaction to the problems we had in getting 5.0 out the door. However I think 
> the pendulum has swung *way* too far in the wrong direction, such that we 
> are now afraid to put *any* kind of plan in place for fear that it will 
> cause the release schedule to slip. Aside from the obvious folly in that 
> (lack of) plan, it fails to take into account the fact that the release 
> schedules already slip, often comically far out into the future, and that 
> the results are often worse than they would have been otherwise.

Agreed entirely.  There's been an over-swing caused by the diagnosis "it's 
like herding cats" into "cats can't be herded, so why try?".  Projects like 
FreeBSD don't agree if there's no consensus on interesting problems to solve, 
directions to run in, etc.  The history of FreeBSD is also full of examples of 
successful collaborative development in which developers decide, together, on 
a direction and run that way.  Sure, it's not the same as "we are paying you 
to do X", but I think many FreeBSD developers like the idea that they are 
working on something larger than just their own micro-project, and would 
subscribe (and contribute) to a sensible plan.  In fact, I think we'd find 
that if we were a bit more forthcoming about our plans, we'd have an easier 
time soliciting contributions from people less involved in the project, as it 
would be more obvious how they could get involved.

It strikes me that the first basic plan would be a release schedule, however. 
:-)
(Continue reading)

Permalink | Reply |
headers
Mark Blackman | 18 Jan 2012 23:31

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


On 18 Jan 2012, at 11:47, Robert Watson wrote:
> 
> 
> It strikes me that the first basic plan would be a release schedule, however. :-)

7.4 - no further development
8.3 - Mar 2012
9.1 - May 2012
8.4 - July 2012
9.2 - Sep 2012 
8.5 - Nov 2012
9.3 - Jan  2013
8.6 - Mar 2013 
9.4 - May 2013
8.7 - July 2013 - Final release
9.5 - Sep 2013
10.0 - Nov 2013
9.6   - Jan 2014
10.1 - Mar 2014

Although, I'm not sure a release every two months would be practical.

- Mark_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Igor Mozolevsky | 18 Jan 2012 23:50
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 18 January 2012 22:31, Mark Blackman <mark <at> exonetric.com> wrote:

> 10.0 - Nov 2013

I think 10.0 should be released based on feature-readiness and not on
some arbitrary date...

--
Igor M.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Mark Blackman | 18 Jan 2012 23:53

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


On 18 Jan 2012, at 22:50, Igor Mozolevsky wrote:

> On 18 January 2012 22:31, Mark Blackman <mark <at> exonetric.com> wrote:
> 
>> 10.0 - Nov 2013
> 
> I think 10.0 should be released based on feature-readiness and not on
> some arbitrary date…

You can always redefine the feature-set to meet the date. :)

- Mark

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Igor Mozolevsky | 18 Jan 2012 23:59
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 18 January 2012 22:53, Mark Blackman <mark <at> exonetric.com> wrote:
>
> On 18 Jan 2012, at 22:50, Igor Mozolevsky wrote:
>
>> On 18 January 2012 22:31, Mark Blackman <mark <at> exonetric.com> wrote:
>>
>>> 10.0 - Nov 2013
>>
>> I think 10.0 should be released based on feature-readiness and not on
>> some arbitrary date…
>
> You can always redefine the feature-set to meet the date. :)

Yes, but there's a difference between releasing because it's the right
thing to do now vs releasing because it's about time...

--
Igor M. :-)
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Mark Blackman | 19 Jan 2012 00:05

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


On 18 Jan 2012, at 22:59, Igor Mozolevsky wrote:

> On 18 January 2012 22:53, Mark Blackman <mark <at> exonetric.com> wrote:
>> 
>> On 18 Jan 2012, at 22:50, Igor Mozolevsky wrote:
>> 
>>> On 18 January 2012 22:31, Mark Blackman <mark <at> exonetric.com> wrote:
>>> 
>>>> 10.0 - Nov 2013
>>> 
>>> I think 10.0 should be released based on feature-readiness and not on
>>> some arbitrary date…
>> 
>> You can always redefine the feature-set to meet the date. :)
> 
> Yes, but there's a difference between releasing because it's the right
> thing to do now vs releasing because it's about time…

The terse-ness of the e-mail should have told you it wasn't particularly
serious. :)

However, it was based around 3 minor releases per year, fitting whatever
features make sense, FSVO "sense", into each one,  giving HEAD a bit 
over two years to gestate into something you might one day  bet the farm 
on, which isn't a million miles from what happens anyway.

- Mark 

_______________________________________________
(Continue reading)

Permalink | Reply |
headers
Dieter BSD | 18 Jan 2012 00:29

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

Atom writes:
> i bought myself a LENOVO T510 when it first came out, around early 2010.
> it's got an i5 CPU and Arrandale GPU. it's two years old and on freeBSD i
> STILL can't run xorg properly with it.

I have a machine from 2005-08 that FreeBSD still doesn't support properly
in 2012. After much research I figured out that SATA NCQ was an essential
feature, and choose a mainboard with nforce4 to get it. FreeBSD still
doesn't support NCQ on nforce after all these years. Linux has had
NCQ on nforce4 since Oct 2006. FreeBSD also doesn't properly support
the onboard VIA firewire chip, which is still found on new mainboards
today. I don't necessarily expect support for every exotic chip out
there the first day they hit the street, but these are both popular
chips, and it is 6.5 years later. I'm not sure how an OS is supposed
to have "The power to serve" when it can't even talk to disks properly.
And all the device drivers that think it is ok to lollygag around
for absurd lengths of time with interrupts turned off, thus causing
data to be lost.

Damien writes:
> Check this PR I opened some months ago:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=161123&cat=kern
>
> It was planned for 9.0-RELEASE, there is no mention of 8.x
> That's just the kind of problem John raises here.

Hey, at least you have a fix, and it is even in a release (I'm
assuming it made it into 9.0). The bigger problem is all the
bugs that don't have fixes at all.
(Continue reading)

Permalink | Reply |
headers
Andriy Gapon | 18 Jan 2012 11:35
Picon
Favicon

FreeBSD is becoming ... by, and for, FreeBSD developers

on 17/01/2012 00:28 John Kozubik said the following:
> FreeBSD is becoming an operating system by, and for, FreeBSD developers

Just want to express my _personal_ opinion on this statement.

I think that the proper tense for the statement would perfect - "has become".
And I think that that is inevitable at present, because the FreeBSD project is a
purely community driven/developed project.  A project by the community.  And
it's natural that it has become a project for the community.  The community of
the project's developers.
Let's see.  The project has no management.  There is no hierarchy of reporting.
 There are no assignments.  No monetary leverage.  No structure.  No single
vision and will.

Let's omit a discussion of a possibility of a project "by users".

Instead let's try to see how projects perceived to be "for users" typically
work.  My personal observation is that those projects are always commercial
(which can be in a variety of ways).  That is, they are "for users", because
they look to make some money from their user base.  Either via direct sales, or
via support contracts, or via sales of related products and services, or via
monetary deals with other corporations, or via voluntary donations from users
and/or corporate sponsorship, or a combination.
And those projects internally are also based on money.  They are corporations:
they have management, they have hierarchy, they have assignments, they have
plans, they have salaries, they QA teams, etc.

Take for a popular example of Linux.  How much is for users the kernel.org?
Compare it to the most popular distributions which produce the original products
like Red Hat and Ubuntu.  Debian... to me it seems to be more of a "for
(Continue reading)

Permalink | Reply |
headers
Dieter BSD | 19 Jan 2012 01:56

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

John writes:
> - EOL 7
> - mark 8 as legacy
> - mark 9 as the _only_ production release
> - release 10.0 in January 2017

Until a few days ago 8 was the latest, shinest release.
So you want to suddenly demote it all the way down to legacy?
I thought the goal was to have releases that can be used for a long time?

On the one hand, many users want/need releases to have a long lifetime.
On the other hand, we want to be able to start a new release when
some new major feature is mature enough. If these features come out
often enough, we end up with a lot of releases to support, and
supporting a lot of releases uses up a lot of time and effort.
Assuming that a lot more resources aren't going to magically appear,
perhaps the solution is to ramp down the level of support for
older releases.

7 - legacy (only gets fixes for security, panic/hang, data loss)
8 - supported (security, panic/hang, data loss bugs, plus others as requested)
9 - very supported (most improvements that aren't massively disruptive)
stable - not quite bleeding edge, not a "release" yet, not recommended
for production, brave users can try out new features
current - bleeding edge

The legacy level shouldn't have many fixes, so it shouldn't take
too much time and effort. It should be possible to support multiple
"legacy" releases. If fixes only get backported to "supported"
releases when users request it, the amount of time and effort may
(Continue reading)

Permalink | Reply |
headers
John Kozubik | 20 Jan 2012 00:13

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


On Wed, 18 Jan 2012, Dieter BSD wrote:

> John writes:
>> - EOL 7
>> - mark 8 as legacy
>> - mark 9 as the _only_ production release
>> - release 10.0 in January 2017
>
> Until a few days ago 8 was the latest, shinest release.
> So you want to suddenly demote it all the way down to legacy?
> I thought the goal was to have releases that can be used for a long time?

No, that's not quite what I meant.

I was speaking at the same time about the problem of having two concurrent 
"production" releases.

Since 9.0 is already released, you can't stop having two production 
releases with 8, since 9 is already here.

So i was saying *after* you continue the normal 8.x lifecycle (perhaps 
another 1 or 1.5 years, getting it to 8.5 *then* you make the drastic 
changes, which I showed in the list above.

So 8 would become legacy on the same schedule that it always had.  No 
changes there.  The change comes with 9 being the only production release, 
and 10.0-RELEASE being delayed.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
(Continue reading)

Permalink | Reply |
headers
Da Rock | 20 Jan 2012 08:32
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On 01/20/12 09:13, John Kozubik wrote:
>
>
> On Wed, 18 Jan 2012, Dieter BSD wrote:
>
>> John writes:
>>> - EOL 7
>>> - mark 8 as legacy
>>> - mark 9 as the _only_ production release
>>> - release 10.0 in January 2017
>>
>> Until a few days ago 8 was the latest, shinest release.
>> So you want to suddenly demote it all the way down to legacy?
>> I thought the goal was to have releases that can be used for a long 
>> time?
>
>
> No, that's not quite what I meant.
>
> I was speaking at the same time about the problem of having two 
> concurrent "production" releases.
>
> Since 9.0 is already released, you can't stop having two production 
> releases with 8, since 9 is already here.
>
> So i was saying *after* you continue the normal 8.x lifecycle (perhaps 
> another 1 or 1.5 years, getting it to 8.5 *then* you make the drastic 
> changes, which I showed in the list above.
>
> So 8 would become legacy on the same schedule that it always had.  No
(Continue reading)

Permalink | Reply |
headers
Adrian Chadd | 22 Jan 2012 08:45
Picon
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

Hi,

It's not an easy task to get "noticed". Well, no i lie - that's easy, start
submitting patches. Then you need to find someone who you can nag to get it
done. I've offered to a few people to include stuff - just keep nagging me.

Linux projects have the same problem, don't doubt it - but they have a
larger group of active people, generally looking after a very specific
corner of the world. If you want to join the fray and get a commit bit,
just be persistent and be willing to look after one specific corner of the
tree. Then you'll be responsible for dealing with others nagging you. :)

Getting to that point can take a bit of effort though. In terms of wifi, I
jumped in with both feet and asked a whole bunch of questions (and nagged a
whole lot of people) until I wrapped my head around things. This may or may
not be the way you work. :-) The trouble is it's just (mostly) me. It's a
little overwhelming, especially since I don't subscribe to the "copy
everyone elses' work and hope it works fine" method of working..

Adrian
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Permalink | Reply |
headers
Da Rock | 26 Jan 2012 12:45
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle


> On 01/20/12 09:13, John Kozubik wrote:
I normally hate to dredge up old threads, but this is like getting 
halfway through a story and not finding out the ending... :)

What is the answer? Is there a solution to this?

I have a string of questions on this:

1. Incidentally, what exactly does constitute a major release?

2. Is there a reason to update the numbers so quickly?

3. Could a higher bar be set to reach a major release than simply 
temporal objectives? One of the differentiating factors between linux 
and FreeBSD is the simple fact that linux distros tend to run so fast 
through the numbers- and while just a matter of perspective, it could 
provide some sense of stability to enterprise users. Weighed against, of 
course, the ability to upgrade easily.

4. If in the case of the former, could some backporting to the stable 
and release branches facilitate an easy upgrade to the next major release?

5. Could binaries be the answer to easier upgrades (customised for 
enterprise users)?

I'd really like to know the OP's thoughts on this...

Cheers
_______________________________________________
(Continue reading)

Permalink | Reply |
headers
John Kozubik | 9 Feb 2012 07:33

Moving on ... (was: Re: FreeBSD has serious problems with...)


Hello,

On Thu, 26 Jan 2012, Da Rock wrote:

> I normally hate to dredge up old threads, but this is like getting halfway 
> through a story and not finding out the ending... :)
>
> What is the answer? Is there a solution to this?

When I wrote the original post, I was expecting at most a benign response, 
and at worst some real blowback ... but I was really pleasantly surprised 
to find that my complaints were very well received, and that a lot of 
folks were experiencing the same issues that I was.

It appears to be a classic case of "if one customer complains, 99 others 
are thinking the same thing".

> I have a string of questions on this:
>
> 1. Incidentally, what exactly does constitute a major release?

I was defining major releases to be 4.x, 5.x, 6.x ... and so on. 
Currently 9.x is the latest major release.

> 2. Is there a reason to update the numbers so quickly?

I didn't think so, which was one of the main points of my post.  A lot of 
other folks have agreed.  BUT there were some counter arguments - 
specifically that fully new features would be delayed for a much longer
(Continue reading)

Permalink | Reply |
headers
mdf | 9 Feb 2012 08:09
Picon
Favicon

Re: Moving on ... (was: Re: FreeBSD has serious problems with...)

On Wed, Feb 8, 2012 at 10:33 PM, John Kozubik <john <at> kozubik.com> wrote:
> If it were up to me, I think I would stake out a very loud and clear mission
> statement for FreeBSD that explicitly sacrifices new features for longer
> lifecycles and deeper investment in particular releases.  I've thought
> seriously about the points that were made in this thread supporting faster
> releases, and I do appreciate what we would be giving up, but I continue to
> advocate for a new major release every 5 years.

To summarize 7 years of working on AIX, where we upgrade the major
version number every 5 years or so, in the interim we do deliver
hundreds of other features.  However, if we made a poor choice for
interface, we're stuck with it.  This leads to two things: (1)
flexible interfaces, like leaving an unused flags field in a syscall
so it can become variadic later, and (2) flexible structures, like
leaving a few bytes in a struct that's part of the KBI so they can be
filled in, and when that space is nearly out, malloc(9) more storage
to hang off the struct.  Sometimes this means a lot of extra testing
effort to ensure the legacy interface works as well as any extensions
that arise later.

It's not ideal, it's more work when designing and testing, and when a
major release does come around where we could break binary
compatibility, we've often forgotten about a lot of these little bits
and just leave things the way they  are.  With a more frequent release
cycle FreeBSD can be more free about breaking KBI and ABI, and even
the [AK]PI, which keeps the current code clean but makes upgrading
more difficult.

It's a hassle.  It's doable, but it adds work, and that's a tough call
to make for a volunteer effort.  Increasing the barrier to entry, or
(Continue reading)

Permalink | Reply |
headers
rank1seeker | 14 Feb 2012 18:18
Picon

9.0 observations

--------
OpenSSH:
--------
After taking advantage of new 'KexAlgorithms'
# sshd -T | grep KexAlgorithms
    will never show it ...


-----
WiFi:
-----
'media OFDM/54Mbps' breaks setup (supplied to 'ifconfig wlan0').
'ucastrate' and 'mcastrate' will set it instead.


-----
gpart
-----

On a MD vnode bassed image, of size:

1g or 2g:
    # gpart create -s MBR md0
        Will create starting offset at 63 sector
=>     63  2097089  md0  MBR  (1.0G)
=>     63  4194241  md0  MBR  (2.0G)

1432m:
    # gpart create -s MBR md0
        Will create starting offset at 33 sector
(Continue reading)

Permalink | Reply |
headers
Da Rock | 9 Feb 2012 14:23
Picon

Re: Moving on ...

On 02/09/12 16:33, John Kozubik wrote:
>
> Hello,
>
> On Thu, 26 Jan 2012, Da Rock wrote:
>
>> I normally hate to dredge up old threads, but this is like getting 
>> halfway through a story and not finding out the ending... :)
>>
>> What is the answer? Is there a solution to this?
>
>
> When I wrote the original post, I was expecting at most a benign 
> response, and at worst some real blowback ... but I was really 
> pleasantly surprised to find that my complaints were very well 
> received, and that a lot of folks were experiencing the same issues 
> that I was.
>
> It appears to be a classic case of "if one customer complains, 99 
> others are thinking the same thing".
I was interested from the perspective of what would make FreeBSD a 
bigger player on the enterprise level of the market. I know ISP's and 
large organisations are not as concerned with "off the shelf" as much as 
scalability, automation and customisation, and so don't mind running a 
minor dev team/person to achieve what they want; but smaller 
organisations would rather have it just work without much input or 
technical ability. I don't know what it is like where you are, but here 
even larger organisations are biased in this way- even up to a 
government level (outsource!).
>> I have a string of questions on this:
(Continue reading)

Permalink | Reply |
headers
Mark Linimon | 18 Feb 2012 23:16

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

On Thu, Jan 26, 2012 at 09:45:47PM +1000, Da Rock wrote:
> 1. Incidentally, what exactly does constitute a major release?

That point in time where we guarantee that we break a certain degree
of backwards compatibility.  (Well, that's the key component.  Feature-
additions ride on top of that.)

> 2. Is there a reason to update the numbers so quickly?

Yes, so that we don't have to keep supporting backwards compatibility
for as long a period (see 1) -- it's a significant burden to maintain.
It's necessary to do these as we rework things like network layers for
higher performance, rework wireless to work with modern devices, and
other high-demand items.

> 3. Could a higher bar be set to reach a major release than simply
> temporal objectives?

Yes.  We did that with 5.x, and blew it big-time.  The goal of "rewrite
the entire system to support SMP in a scalable, reliable fashion" was
simply too aggressive.  It led to ~5 years between major releases, and by
that time the system had changed very dramatically (SMP, suspend/resume,
IIRC GEOM, and too many other things to list).  It was a huge jump and
the learning curve for upgrading was way too large.  We lost userbase.

Also, keeping 5 years between major releases led to very high developer
frustration.  Why work on something when it will take 4+ years to even
see the light of day?

This is why we moved to the time-based releases.  18 months was seen as
(Continue reading)

Permalink | Reply |
headers
Super Bisquit | 19 Feb 2012 00:28
Picon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

The individual maintainers of each architecture have the right to make
a "PRE-RELEASE" of the system at any time.  Come to think of it,
anyone who can has that right- that is to make a pre-release.

On 2/18/12, Mark Linimon <linimon <at> lonesome.com> wrote:
> On Thu, Jan 26, 2012 at 09:45:47PM +1000, Da Rock wrote:
>> 1. Incidentally, what exactly does constitute a major release?
>
> That point in time where we guarantee that we break a certain degree
> of backwards compatibility.  (Well, that's the key component.  Feature-
> additions ride on top of that.)
>
>> 2. Is there a reason to update the numbers so quickly?
>
> Yes, so that we don't have to keep supporting backwards compatibility
> for as long a period (see 1) -- it's a significant burden to maintain.
> It's necessary to do these as we rework things like network layers for
> higher performance, rework wireless to work with modern devices, and
> other high-demand items.
>
>> 3. Could a higher bar be set to reach a major release than simply
>> temporal objectives?
>
> Yes.  We did that with 5.x, and blew it big-time.  The goal of "rewrite
> the entire system to support SMP in a scalable, reliable fashion" was
> simply too aggressive.  It led to ~5 years between major releases, and by
> that time the system had changed very dramatically (SMP, suspend/resume,
> IIRC GEOM, and too many other things to list).  It was a huge jump and
> the learning curve for upgrading was way too large.  We lost userbase.
>
(Continue reading)

Permalink | Reply |
headers
Alexander Leidinger | 19 Jan 2012 13:22
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

Hi,

yesterday I wrote some words in my how we could put the power how long a branch lives a little bit more into he
hands of the users. It's available at http://www.leidinger.net/blog/ and also has some sentences how we
could improve our knowledge about what bugs our users the most.

Maybe it gives some ideas to some people.

Bye,
Alexander.

--

-- 
Send via an Android device, please forgive brevity and typographic and spelling errors. 

"Matthew D. Fuller" <fullermd <at> over-yonder.net> hat geschrieben:On Wed, Jan 18, 2012 at 02:20:56PM
-0600 I heard the voice of
Mark Felder, and lo! it spake thus:
> On Wed, 18 Jan 2012 13:46:45 -0600, John Kozubik <john <at> kozubik.com> wrote:
> > This is nice because no upheaval needs to happen with 7 and 8, and
> > interested developers do not get kneecapped vis a vis 9 - they can
> > just  keep going where they were going with it, and the only real
> > change is  that 10 is pushed out a long ways, and people[1] get to
> > really sink  their teeth into 9.
> >
> 
> What are the policies for changes though? Are we stuck with 9.0's
> feature  set for 5 years? Will we have to wait 5 years to get a
> stable release of  FreeBSD with KMS/GEM? That work is unfinished and
> didn't make 9.0; it's  also a huge changeset. How will things like
> this be dealt with? Five years  is a long time for the next stable
(Continue reading)

Permalink | Reply |
headers
Alexander Leidinger | 20 Jan 2012 11:51
Favicon

Re: FreeBSD has serious problems with focus, longevity, and lifecycle

Hi,

I think some tools could help here. If users are able to submit patches to branches they are interested in and
some automatic compile/style/whatever testing for them, it would already help. See
http://www.leidinger.net/blog/ for a more detailed explanation of this.

Bye,
Alexander.

-- 
Send via an Android device, please forgive brevity and typographic and spelling errors. 

Adrian Chadd <adrian <at> freebsd.org> hat geschrieben:.. and people _do_ realise that this is all mostly
driven by volunteers,
right?

The companies/individuals that _could_ run this kind of thing do it
internally. So you're left with volunteers doing the public releases
instead of the vendors who are asking for it.

Honestly, I think the re <at>  and ports building teams would _love_ some help.
If you'd like to see this happen, step up and offer your assistance. That's
the most likely way to achieve your goal.

Adrian
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
(Continue reading)

Permalink | Reply |

Gmane