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.)
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 lini...@lonesome.com wrote:
On Thu, Jan 26, 2012 at 09:45:47PM +1000, Da
On 27 Jan 2012, at 03:26, Mark Linimon wrote:
On Thu, Jan 26, 2012 at 10:52:44PM +, 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.
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
On Thursday, January 19, 2012 4:33:40 pm Adrian Chadd wrote:
On 19 January 2012 09:47, Mark Saad nones...@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
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 nones...@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
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 nones...@longcount.org wrote:
What could I do to help make 7.5-RELEASE a
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
On 26 Jan 2012, at 22:49, Mark Linimon wrote:
On Thu, Jan 26, 2012 at 10:23:43PM +, 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.
On Thu, Jan 26, 2012 at 10:23:43PM +, 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
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 nones...@longcount.org wrote:
What could I do to help make 7.5-RELEASE a reality ?
Put your hand up and volunteer
On Thu, Jan 26, 2012 at 10:52:44PM +, 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
Hi,
On Wed, Jan 25, 2012 at 2:28 AM, Mark Linimon lini...@lonesome.com wrote:
I might just be also interested to review/comment code, discuss
regressions, and architecture, for a change ;-)
Unfortunately, such threads rarely ever happen. Most of the time, the
only food provided is a really
On Wed, Jan 25, 2012 at 9:58 AM, Arnaud Lacombe lacom...@gmail.com wrote:
Hi,
On Wed, Jan 25, 2012 at 2:28 AM, Mark Linimon lini...@lonesome.com wrote:
I might just be also interested to review/comment code, discuss
regressions, and architecture, for a change ;-)
Unfortunately, such threads
I might just be also interested to review/comment code, discuss
regressions, and architecture, for a change ;-)
Unfortunately, such threads rarely ever happen. Most of the time, the
only food provided is a really indigestible +5000/-3000 patch, where
all the thinking, architectural design and
On Wed, Jan 25, 2012 at 03:58:41AM -0500, Arnaud Lacombe wrote:
You seem to be obsessed by picking over
semantics and finding shortcomings to be aggreived over.
Semantics and proper, independent, API are crucial.
I'm talking about the semantics of the non-technical part: the wording
of
Hi,
On Wed, Jan 25, 2012 at 3:22 PM, Mark Linimon lini...@lonesome.com wrote:
On Wed, Jan 25, 2012 at 03:58:41AM -0500, Arnaud Lacombe wrote:
You seem to be obsessed by picking over
semantics and finding shortcomings to be aggreived over.
Semantics and proper, independent, API are
Mark Linimon lini...@lonesome.com pisze:
On Thu, Jan 19, 2012 at 08:07:43AM +0100, vermaden wrote:
I submit PRs and try to help test them as some developer/committer
will pick up the PR, submit a patch to test, but it was MANY times
that the response from developer/committer was way too
Hi,
Mark Linimon lini...@lonesome.com pisze:
We don't have a way to track emails that various users send to individual
maintainers. With a PR open, we have a way to do that. We also track
maintainer-timeouts, and these can eventually lead to a maintainer reset.
It is less a problem of
On 24 January 2012 18:36, Arnaud Lacombe lacom...@gmail.com wrote:
Hi,
Mark Linimon lini...@lonesome.com pisze:
We don't have a way to track emails that various users send to individual
maintainers. With a PR open, we have a way to do that. We also track
maintainer-timeouts, and these can
On 24 January 2012 18:36, Arnaud Lacombe lacom...@gmail.com wrote:
It is less a problem of having the tools than having the will to do
everything publicly. From experience, committers loves to do all kind
of things privately/secretly.
Perhaps it's human nature because of all the increasingly
Hi,
On Tue, Jan 24, 2012 at 4:10 PM, Mark Linimon lini...@lonesome.com wrote:
On 24 January 2012 18:36, Arnaud Lacombe lacom...@gmail.com wrote:
It is less a problem of having the tools than having the will to do
everything publicly. From experience, committers loves to do all kind
of things
On Tue, Jan 24, 2012 at 12:24:22PM +0100, vermaden wrote:
It would also be good to have some wiki.freebsd.org page that
would describe what information is needed to fill a good PR
See:
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/ .
Your suggestion to include things
On Tue, 24 Jan 2012 15:23:47 -0600
Mark Linimon lini...@lonesome.com wrote:
On Tue, Jan 24, 2012 at 12:24:22PM +0100, vermaden wrote:
It would be also good to have a wiki.freebsd.org page describing
what is needed and in what format a user should send the
documentation changes
Perhaps
It would also be good to have some wiki.freebsd.org page that
would describe what information is needed to fill a good PR
See:
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/
Thanks, I will read it.
I have now filled these PR's here:
On Wed, 25 Jan 2012 00:05:55 +0100
vermaden verma...@interia.pl wrote:
I have now filled these PR's here:
http://www.freebsd.org/cgi/query-pr.cgi?pr=164432
Thanks. This makes these issues visible.
One of them is already closed ... with ZERO changes,
the reason from the person that
Mike Meyer m...@mired.org pisze:
On Wed, 25 Jan 2012 00:05:55 +0100
vermaden wrote:
I have now filled these PR's here:
http://www.freebsd.org/cgi/query-pr.cgi?pr=164432
Thanks. This makes these issues visible.
One of them is already closed ... with ZERO changes,
the reason
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
On 2012-Jan-21 02:07:35 +0100, Daniel Gerzo dan...@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
On Thu, Jan 19, 2012 at 08:07:43AM +0100, vermaden wrote:
I submit PRs and try to help test them as some developer/committer
will pick up the PR, submit a patch to test, but it was MANY times
that the response from developer/committer was way too long that
I even DID NOT HAVE THE HARDWARE
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
On 01/22/12 15:49, Mark Linimon wrote:
As I type this, there are 1122 ports PRs (6272 total PRs). On most
days, around 40 come in.
How do you get that number? I ran a search on pr's and only came up with
around ~4k. Is there a trick I'm missing?
___
On 22 Jan 2012 12:05, Da Rock 9phack...@herveybayaustralia.com.au wrote:
On 01/22/12 15:49, Mark Linimon wrote:
As I type this, there are 1122 ports PRs (6272 total PRs). On most days,
around 40 come in.
How do you get that number? I ran a search on pr's and only came up with
around ~4k. Is
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
On 01/22/12 22:44, Chris Rees wrote:
On 22 Jan 2012 12:05, Da Rock9phack...@herveybayaustralia.com.au wrote:
On 01/22/12 15:49, Mark Linimon wrote:
As I type this, there are 1122 ports PRs (6272 total PRs). On most days,
around 40 come in.
How do you get that number? I ran a search on pr's
On Sun, Jan 22, 2012 at 11:15:09PM +1000, Da Rock wrote:
Scroll up and count the serious and critical bugs too :)
I didn't realise it broke the numbers into the sections.
Yeah. The problem is that, over time, the values in those fields has
become meaningless. Some of us try to triage what
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
On Tue, Jan 17, 2012 at 02:43:21AM +, 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
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
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.
--
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
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
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
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
2012/1/20 Gleb Smirnoff gleb...@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
On 18 January 2012 17:13, Daniel Eischen deisc...@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
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
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
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
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
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
-Original Message-
From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-
hack...@freebsd.org] On Behalf Of Robert Huff
Sent: Thursday, January 19, 2012 8:35 AM
To: freebsd-hackers@freebsd.org
Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 19 January 2012 09:47, Mark Saad nones...@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
On 19 January 2012 16:35, Robert Huff roberth...@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
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
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
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
.. 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@ and
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
On Thu, 19 Jan 2012 08:07:43 +0100
vermaden verma...@interia.pl wrote:
I got these maintainers email addresses from http://freshports.org
page, are they up-to-date there? Maybe that is the problem and
that my mails jest went to /dev/null ... Just checking for sure.
I dunno. If you want the
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
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
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
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
On 18 January 2012 09:25, Andriy Gapon a...@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).
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:
on 18/01/2012 12:54 Igor Mozolevsky said the following:
On 18 January 2012 09:25, Andriy Gapon a...@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
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
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
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
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
On 18 January 2012 11:08, Andriy Gapon a...@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
on 18/01/2012 13:54 Igor Mozolevsky said the following:
On 18 January 2012 11:08, Andriy Gapon a...@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
On Tue, Jan 17, 2012 at 8:41 PM, Igor Mozolevsky i...@hybrid-lab.co.uk wrote:
On 18 January 2012 01:11, Eitan Adler li...@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.
On 18 January 2012 13:11, Eitan Adler li...@eitanadler.com wrote:
On Tue, Jan 17, 2012 at 8:41 PM, Igor Mozolevsky i...@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
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.
[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
Am 17.01.2012 um 20:54 schrieb Steven Hartland:
- Original Message - From: John Kozubik j...@kozubik.com
It's amazing how many people are in the exact same boats - waiting for 8.3,
getting locked out of new motherboards because em(4) can't be backported
to even the production
-Original Message-
From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-
hack...@freebsd.org] On Behalf Of Julian Elischer
Sent: Tuesday, January 17, 2012 10:56 AM
To: Mark Felder
Cc: freebsd-hackers@freebsd.org
Subject: Re: FreeBSD has serious problems with focus
@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
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
: Tuesday, January 17, 2012 10:56 AM
To: Mark Felder
Cc: freebsd-hackers@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
On 18 January 2012 17:30, Chris Rees utis...@gmail.com wrote:
On 18 Jan 2012 17:12, Igor Mozolevsky i...@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
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
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
Felder
Cc: freebsd-hackers@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
On Wed, Jan 18, 2012 at 11:49 AM, Julian Elischer jul...@freebsd.orgwrote:
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
On Wed, Jan 18, 2012 at 10:27 AM, Adam Vande More amvandem...@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
On Wed, Jan 18, 2012 at 10:27 AM, Adam Vande More amvandem...@gmail.com wrote:
On Wed, Jan 18, 2012 at 11:49 AM, Julian Elischer jul...@freebsd.orgwrote:
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,
On 18 January 2012 18:27, Adam Vande More amvandem...@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
On 18 January 2012 17:56, Andriy Gapon a...@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
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
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
On Wed, 18 Jan 2012 13:46:45 -0600, John Kozubik j...@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
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
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 -
On 18 January 2012 22:31, Mark Blackman m...@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@freebsd.org mailing list
On 18 Jan 2012, at 22:50, Igor Mozolevsky wrote:
On 18 January 2012 22:31, Mark Blackman m...@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. :)
-
On 18 January 2012 22:53, Mark Blackman m...@exonetric.com wrote:
On 18 Jan 2012, at 22:50, Igor Mozolevsky wrote:
On 18 January 2012 22:31, Mark Blackman m...@exonetric.com wrote:
10.0 - Nov 2013
I think 10.0 should be released based on feature-readiness and not on
some arbitrary date…
On 18 Jan 2012, at 22:59, Igor Mozolevsky wrote:
On 18 January 2012 22:53, Mark Blackman m...@exonetric.com wrote:
On 18 Jan 2012, at 22:50, Igor Mozolevsky wrote:
On 18 January 2012 22:31, Mark Blackman m...@exonetric.com wrote:
10.0 - Nov 2013
I think 10.0 should be released based
1 - 100 of 201 matches
Mail list logo
