Re: Upcoming Releases Schedule... - FreeBSD

This is a discussion on Re: Upcoming Releases Schedule... - FreeBSD ; >>> Where can one find the expected EoL for these releases? > On Wed, Sep 03, 2008 at 09:24:04PM -0700, Nathan Way wrote: >> http://www.freebsd.org/security/secu...orted-branches >> To quote from the above web site: (snip) On Sep 4, 2008, at 6:36 ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 31

Thread: Re: Upcoming Releases Schedule...

  1. Re: Upcoming Releases Schedule...

    >>> Where can one find the expected EoL for these releases?

    > On Wed, Sep 03, 2008 at 09:24:04PM -0700, Nathan Way wrote:
    >> http://www.freebsd.org/security/secu...orted-branches
    >> To quote from the above web site: (snip)


    On Sep 4, 2008, at 6:36 AM, Wesley Shields wrote:
    > These are the existing releases. I believe Jo was looking for EoL for
    > 7.1 and 6.4 once they are released.


    Yes, thank you.

    > The answer to that is not clear -
    > nor do I know if it should be clear yet. I don't know when the type
    > of
    > support decision is made, but I suspect it's not this early in the
    > process.



    The release date for 6.4 is ~30 days away, isn't it?

    Also given that we've previously seen overlaps such that a newer
    version is only supported to the same EoL as the older version, that
    would pretty much dictate that spending resources on testing 6.4-REL
    and/or upgrading would be futile.

    To go back to the original statements made at the time: "you should
    consider the lifetime of the release before you invest resources in
    it". That means we need to know the lifetime to determine how much
    resources to apply to testing it, yes?

    --
    Jo Rhett
    Net Consonance : consonant endings by net philanthropy, open source
    and other randomness


    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  2. Re: Upcoming Releases Schedule...

    Jo Rhett wrote:
    > Because frankly we're going to be forced to run our own internal
    > release management process instead.
    > I guess this is not surprising, as this appears to be what every other
    > business using significant amounts of freebsd in production are doing
    > today.


    I'm afraid you've hit the nail on the head. Stable, Current, these
    words mean nothing to me anymore, I'm using 8-CURRENT to get stable ZFS
    with the ata driver from 7 (because 8's doesn't work), and the old BTX
    loader because the new one locks up on all my newer hardware.

    Then there's the bag of patches I am now carrying around from release to
    release, some for bug fixes and some for feature enhancements, none of
    which are in the base system for whatever reason.

    I think FreeBSD is getting in a difficult position now because there's
    so much cool new stuff being shoe-horned in, but without the necessary
    volume of contributors to back it up with testing and bug fixes.

    There's some truth to what you say, in that I would love to be directly
    contributing to the FreeBSD effort but instead I feel I'm running around
    putting out little fires all the time. Plus this era of 4 to 8 CPU
    cores has meant I am seeing bugs that are difficult to pin down and only
    occur under production load.


    - Andrew
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  3. Re: Upcoming Releases Schedule...

    On Tue, Sep 16, 2008 at 04:30:26PM +1000, Andrew Snow wrote:
    > I think FreeBSD is getting in a difficult position now because there's
    > so much cool new stuff being shoe-horned in, but without the necessary
    > volume of contributors to back it up with testing and bug fixes.


    We're interested in suggestions about how to get more people involved
    with testing and bug fixes.

    There's certainly no lack of demand for the features -- all the way from
    running on inexpensive wireless routers all the way up to 'enterprise-
    grade' distributed storage solutions. (These are real examples from
    various mailing lists.)

    So, in your opinion, what's the way to reconcile all these demands
    (features + stability + long-term support of release branches) with
    a group that is 95%-plus volunteer effort?

    mcl
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  4. Re: Upcoming Releases Schedule...

    Mark Linimon wrote:
    > So, in your opinion, what's the way to reconcile all these demands
    > (features + stability + long-term support of release branches) with
    > a group that is 95%-plus volunteer effort?


    Its important to me that people keep using FreeBSD. Numbers are
    important. To that end I'm happy for developers to keep working hardest
    on the parts of FreeBSD they find most rewarding. Something's got to
    give and you can't stop it by creating more beaurocracy and red tape.

    Another thing I think is important is for new hardware to be perpetually
    sent to those who can implement drivers and create patches. I don't
    feel the FreeBSD foundation is doing enough in that regard. Not talking
    about big ticket items like server farms, just new motherboards every
    time a new CPU or chipset is released.


    - Andrew
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  5. Re: Upcoming Releases Schedule...

    On Tue, Sep 16, 2008 at 06:51:32PM +1000, Andrew Snow wrote:
    > Mark Linimon wrote:
    >> So, in your opinion, what's the way to reconcile all these demands
    >> (features + stability + long-term support of release branches) with
    >> a group that is 95%-plus volunteer effort?

    >
    > Its important to me that people keep using FreeBSD. Numbers are
    > important. To that end I'm happy for developers to keep working hardest
    > on the parts of FreeBSD they find most rewarding. Something's got to
    > give and you can't stop it by creating more beaurocracy and red tape.
    >
    > Another thing I think is important is for new hardware to be perpetually
    > sent to those who can implement drivers and create patches. I don't
    > feel the FreeBSD foundation is doing enough in that regard. Not talking
    > about big ticket items like server farms, just new motherboards every
    > time a new CPU or chipset is released.


    I agree with the last point. However, a couple counter-points:

    1) I believe this is what freebsd-donations@ is for (though I feel the
    Foundation as a whole could be helping more with this),

    2) Based on my own experience: I've offered to purchase new hardware
    to send developers (free of charge), assuming I can get my hands on
    whatever hardware it is they need. I'm willing to spend a few hundred
    dollars to get whatever it is they want, so financially I'm flexible.

    Here's my experience:

    What I'm finding out is that it's not the hardware developers need --
    it's the time required to sit down and test everything and write the
    code. No matter what we do, we cannot create more time (or in some
    cases, more incentives) for developers. What we ultimately need is more
    talent to make things better.

    There's a number of people I see doing really good work, at least with
    regards to RELENG_7 (I do not follow HEAD/CURRENT commits). From what I
    understand, all these folks are incredibly pressed for time. I'll name
    names, just because they deserve mention: rwatson, pjd, phk, jhb,
    alfred, kmacy, kris, kib, yongari, scottl, Andrey Elsukov, and Max
    Laier. I apologise if I've upset anyone by this -- I'm not naming names
    to "rank" people against others (it's a volunteer project after all),
    I'm just listing off people who I've seen do really good work over the
    past year or so, with regards to the few devices or kernel pieces I
    actively follow.

    For something as gargantuan/massive as an entire operating system and
    all of its device support, there's a very small number of central people
    doing regular work. Compare this to Linux, where you've got:

    a) 6-7 times the amount of kernel-people,
    b) Commercial interest and support from companies (that means developers
    are more likely to get documentation and development/test hardware from
    the vendor themselves),
    c) A significantly larger user-base for testing.

    I have never agreed with Eric Raymond's "bazaar" concept, where the
    attitude is "more eyes = overall better". The problem in our case is
    not lack of eyes, it's lack of hands and brains. We have a lot of smart
    people who aren't working on kernel-stuff because they lack the
    experience/knowledge of how to get involved, where to start, and overall
    understanding of the code. I'm one of those people, for example. I
    do not understanding threading (the concept yes, the implementation no),
    nor any "core" part of the kernel.

    The most common rebuttal to this argument is "Well, there's page> and ", but then when you try to follow either of them,
    are later told "yeah, is wrong, and is completely out of
    date, everything has changed". It's demoralising.

    I can sit down and within about 15-20 minutes have a minimum
    understanding of part of a C userland program. Comparatively, I have
    looked at kernel drivers for hours without any understanding of what
    numerous kernel ABI/API functions do, why they're being done, why
    they're being done when they are. I'm not even talking about
    device-specific semantics (e.g. what does this IC register do, etc.).
    I'm talking about the surrounding pieces. I *have* hacked on the em(4)
    driver, but all the surrounding pieces made me say "hmm, do not touch".
    Any time I see the words VFS, BIO, mtx, or uma, I back off.

    --
    | Jeremy Chadwick jdc at parodius.com |
    | Parodius Networking http://www.parodius.com/ |
    | UNIX Systems Administrator Mountain View, CA, USA |
    | Making life hard for others since 1977. PGP: 4BD6C0CB |

    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  6. Re: Upcoming Releases Schedule...


    Another thing that I believe would help: Voting on PRs.

    Currently a maintainer has no idea if a PR is due to one guy's flakey
    hardware or if 50 people have had the same problem and are waiting for a
    fix.

    For each major problem report, there are probably many people who tried
    FreeBSD on particular hardware and just silently gave up when it failed.

    Ability to "vote up" on a PR on the freebsd website would give
    maintainers a tool to see which PRs are affecting the userbase.


    - Andrew
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  7. Re: Upcoming Releases Schedule...

    Andrew Snow wrote:
    >
    > Another thing that I believe would help: Voting on PRs.
    >
    > Currently a maintainer has no idea if a PR is due to one guy's flakey
    > hardware or if 50 people have had the same problem and are waiting for a
    > fix.
    >
    > For each major problem report, there are probably many people who tried
    > FreeBSD on particular hardware and just silently gave up when it failed.


    You might even find that people don't even know what a PR is or how to
    report it. Maybe a dialog during the install telling people about the
    PR system might be helpful.

    >
    > Ability to "vote up" on a PR on the freebsd website would give
    > maintainers a tool to see which PRs are affecting the userbase.



    Andrew

    >
    > - Andrew
    > _______________________________________________
    > freebsd-stable@freebsd.org mailing list
    > http://lists.freebsd.org/mailman/lis...freebsd-stable
    > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  8. Re: Upcoming Releases Schedule...

    On Thu, Sep 18, 2008 at 02:46:09PM +0200, Wilko Bulte wrote:
    > Quoting Jo Rhett, who wrote on Wed, Sep 17, 2008 at 09:25:27PM -0700 ..
    > > On Sep 17, 2008, at 4:33 PM, Robert Watson wrote:
    > > > An important factor is whether or not we consider the release a
    > > > highly maintainable release, and while we have intuitions at the
    > > > time of release, that's something we can only learn in the first
    > > > couple of months after it's in production. I don't know of any COTS
    > > > software house that really does it any differently

    > >
    > > I understand what you mean, but the statement is blatantly false as
    > > stated. Anyone selling software to the US Government *must* specify
    > > (or meet, depending) a minimum support period, and must also specify a
    > > cost the agency can pay to extend the support period.
    > >
    > > Not relevant to FreeBSD -- just qualifying the statement as it
    > > stands. For the obvious comparison, Solaris versions have well-
    > > published release and support periods, usually upwards of 8 years.
    > > Obviously they have more resources to do this, I'm just pointing out
    > > that the statement you made is incorrect as stated.
    > >
    > > > and I'm not sure you could do it differently -- no one plans to ship
    > > > a lemon, but once in a while you discover that things don't go as
    > > > planned.

    > >
    > >
    > > I am amazed at the preposterously large elephant in the room that none
    > > of you are willing to address. Watching each of you dance around it
    > > would be terribly funny if it didn't affect my job so badly. (and if
    > > I wasn't going to have to bail on FreeBSD and go to some crap form of
    > > Linux because the FreeBSD developers appear to be unwilling to
    > > consider the idea of getting more help)

    >
    > You seem to be *demanding* quite a lot lately.


    Jo has a point, though. I'm certain he's looked at the situation from
    the developers' point of view, and in response, I'd recommend others
    try to look at it from his, even if others consider it silly or
    unreasonable.

    It's a frustrating situation, and there's no snap-your-fingers-voila
    solution for it, other than extending support lifetimes per release.
    Mark's graphs show release lifetimes are getting shorter, which I doubt
    Jo would have a problem with, assuming each new release was somehow
    guaranteed (more or less, cut me some slack) to not break previous
    releases' binaries and so on.

    --
    | Jeremy Chadwick jdc at parodius.com |
    | Parodius Networking http://www.parodius.com/ |
    | UNIX Systems Administrator Mountain View, CA, USA |
    | Making life hard for others since 1977. PGP: 4BD6C0CB |

    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  9. Re: Upcoming Releases Schedule...

    On Sep 18, 2008, at 5:46 AM, Wilko Bulte wrote:
    > You seem to be *demanding* quite a lot lately.



    I have demanded nothing. I have made a suggestion or two -- presented
    the background which pretty much everyone agrees with, made some
    suggestions about how to improve it.

    My last post was expressing amusement about watching every developer
    dance around the topic, skipping over the relevant part -- how do we
    improve things?

    We could improve things. We could get more resources. Why not
    consider the topic?

    That's not demanding. Check your dictionary.

    --
    Jo Rhett
    Net Consonance : consonant endings by net philanthropy, open source
    and other randomness


    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  10. Re: Upcoming Releases Schedule...

    On Sep 18, 2008, at 2:03 PM, Mike Tancsa wrote:
    > I had a search and I see some PRs you have submitted, but I guess
    > you commit under a different @freebsd.org email address ?


    I don't commit. I submit and others commit. This hasn't really been
    a handicap ;-)

    > Thats most excellent! I think people would take your suggestions
    > with greater gravity if you reminded them with a few URLs to point
    > out the various commit messages that say, "sponsored by
    > netconsonance" etc. Or perhaps a few of these numerous developers
    > could speak up on your behalf?


    Again, netconsonance is "Jo" and a few random others that contract via
    the company to avoid having to create their own company. The "We" in
    most of my discussions is my $EMPLOYER. And you can see their logos
    and name listed in numerous places.

    >> We pay for development of features that
    >> we need but don't have the appropriate skills to fix ourselves.

    >
    > That then went back into FreeBSD ? Can you give examples ? I
    > ask all this as you really, really want things to change, and you
    > say you have \


    I'm sorry, but I have neither the time nor the interest in trying to
    provide a FreeBSD resume to someone. This is a tangent, and never in
    my experience has a tangent moved the original discussion forward.

    Are you in a position to make changes? What role in this do you
    have? What value is there answering these questions?
    (which have been answered many times if you google for them)

    I'd rather just drop this tangent.

    --
    Jo Rhett
    Net Consonance : consonant endings by net philanthropy, open source
    and other randomness


    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  11. Re: Upcoming Releases Schedule...

    On Thu, Sep 18, 2008 at 12:23:45PM -0700, Jo Rhett wrote:
    > On Sep 18, 2008, at 12:01 PM, Robert Watson wrote:


    > > (1) Become a contributor to the community by developing and
    > > maintaining patches against unsupported branches, especially against
    > > older releases such as 4.x and 5.x where the branches are open for
    > > commits but have fallen out of support status. I can't promise the
    > > results will

    >
    > We have no 4.x or 5.x systems nor do we have any interest in
    > maintaining those. So perhaps a good idea, but not something I can
    > help with.
    >
    > I *did* offer to work on maintenance for 6.2, but was told it would be
    > rejected by the developers. Would I extend effort to do exactly what
    > I am talking about -- extending the support lifetime for very recent
    > releases? Absolutely. If its in a form useful for the community as a
    > whole.
    >
    > If I have to do this on my own (what we are doing internally now) then
    > the FreeBSD community leverages nothing from the effort, and we're not
    > changing the resources limitations at all.


    I don't have a dog in this fight. I'm just writing this message because
    it looks to me like there is a lot of talking past one another going on
    between people who are basically in violent agreement with one another.
    I am hoping that wording things differently will lead to understanding
    on both sides. I may have completely misinterpreted both sides. Spoken
    languages are too ambiguous.

    Here is the boiled down gist of my interpretation of a possible way to
    go forward with this; bad pseudo code:

    RESOURCES='Jo and the others he seems to know of who back port fixes to
    their production versions of "unsupported" versions of FreeBSD.'

    For i in "RELENG_X_Y" (where X_Y is not a currently "supported" version of FreeBSD); do
    grant maintenance commit access for $i to ${RESOURCES}
    done;

    Now for the code documentation:

    Maybe one of the ${RESOURCES} could build some web application whereby
    people could sign up to be a "community extended support" resource for
    RELENG_X_Y until $date_in_the_future. Perhaps a letter of commitment
    from ${RESOURCE}s ${EMPLOYER} would be required before accepting the
    candidate for work on RELENG_X_Y.

    Then the existing developers or core team could approve their
    application/access and provide a mentor if they aren't currently
    commiters. (This is some extra work for the existing people. But
    hopefully the rewards would be worth the minimal? effort.)

    Eventually, the mentor pool could be wholly from ${RESOURCES}. Much
    of the approval of new candidates would be from the same pool. The
    whole thing might have to be conditional on ${RESOURCES} bringing the
    necessary tinderbox type hardware to do basic QA on their extended
    support branches. With enough ${RESOURCES} signed up, they might be
    able to get hardware from ${DONORS} other than themselves.

    The ${RESOURCES} people could gang up on which RELENG_X_Ys they want to
    support. They can support them for as long as they have people on the
    team who are interested in supporting them. Presumably, these people
    would be working for companies which have made a commitment to use
    RELENG_X_Y for N years.

    In this way, the companies which are already paying their people to
    apply security fixes to old releases can donate the work which is
    already being done back to the project. Hopefully they will end up
    sharing the load so that they reap the benefits of work done by other
    companies which are paying people to do the same things.

    So long as the requirements for a back port to the ${RESOURCES}
    supported branches are the same as to an officially supported branch,
    there shouldn't be much chance of harm. Perhaps they are only allowed
    to back port fixes which have been approved for a supported RELENG_X_Y.

    Eventually, if enough ${RESOURCES} sign up, they might be able to
    release X.Y.z distribution media. If they only provide the media for
    CD/DVD purchase, the revenue might help to provide for QA tinderboxes
    for the ${RESOURCES} supported work.

    We might even end up with more people who are familiar with the release
    process and volunteer to work on RELENG_X_Y from initial release all
    the way through normal end of support and into the community extended
    support period.

    I think that would provide, as much as is possible, for the "don't make
    extra work for the existing developers" requirement as well as giving
    these resources a way to "put up or shut up." I could be wrong.

    --
    Scott Lambert KC5MLE Unix SysAdmin
    lambert@lambertfam.org

    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  12. Re: Upcoming Releases Schedule...

    Quoting Jo Rhett, who wrote on Thu, Sep 18, 2008 at 11:58:00AM -0700 ..
    > On Sep 18, 2008, at 5:46 AM, Wilko Bulte wrote:
    > > You seem to be *demanding* quite a lot lately.

    >
    >
    > I have demanded nothing. I have made a suggestion or two -- presented
    > the background which pretty much everyone agrees with, made some
    > suggestions about how to improve it.
    >
    > My last post was expressing amusement about watching every developer
    > dance around the topic, skipping over the relevant part -- how do we
    > improve things?


    > We could improve things. We could get more resources. Why not
    > consider the topic?
    >
    > That's not demanding. Check your dictionary.


    I do not need a dictionary thank you very much.

    Wilko
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  13. Re: Upcoming Releases Schedule...

    At 05:46 PM 9/18/2008, Jo Rhett wrote:

    >I'd rather just drop this tangent.



    Me too.

    ---Mike

    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  14. Re: Upcoming Releases Schedule...

    Hi,

    Jo Rhett wrote:
    > I agree with pretty much everything you've said here, with the obvious
    > exception that I don't know what's involved in the release management
    > process to do as you've said.
    >
    > Also for my own self, rather than resurrect 6.2 I'd personally rather
    > focus on what we could do to extend the support period for 6.4. And
    > other releases going forward.

    If you want extended support period, you should go for 7.1
    If I remember correctly .1 REL is supposed to be the target for all
    binary programs/drivers.

    But if your target is not only security fixes, but drivers (included in
    base) and new features then release is not working for you, right?
    Because new drivers are never back-ported to release, best they go to
    -stable, but you are not tracking -stable?
    As I understand if you track stable then you really do not care about
    the numbers after the dot - you are using just 6.x or 7.x (or 8.x in
    future)
    And 7-stable will not reach EOL at least next 4-5 years.

    Sorry if you already answer this, but the thread is very long and it's
    hard to track every mail in it.

    My simple question is how you plan to benefit if 7.1 have extended EOL?
    You will stick with 7.1Release (RELENG_7_1) and security patches, or to
    (RELENG_7) - which include new drivers?

    I'm asking because you said, that the main problem with EOL is not
    fixing bugs which you can do fine, but new drivers that are not back-ported.
    How you think this can be solved? Most business user do not want new
    driver to be masked as security update?

    --

    Best Wishes,
    Stefan Lambrev
    ICQ# 24134177

    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  15. Re: Upcoming Releases Schedule...

    On Thu, 18 Sep 2008, Jo Rhett wrote:

    > Thank you. If you don't mind I'd prefer to widen the scope a touch because
    > 6.2 will eventually go away, and frankly it is probably better to look
    > forward than to resurrect an unsupported version. So I would probably
    > state:
    >
    > Jo's $EMPLOYER has significant interest in longer support for -REL versions.
    > Enough to fund my time supporting the mainstream project. What would Jo (or
    > anyone else in a similar situation) need to bring to the table in order to
    > provide back to the project?


    This is the same answer I gave Lowell, but let me expand on it slightly. Our
    community grants rights (read also: responsibilities) on the basis of
    credibility in the community. Here's a possible plan:

    In the first stage, you need to establish credibility with the community as
    someone able and willing to do the work. You can do this by doing hard bits
    of the work without getting "official" sanction by creating an "Unofficial
    security and errata support for EoL'd FreeBSD releases" web page. Be very
    careful to scope the work so that you're not over-committing and there's no
    misunderstanding of what you're trying to do. Flag certain branches as "in
    support", and for each of those branches, provide pointers to the security
    advisories and errata patches that you've backported. If you take a branch
    out of support for your page (are no longer interested in maintaining it),
    keep the old stuff around for historical reasons, but clearly marked as
    historical rather than active.

    This will allow you to gain experience in maintaining security and errata
    patches for FreeBSD branches (more different than you might think from
    maintaining patches locally), establish credibility with the community as a
    whole, but in particular with the FreeBSD developers who are responsible for
    doing similar work for supported branches. This in turn may convince them
    that they should invest their time in mentoring you for a FreeBSD commit bit,
    and potentially join the security or release engineering teams once you've
    established that you are a member of the developer team who works well with
    others, does good technical work, and who is in it for the long haul.

    Some downsides to this approach:

    (1) It doesn't give the immediate gratification of seeing the official support
    status extended for releases. However, as you say, you're already doing
    the work.

    (2) You don't gain early access to confidential vulnerability information as a
    member of the security team, so (a) you can't have the patches ready in
    advance of the advisory, and (b) if there are reports of vulnerabilities
    in versions you support but the FreeBSD security team doesn't, you might
    not receive it in a timely manner.

    However, it accepts the way the project works: we don't provide access to our
    CVS (SVN) repository to people unless they have a mentor willing to propose
    them, and that mentor has to argue on the basis of a proven track record that
    the contribution you will make justify commit access to the tree. Likewise,
    we don't grant membership to the security team to committers unless they've
    shown a longer term commitment even than required for a commit bit, shown
    specific interest and commitment to security support issues, and that have
    they confidence of the security team that will be able to work with
    appropriate discretion in protecting the confidential and often critical
    security information we receive.

    Don't take this as a personal slight -- none of this says you aren't able to
    work with others, that you don't have the technical skills, that you don't
    have the time, aren't willing to make the commitment, or that you lack
    adequate discretion. Rather, it's saying that the way we evaluate people for
    participation in the project is that they have a track record of these things
    in the community. In a largely online and volunteer community, that's the way
    it works.

    Robert N M Watson
    Computer Laboratory
    University of Cambridge
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  16. Re: Upcoming Releases Schedule...

    >From what I've gathered so far...

    | By Jo Rhett
    | [ 2008-09-20 02:46 +0200 ]
    > To get a business to commit resources to a project there must be an
    > actual goal.


    [1] The FreeBSD project would have to commit resources too. Its community
    that provides those resources need to see tangible work that is useful to
    the project before committing any resources to it.


    > And to reach that actual goal there must be both (a) a
    > plan to get there, (b) a reasoned assessment of the effort involved,
    > etc etc and (z) the effort taking place to reach that goal.


    For (a), (b), and (z), this is where you come in. Define the goal. Make a
    plan to get there. Assess the effort involved. Convince your employer that
    (a), (b) and (z) is worth it to him/her and that the result of (z) will
    convince the FreeBSD project to commit the resources needed to integrate it.
    If they're happy, start working on (z) and bring it to the FreeBSD project
    when you think it's ready.

    If the FreeBSD project has to be involved in (a), (b), or (z), it will
    have to commit its own resources to the effort. See [1].

    Just my humble observation as a fellow FreeBSD user...


    Regards,
    Aragon
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  17. Re: Upcoming Releases Schedule...


    On Sep 19, 2008, at 7:07 PM, Aragon Gouveia wrote:
    >> To get a business to commit resources to a project there must be an
    >> actual goal.

    >
    > [1] The FreeBSD project would have to commit resources too. Its
    > community


    Of course. This is what the requirements analysis is ;-)

    > For (a), (b), and (z), this is where you come in. Define the goal.
    > Make a
    > plan to get there. Assess the effort involved. Convince your
    > employer that
    > (a), (b) and (z) is worth it to him/her and that the result of (z)
    > will
    > convince the FreeBSD project to commit the resources needed to
    > integrate it.
    > If they're happy, start working on (z) and bring it to the FreeBSD
    > project
    > when you think it's ready.



    Of course. If this was something that could be done without working
    with the freebsd developers, do you think I would put up with this
    kind of abuse? I'd much rather have something I could just go and
    do ;-)

    The issue is that nobody is willing to answer the question: "what
    resources are too limited to provide longer support? How can we help?"

    This the elephant that everyone ignores. To develop a plan, you need
    to know the limitations. Once those are spelled out, you sit down and
    try to determine what resources are necessary to achieve a certain
    goal. Then you find those resources, etc etc...

    Without input from the current release team extending the support
    schedule is not possible.

    --
    Jo Rhett
    Net Consonance : consonant endings by net philanthropy, open source
    and other randomness


    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  18. Re: Upcoming Releases Schedule...

    On Fri, Sep 19, 2008 at 10:38 PM, Jo Rhett wrote:
    >
    > On Sep 19, 2008, at 7:07 PM, Aragon Gouveia wrote:
    >>>
    >>> To get a business to commit resources to a project there must be an
    >>> actual goal.

    >>
    >> [1] The FreeBSD project would have to commit resources too. Its community

    >
    > Of course. This is what the requirements analysis is ;-)
    >
    >> For (a), (b), and (z), this is where you come in. Define the goal. Make
    >> a
    >> plan to get there. Assess the effort involved. Convince your employer
    >> that
    >> (a), (b) and (z) is worth it to him/her and that the result of (z) will
    >> convince the FreeBSD project to commit the resources needed to integrate
    >> it.
    >> If they're happy, start working on (z) and bring it to the FreeBSD project
    >> when you think it's ready.

    >
    >
    > Of course. If this was something that could be done without working with
    > the freebsd developers, do you think I would put up with this kind of abuse?
    > I'd much rather have something I could just go and do ;-)
    >
    > The issue is that nobody is willing to answer the question: "what resources
    > are too limited to provide longer support? How can we help?"
    >


    Jo, I think this is the clearest way you have stated your point yet, and
    it is quite definitely the crux of the issue:
    What resources does re@ not have, that releases are supported
    for these short times? I have never run a release, so I can't be much
    more specific that ``man-hours'' -- someone else should chime in
    and say what those hours would be spent on, if they were there.
    I think this is a great opportunity for the project, and a few pointers
    for how one could maintain an independent support of older releases
    would give the rest of us a great resource.


    -Ben Kaduk
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  19. Re: Upcoming Releases Schedule...

    2008/9/20 Jo Rhett :
    >
    > On Sep 19, 2008, at 7:07 PM, Aragon Gouveia wrote:
    >>>
    >>> To get a business to commit resources to a project there must be an
    >>> actual goal.

    >>
    >> [1] The FreeBSD project would have to commit resources too. Its community

    >
    > Of course. This is what the requirements analysis is ;-)
    >
    >> For (a), (b), and (z), this is where you come in. Define the goal. Make
    >> a
    >> plan to get there. Assess the effort involved. Convince your employer
    >> that
    >> (a), (b) and (z) is worth it to him/her and that the result of (z) will
    >> convince the FreeBSD project to commit the resources needed to integrate
    >> it.
    >> If they're happy, start working on (z) and bring it to the FreeBSD project
    >> when you think it's ready.

    >
    >
    > Of course. If this was something that could be done without working with
    > the freebsd developers, do you think I would put up with this kind of abuse?
    > I'd much rather have something I could just go and do ;-)
    >
    > The issue is that nobody is willing to answer the question: "what resources
    > are too limited to provide longer support? How can we help?"
    >
    > This the elephant that everyone ignores. To develop a plan, you need to
    > know the limitations. Once those are spelled out, you sit down and try to
    > determine what resources are necessary to achieve a certain goal. Then you
    > find those resources, etc etc...
    >
    > Without input from the current release team extending the support schedule
    > is not possible.
    >
    > --
    > Jo Rhett
    > Net Consonance : consonant endings by net philanthropy, open source and
    > other randomness
    >
    >
    > _______________________________________________
    > freebsd-stable@freebsd.org mailing list
    > http://lists.freebsd.org/mailman/lis...freebsd-stable
    > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
    >


    I have been following this thread for a while now and I've only
    recently used FreeBSD for the past 1-2 years, so my experience is not
    so great.

    But from what I've gathered from reading the mailing lists during the
    EOL of 4.11, the limited resources are

    >From Kernel Space

    - Security patches
    - Drivers (sometimes back porting a 7.x driver to 6.x isn't possible
    because if missing API or limited API calls that are only available to
    newer kernels)

    Base/Core Software
    - Security Patches

    Ports (I think the biggest issue in maintaining support)
    - Ports maintainers have to keep patches for every RELENG thats
    available. Previously they had to maintain compatibility with 3-4
    branches (i can't remember), 4.x, 5.x, 6.x, 7.x. and there is alot
    (10,000+) ports.
    - At the moment there is two (i think) 6.x and 7.x, and possible mid
    next year (2009) there will be 3 (8.x).
    - Some ports didn't work with 4.x due to missing API calls as well and
    had to be marked broken if they tried to compile it on a 4.x. This
    will eventually happen when FreeBSD reaches 8 or 9 and 6 will not have
    the API calls required.

    >From what I gather, those are the main points in maintaining extended support.


    How long are you expecting support for a RELENG to last, 1, 2, 3
    years? 5 years? (comparison, Ubuntu LTS is 3 years, security updates)
    Are you after support for a RELENG_X or RELENG_X_Y?
    What are you expecting from the support? Security only? Drivers? Ports?

    Please don't get me wrong, it is great that you and your company is
    willing to put the resources in, but its a huge undertaking
    maintaining a release. Maybe those questions might clarify to some
    FreeBSD Developers what you're asking from them.

    NB: I'm not a FreeBSD developer, but a very happy user that maintains
    FreeBSD servers for business clients.

    Regards
    David N
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  20. Re: Upcoming Releases Schedule...

    On Fri, Sep 19, 2008 at 07:38:32PM -0700, Jo Rhett wrote:
    > Without input from the current release team extending the support
    > schedule is not possible.


    Inquiry - is release team the constraint?

    Or to put it another way, what to you is "support" in terms of
    FreeBSD releases?

    As far as I am aware, if you stick on a RELENG_X_Y_Z_RELEASE tag
    then the most you get is security fixes. No new features,
    no new drivers, no bugfixes. So if I am interpreting things
    correctly, you are asking for security fixes to be ported to
    RELEASE tagged branches for longer?

    So is release team the contrained resource in your problem?
    I am not denying that *any* part of the FreeBSD team is not
    resource constrained, but I'm wondering if you're examining
    the correct area.

    Note: I am not up on the internals of modern FreeBSD
    release engineering and maintenance nor the relationship
    between "staff" functions, so I may be barking up the wrong
    telephone pole.

    Regards,

    Gary

    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


+ Reply to Thread
Page 1 of 2 1 2 LastLast