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 wrote:
> On Thu, Jan 26, 2012 at 09:45:47PM +1000, Da Rock wrote:
>> 1. In
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.)
>
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 releas
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 shippin
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 wrote:
> >>>
> >>>
> >>> What could I do to help make 7.5-RELEASE a reality ?
> >>>
> >>
> >> Put your hand up and volun
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
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 interva
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.
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 wrote:
> >>>
> >>>
> >>> What could I do to help make 7.5-RELEASE a reali
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 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
On Thursday, January 19, 2012 4:33:40 pm Adrian Chadd wrote:
> On 19 January 2012 09:47, Mark Saad 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 th
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 co
Hi,
On Wed, Jan 25, 2012 at 3:22 PM, Mark Linimon 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 crucial.
>
> I'm
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
> 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
On Wed, Jan 25, 2012 at 9:58 AM, Arnaud Lacombe wrote:
> Hi,
>
> On Wed, Jan 25, 2012 at 2:28 AM, Mark Linimon 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
Hi,
On Wed, Jan 25, 2012 at 2:28 AM, Mark Linimon 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 indigestible +5
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 t
"Mike Meyer" 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 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 from the person that closed it:
>
> > 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:
> >
> > http://w
On Tue, 24 Jan 2012 15:23:47 -0600
Mark Linimon 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 there should b
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
Hi,
On Tue, Jan 24, 2012 at 4:10 PM, Mark Linimon wrote:
>> On 24 January 2012 18:36, Arnaud Lacombe 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
> On 24 January 2012 18:36, Arnaud Lacombe 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 nit-picky, pass
On 24 January 2012 18:36, Arnaud Lacombe wrote:
> Hi,
>
> "Mark Linimon" 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 maintai
Hi,
"Mark Linimon" 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 having the tools tha
"Mark Linimon" pisze:
> On Thu, Jan 19, 2012 at 08:07:43AM +0100, vermaden wrote:
> > I submit PRs and try to help test them as some developer/committer
> > will pick up the PR, submit a patch to test, but it was MANY times
> > that the response from developer/committer was way too long that
> > I
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
On 01/22/12 22:44, Chris Rees wrote:
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
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 thi
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
arou
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?
___
f
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
specifica
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 a
On 2012-Jan-21 02:07:35 +0100, Daniel Gerzo 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 pe
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 h
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/f
On 18 January 2012 17:13, Daniel Eischen 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 for
2012/1/20 Gleb Smirnoff :
> 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
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 sa
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 l
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 g
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
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.
--
Sen
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 d
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 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 w
On Thu, 19 Jan 2012 08:07:43 +0100
vermaden 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 maintainer as of you
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 wa
.. 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 port
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 b
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 ha
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 su
On 19 January 2012 16:35, Robert Huff 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 "tink
On 19 January 2012 09:47, Mark Saad 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 . Ther
> -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 foc
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 an
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 H
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 particu
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 g
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.
The
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 fo
On Wed, 18 Jan 2012 17:39:31 -0600
"Matthew D. Fuller" 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 bei
On Wed, Jan 18, 2012 at 12:27 PM, Doug Barton 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. T
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 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
On 18 Jan 2012, at 22:59, Igor Mozolevsky wrote:
> On 18 January 2012 22:53, Mark Blackman wrote:
>>
>> On 18 Jan 2012, at 22:50, Igor Mozolevsky wrote:
>>
>>> On 18 January 2012 22:31, Mark Blackman wrote:
>>>
10.0 - Nov 2013
>>>
>>> I think 10.0 should be released based on feature-re
On 18 January 2012 22:53, Mark Blackman wrote:
>
> On 18 Jan 2012, at 22:50, Igor Mozolevsky wrote:
>
>> On 18 January 2012 22:31, Mark Blackman 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 red
On 18 Jan 2012, at 22:50, Igor Mozolevsky wrote:
> On 18 January 2012 22:31, Mark Blackman 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
___
On 18 January 2012 22:31, Mark Blackman 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
http://lists.freebsd.org/mailman/lis
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 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
experi
On Wed, 18 Jan 2012 13:46:45 -0600, John Kozubik 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:
- EO
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, 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 Fre
On 18 January 2012 17:56, Andriy Gapon 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 develop
On 18 January 2012 18:27, Adam Vande More 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
On Wed, Jan 18, 2012 at 10:27 AM, Adam Vande More wrote:
> On Wed, Jan 18, 2012 at 11:49 AM, Julian Elischer 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
On Wed, Jan 18, 2012 at 10:27 AM, Adam Vande More 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 campai
On Wed, Jan 18, 2012 at 11:49 AM, Julian Elischer 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 t
ian 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, longevity, and
> >> lifecycle
> >>
> > [snip]
> >
>
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
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 Foundati
On 18 January 2012 17:30, Chris Rees wrote:
> On 18 Jan 2012 17:12, "Igor Mozolevsky" 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
>> Sent: 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
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 pack
r
>> 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
> -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 seriou
Am 17.01.2012 um 20:54 schrieb Steven Hartland:
> - Original Message - From: "John Kozubik"
>> 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 release...
[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
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
On 18 January 2012 13:11, Eitan Adler wrote:
> On Tue, Jan 17, 2012 at 8:41 PM, Igor Mozolevsky
> 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, c
On Tue, Jan 17, 2012 at 8:41 PM, Igor Mozolevsky wrote:
> On 18 January 2012 01:11, Eitan Adler 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
on 18/01/2012 13:54 Igor Mozolevsky said the following:
> On 18 January 2012 11:08, Andriy Gapon 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 FreeB
On 18 January 2012 11:08, Andriy Gapon 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
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 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
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
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
on 18/01/2012 12:54 Igor Mozolevsky said the following:
> On 18 January 2012 09:25, 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* cod
1 - 100 of 201 matches
Mail list logo