On Friday, 21 December 2012 at 18:34:12 UTC, Rob T wrote:
On Thursday, 20 December 2012 at 23:43:12 UTC, Joseph Cassman
wrote:
Just some food for thought.
In the section about the "Branching model", the wiki currently
has a staging branch in addition to the master branch. From
what I understa
On Thursday, 20 December 2012 at 23:43:12 UTC, Joseph Cassman
wrote:
Just some food for thought.
In the section about the "Branching model", the wiki currently
has a staging branch in addition to the master branch. From
what I understand, the idea seems to be to vet a release on
staging until
On Thursday, 20 December 2012 at 23:43:12 UTC, Joseph Cassman
wrote:
On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei
Alexandrescu wrote:
I agree with one "stable" branch.
Andrei
Just some food for thought.
In the section about the "Branching model", the wiki currently
has a staging
On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei
Alexandrescu wrote:
I agree with one "stable" branch.
Andrei
Just some food for thought.
In the section about the "Branching model", the wiki currently
has a staging branch in addition to the master branch. From what
I understand, the
On Thursday, 20 December 2012 at 08:27:22 UTC, foobar wrote:
I see both as going hand-in-hand, otherwise we have chicken-egg
problem.
We need a better process to allow more developers to contribute
code more easily *and* we need better planning to provide
incentive for new developer to contribu
On Thursday, 20 December 2012 at 05:32:30 UTC, H. S. Teoh wrote:
>On Wednesday, 19 December 2012 at 23:05:59 UTC, deadalnix
>wrote:
>
>>master : used as a base for development. New feature are
>>merged
>>here.
>>staging : used to provide a view of what the next version
>>will
>>look like. Re
On Thursday, 20 December 2012 at 05:33:27 UTC, Rob T wrote:
On Wednesday, 19 December 2012 at 21:58:12 UTC, foobar wrote:
Personally, I think the whole pre-development stage needs to
get looks at -
Specifically having some sort of at least high-level *binding*
planning - road map, mile stones
On Thursday, 20 December 2012 at 05:32:30 UTC, H. S. Teoh wrote:
On Thu, Dec 20, 2012 at 05:48:13AM +0100, deadalnix wrote:
On Thursday, 20 December 2012 at 04:11:00 UTC, Jesse Phillips
In my mind, after a release, the contents of staging are
updated to be
exactly the same as master. This can b
On Wednesday, 19 December 2012 at 21:58:12 UTC, foobar wrote:
Personally, I think the whole pre-development stage needs to
get looks at -
Specifically having some sort of at least high-level *binding*
planning - road map, mile stones, todo lists. This should give
more weight to DIPs.
DIPs at
On Thu, Dec 20, 2012 at 05:48:13AM +0100, deadalnix wrote:
> On Thursday, 20 December 2012 at 04:11:00 UTC, Jesse Phillips wrote:
> >On Wednesday, 19 December 2012 at 23:05:59 UTC, deadalnix wrote:
> >
> >>master : used as a base for development. New feature are merged
> >>here.
> >>staging : used
On Thursday, 20 December 2012 at 04:11:00 UTC, Jesse Phillips
wrote:
From the sound of it this request is pulled into master. We
continue to pull many of these changes in. How do we decide
they should be placed into staging, when we pull them into
master?. If we wait for some 'magic time' how
On Thursday, 20 December 2012 at 04:11:00 UTC, Jesse Phillips
wrote:
On Wednesday, 19 December 2012 at 23:05:59 UTC, deadalnix wrote:
master : used as a base for development. New feature are
merged here.
staging : used to provide a view of what the next version will
look like. Regular snapshot
On Wednesday, 19 December 2012 at 23:05:59 UTC, deadalnix wrote:
master : used as a base for development. New feature are merged
here.
staging : used to provide a view of what the next version will
look like. Regular snapshot of that branch are made so public
can use the last features.
version
On Wednesday, 19 December 2012 at 23:08:59 UTC, Andrei
Alexandrescu wrote:
My understanding is that's what many projects do. Supporting
each minor release would make for a ton of work.
The whole point is to not support all minor release. Usually
project supports one or 2 of them, that's it.
On 12/19/12 5:43 PM, deadalnix wrote:
On Wednesday, 19 December 2012 at 22:30:29 UTC, Andrei Alexandrescu wrote:
On 12/19/12 5:07 PM, deadalnix wrote:
On Wednesday, 19 December 2012 at 21:48:22 UTC, Andrei Alexandrescu
wrote:
Walter needs to chime in about that. One possibility is to continue
On Wednesday, 19 December 2012 at 22:30:29 UTC, Andrei
Alexandrescu wrote:
On 12/19/12 5:07 PM, deadalnix wrote:
On Wednesday, 19 December 2012 at 21:48:22 UTC, Andrei
Alexandrescu wrote:
Walter needs to chime in about that. One possibility is to
continue
using tags for marking releases, and th
On Wednesday, 19 December 2012 at 22:30:29 UTC, Andrei
Alexandrescu wrote:
On 12/19/12 5:07 PM, deadalnix wrote:
On Wednesday, 19 December 2012 at 21:48:22 UTC, Andrei
Alexandrescu wrote:
Walter needs to chime in about that. One possibility is to
continue
using tags for marking releases, and th
On 12/19/12 5:07 PM, deadalnix wrote:
On Wednesday, 19 December 2012 at 21:48:22 UTC, Andrei Alexandrescu wrote:
Walter needs to chime in about that. One possibility is to continue
using tags for marking releases, and then branch for the few important
releases that we want to patch.
Note that
On Wednesday, 19 December 2012 at 21:53:04 UTC, H. S. Teoh wrote:
On Wed, Dec 19, 2012 at 04:48:22PM -0500, Andrei Alexandrescu
wrote:
On 12/19/12 4:40 PM, deadalnix wrote:
>On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei
>Alexandrescu wrote:
>>On 12/19/12 4:23 PM, foobar wrote:
[...]
On Wednesday, 19 December 2012 at 21:58:12 UTC, foobar wrote:
On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei
Alexandrescu wrote:
On 12/19/12 4:23 PM, foobar wrote:
On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix
wrote:
On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wro
On Wednesday, 19 December 2012 at 21:48:22 UTC, Andrei
Alexandrescu wrote:
Walter needs to chime in about that. One possibility is to
continue using tags for marking releases, and then branch for
the few important releases that we want to patch.
Note that what is described on the wiki distin
On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei
Alexandrescu wrote:
On 12/19/12 4:23 PM, foobar wrote:
On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix
wrote:
On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
Do we all agree that we need a "stable" branch?
No. St
On Wed, Dec 19, 2012 at 04:48:22PM -0500, Andrei Alexandrescu wrote:
> On 12/19/12 4:40 PM, deadalnix wrote:
> >On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei Alexandrescu wrote:
> >>On 12/19/12 4:23 PM, foobar wrote:
[...]
> >>>Let's generalize this point for the sake of reaching consensus
On 12/19/12 4:40 PM, deadalnix wrote:
On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei Alexandrescu wrote:
On 12/19/12 4:23 PM, foobar wrote:
On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix wrote:
On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
Do we all agree th
On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei
Alexandrescu wrote:
On 12/19/12 4:23 PM, foobar wrote:
On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix
wrote:
On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
Do we all agree that we need a "stable" branch?
No. St
On 12/19/12 4:23 PM, foobar wrote:
On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix wrote:
On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
Do we all agree that we need a "stable" branch?
No. Stable isn't a boolean criteria. You'll find different degree of
stability goi
On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix wrote:
On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
Do we all agree that we need a "stable" branch?
No. Stable isn't a boolean criteria. You'll find different
degree of stability going from not so stable (dev version)
On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
On Wednesday, 19 December 2012 at 19:26:48 UTC, deadalnix wrote:
On Wednesday, 19 December 2012 at 19:01:56 UTC, Andrei
Alexandrescu wrote:
I was hoping for more consensus to build in this thread.
Right now it seems there's still quit
On Wed, Dec 19, 2012 at 02:01:57PM -0500, Andrei Alexandrescu wrote:
> On 12/19/12 1:45 PM, H. S. Teoh wrote:
> >On Fri, Dec 14, 2012 at 10:16:45AM -0500, Andrei Alexandrescu wrote:
> >>On 12/14/12 10:02 AM, H. S. Teoh wrote:
> >>>A number of us have put up a draft of a proposed release process on
On Wednesday, 19 December 2012 at 19:26:48 UTC, deadalnix wrote:
On Wednesday, 19 December 2012 at 19:01:56 UTC, Andrei
Alexandrescu wrote:
I was hoping for more consensus to build in this thread. Right
now it seems there's still quite a bit of controversy about
what the best way to go is.
On Wednesday, 19 December 2012 at 19:01:56 UTC, Andrei
Alexandrescu wrote:
I was hoping for more consensus to build in this thread. Right
now it seems there's still quite a bit of controversy about
what the best way to go is.
I'm afraid a lot of discussions we see right now are plain
useles
On Wednesday, 19 December 2012 at 19:01:56 UTC, Andrei
Alexandrescu wrote:
I was hoping for more consensus to build in this thread. Right
now it seems there's still quite a bit of controversy about
what the best way to go is.
Andrei
We need to list out all the main points of contention and
On 12/19/12 1:45 PM, H. S. Teoh wrote:
On Fri, Dec 14, 2012 at 10:16:45AM -0500, Andrei Alexandrescu wrote:
On 12/14/12 10:02 AM, H. S. Teoh wrote:
A number of us have put up a draft of a proposed release process on
the wiki, based on some of the things discussed in this thread.
http:/
On Fri, Dec 14, 2012 at 10:16:45AM -0500, Andrei Alexandrescu wrote:
> On 12/14/12 10:02 AM, H. S. Teoh wrote:
> >A number of us have put up a draft of a proposed release process on
> >the wiki, based on some of the things discussed in this thread.
> >
> > http://wiki.dlang.org/Release_Process
On Wednesday, 19 December 2012 at 06:31:04 UTC, Rob T wrote:
Perhaps there is resistance to changing from the current
"snapshot" process which tends to produce meaningless
buggy/breaking releases, to one that is a "feature" based
release.
I don not see a greater correlation between snapshot r
On Wednesday, 19 December 2012 at 06:31:04 UTC, Rob T wrote:
On Wednesday, 19 December 2012 at 01:48:49 UTC, deadalnix wrote:
I think the smart move here is to release new feature less
often, but to release more at once, and at the same time go
fast on bug fixes.
I'm not a a fan of time line
On Wednesday, 19 December 2012 at 01:48:49 UTC, deadalnix wrote:
I think the smart move here is to release new feature less
often, but to release more at once, and at the same time go
fast on bug fixes.
I'm not a a fan of time line based releases (snapshots), it makes
no sense to me at all ot
On Wednesday, 19 December 2012 at 01:38:16 UTC, Joseph Rushton
Wakeling wrote:
On 12/19/2012 02:22 AM, deadalnix wrote:
I don't see how they aren't release. They are released. But
they have branches,
they are tags. Each time you package the software to put it in
download
somewhere for users to
On 12/19/2012 02:22 AM, deadalnix wrote:
I don't see how they aren't release. They are released. But they have branches,
they are tags. Each time you package the software to put it in download
somewhere for users to use, you do a release.
I you want to talk about branch or versions talk about br
On Wednesday, 19 December 2012 at 01:08:28 UTC, Joseph Rushton
Wakeling wrote:
On 12/19/2012 01:00 AM, deadalnix wrote:
This is probably too slow for revision and too fast for new
versions.
I'm not counting minor-point bugfix updates as a "release" in
this context, as I doubt you'd have a sep
On 12/19/2012 01:00 AM, deadalnix wrote:
This is probably too slow for revision and too fast for new versions.
I'm not counting minor-point bugfix updates as a "release" in this context, as I
doubt you'd have a separate branch for those.
This is yet another point where the distro process do
On Tuesday, 18 December 2012 at 20:55:34 UTC, Joseph Rushton
Wakeling wrote:
On 12/18/2012 09:48 PM, SomeDude wrote:
And it's not the same at all as creating one branch every
month.
But why would you do that? The general discussion seems to
have been around the idea of 1 or 2 stable releases
On Tuesday, 18 December 2012 at 22:37:10 UTC, SomeDude wrote:
On Tuesday, 18 December 2012 at 20:55:34 UTC, Joseph Rushton
Wakeling wrote:
On 12/18/2012 09:48 PM, SomeDude wrote:
And it's not the same at all as creating one branch every
month.
But why would you do that? The general discussio
On Tuesday, 18 December 2012 at 20:55:34 UTC, Joseph Rushton
Wakeling wrote:
On 12/18/2012 09:48 PM, SomeDude wrote:
And it's not the same at all as creating one branch every
month.
But why would you do that? The general discussion seems to
have been around the idea of 1 or 2 stable releases
On 12/18/2012 09:48 PM, SomeDude wrote:
And it's not the same at all as creating one branch every month.
But why would you do that? The general discussion seems to have been around the
idea of 1 or 2 stable releases per year, 1 every 3 months max.
On Monday, 17 December 2012 at 17:45:12 UTC, David Nadlinger
wrote:
On Monday, 17 December 2012 at 17:31:45 UTC, foobar wrote:
Huh?
Both LLVM and KDE are developed on *subversion* and as such
their work-flows are not applicable. Not to mention that KDE
is vastly different in concept and goals
On Monday, 17 December 2012 at 22:10:12 UTC, foobar wrote:
I forgot to explain that the multiple roots is applicable to D
as well in that we have there fully working compilers - LDC,
GDC and DMD. They currently share the same front-end - GDC and
LDC merge DMD's code. This situation is also sub
On Monday, 17 December 2012 at 22:02:45 UTC, foobar wrote:
On Monday, 17 December 2012 at 21:03:04 UTC, Rob T wrote:
On Monday, 17 December 2012 at 18:14:54 UTC, foobar wrote:
At the moment we may use git commands but really we are still
developing on mostly a subversion model. Walter used to
On Monday, 17 December 2012 at 21:03:04 UTC, Rob T wrote:
On Monday, 17 December 2012 at 18:14:54 UTC, foobar wrote:
At the moment we may use git commands but really we are still
developing on mostly a subversion model. Walter used to accept
patches and those were simply replaced by pull reques
On Monday, 17 December 2012 at 18:14:54 UTC, foobar wrote:
At the moment we may use git commands but really we are still
developing on mostly a subversion model. Walter used to accept
patches and those were simply replaced by pull requests. There
isn't any change in the mental model required to
On Monday, 17 December 2012 at 17:45:12 UTC, David Nadlinger
wrote:
On Monday, 17 December 2012 at 17:31:45 UTC, foobar wrote:
Huh?
Both LLVM and KDE are developed on *subversion* and as such
their work-flows are not applicable. Not to mention that KDE
is vastly different in concept and goals
On Monday, 17 December 2012 at 17:31:45 UTC, foobar wrote:
Huh?
Both LLVM and KDE are developed on *subversion* and as such
their work-flows are not applicable. Not to mention that KDE is
vastly different in concept and goals than a programming
language.
Subversion is conceptually very diffe
On Sunday, 16 December 2012 at 23:18:20 UTC, Jonathan M Davis
wrote:
On Sunday, December 16, 2012 11:23:57 Andrei Alexandrescu wrote:
Right now we're using a tagging system for releases, implying
releases
are just snapshots of a continuum. But what we need is e.g. to
be able
to patch 2.065 to f
On Sunday, 16 December 2012 at 22:43:13 UTC, David Nadlinger
wrote:
On Sunday, 16 December 2012 at 22:18:14 UTC, SomeDude wrote:
This sounds to me like a bad idea. And indeed, I haven't heard
of any other project doing this.
Having release branches is a common practice for many open
source pr
On Monday, 17 December 2012 at 07:04:29 UTC, deadalnix wrote:
This is exactly to handle this kind of grunt work that computer
and software were invented.
Yep, and why Git handles merging so well. But it doesn't know
which branches you are merging into until you tell it. So you can
go ahead a
On Monday, 17 December 2012 at 05:29:23 UTC, SomeDude wrote:
On Sunday, 16 December 2012 at 22:43:13 UTC, David Nadlinger
wrote:
On Sunday, 16 December 2012 at 22:18:14 UTC, SomeDude wrote:
This sounds to me like a bad idea. And indeed, I haven't
heard of any other project doing this.
Having
On Sunday, 16 December 2012 at 22:43:13 UTC, David Nadlinger
wrote:
On Sunday, 16 December 2012 at 22:18:14 UTC, SomeDude wrote:
This sounds to me like a bad idea. And indeed, I haven't heard
of any other project doing this.
Having release branches is a common practice for many open
source pr
On Sun, Dec 16, 2012 at 11:43:12PM +0100, David Nadlinger wrote:
> On Sunday, 16 December 2012 at 22:18:14 UTC, SomeDude wrote:
> >This sounds to me like a bad idea. And indeed, I haven't heard of
> >any other project doing this.
>
> Having release branches is a common practice for many open sourc
On Sunday, December 16, 2012 11:23:57 Andrei Alexandrescu wrote:
> Right now we're using a tagging system for releases, implying releases
> are just snapshots of a continuum. But what we need is e.g. to be able
> to patch 2.065 to fix a bug for a client who can't upgrade right now.
> That means one
On Sunday, 16 December 2012 at 20:08:11 UTC, Jacob Carlborg wrote:
On 2012-12-16 20:04, Jesse Phillips wrote:
I see it unreasonable to maintain every release. If we need to
make a
special "maintenance" release then we directly handle the
issue being
requested instead of providing every fix ap
On Sunday, 16 December 2012 at 22:18:14 UTC, SomeDude wrote:
This sounds to me like a bad idea. And indeed, I haven't heard
of any other project doing this.
Having release branches is a common practice for many open source
projects. For example, KDE creates a branch per minor release,
with pa
On Sunday, 16 December 2012 at 22:18:14 UTC, SomeDude wrote:
On Sunday, 16 December 2012 at 15:05:58 UTC, Andrei
Alexandrescu wrote:
On 12/16/12 6:15 AM, Joseph Rushton Wakeling wrote:
On 12/15/2012 09:39 PM, deadalnix wrote:
Can we drop the LTS name ? It reminds me of ubuntu, and I
clearly ho
On Sunday, 16 December 2012 at 15:05:58 UTC, Andrei Alexandrescu
wrote:
On 12/16/12 6:15 AM, Joseph Rushton Wakeling wrote:
On 12/15/2012 09:39 PM, deadalnix wrote:
Can we drop the LTS name ? It reminds me of ubuntu, and I
clearly hope
that
people promoting that idea don't plan to reproduce ub
On 12/16/2012 05:23 PM, Andrei Alexandrescu wrote:
Right now we're using a tagging system for releases, implying releases are just
snapshots of a continuum. But what we need is e.g. to be able to patch 2.065 to
fix a bug for a client who can't upgrade right now. That means one branch per
release.
On Sunday, 16 December 2012 at 18:37:48 UTC, Andrei Alexandrescu
wrote:
This should be Walter's business and not part
of the "official" community process.
I think this is rather shortsighted. Corporate support by
Walter is only one possible scenario, but there are many others.
Indeed. To a
On 2012-12-16 20:04, Jesse Phillips wrote:
I see it unreasonable to maintain every release. If we need to make a
special "maintenance" release then we directly handle the issue being
requested instead of providing every fix applicable.
We could say that we support X number of older releases.
On Sunday, 16 December 2012 at 16:23:57 UTC, Andrei Alexandrescu
wrote:
Right now we're using a tagging system for releases, implying
releases are just snapshots of a continuum. But what we need is
e.g. to be able to patch 2.065 to fix a bug for a client who
can't upgrade right now. That mean
On Sunday, 16 December 2012 at 07:35:27 UTC, deadalnix wrote:
I shouldn't be here explaining why this is wrong, you should be
here explaining me why it can be applied anyway.
We are developing a process, specifying what it will look like.
If I'm building an airplane and say I think it should
On Sunday, 16 December 2012 at 18:37:48 UTC, Andrei Alexandrescu
wrote:
The prevalent use of the feature would be that a bug in a
future release is back-patched onto an older release.
Andrei
The issue I see is we will have X releases. A bug is fixed, do we
now apply it to all X or only Y
On 12/16/12 11:56 AM, foobar wrote:
I don't see why that is a requirement (having a branch per release).
We can still have a single stable branch with tags for releases and when
Walter needs to provide special customizations he can always just branch
off of the tagged release.
To the extent pos
On Sunday, 16 December 2012 at 15:05:58 UTC, Andrei Alexandrescu
wrote:
On 12/16/12 6:15 AM, Joseph Rushton Wakeling wrote:
On 12/15/2012 09:39 PM, deadalnix wrote:
Can we drop the LTS name ? It reminds me of ubuntu, and I
clearly hope
that
people promoting that idea don't plan to reproduce ub
On 12/16/12 10:15 AM, Joseph Rushton Wakeling wrote:
On 12/16/2012 04:05 PM, Andrei Alexandrescu wrote:
Just one tidbit of information: I talked to Walter and we want to
build into the
process the ability to modify any particular release. (One possibility
is to do
so as part of paid support for
On Sun, Dec 16, 2012 at 10:05:58AM -0500, Andrei Alexandrescu wrote:
[...]
> Just one tidbit of information: I talked to Walter and we want to
> build into the process the ability to modify any particular release.
> (One possibility is to do so as part of paid support for large
> corporate users.)
On 12/16/2012 04:05 PM, Andrei Alexandrescu wrote:
Just one tidbit of information: I talked to Walter and we want to build into the
process the ability to modify any particular release. (One possibility is to do
so as part of paid support for large corporate users.) That means there needs to
be o
On 12/16/12 6:15 AM, Joseph Rushton Wakeling wrote:
On 12/15/2012 09:39 PM, deadalnix wrote:
Can we drop the LTS name ? It reminds me of ubuntu, and I clearly hope
that
people promoting that idea don't plan to reproduce ubuntu's scheme :
- it is not suitable for a programming language (as stated
On 12/15/2012 09:39 PM, deadalnix wrote:
Can we drop the LTS name ? It reminds me of ubuntu, and I clearly hope that
people promoting that idea don't plan to reproduce ubuntu's scheme :
- it is not suitable for a programming language (as stated 3 time now, so just
read before why I won't repeat
On 12/16/2012 08:35 AM, deadalnix wrote:
On Sunday, 16 December 2012 at 02:03:34 UTC, Jesse Phillips wrote:
You don't need to repeat your self, you need to expand on your points. Joseph
has already requested that you give specifics of your objection, you have
explained why the situation is diffe
On Sunday, 16 December 2012 at 08:52:24 UTC, deadalnix wrote:
So distro's versioning system is good for a programming
language because you use it successfully in your software which
isn't a programming language (and we also don't know according
to which goal it is successful) ?
Let's not ge
On Sunday, 16 December 2012 at 07:39:09 UTC, deadalnix wrote:
The compiler source code is probably what we have that look
like the most as a spec right now.
Unfortunately that is likely the case. I hope we can all agree
that the specification should be managed better, but it's a much
lesser p
On Sunday, 16 December 2012 at 08:30:04 UTC, Rob T wrote:
On Sunday, 16 December 2012 at 07:35:27 UTC, deadalnix wrote:
The only goal that is coming is trying to reach some level of
stability. Everything else is completely different.
There are still some clear similarities between what Deb
On Sunday, 16 December 2012 at 07:35:27 UTC, deadalnix wrote:
The only goal that is coming is trying to reach some level of
stability. Everything else is completely different.
There are still some clear similarities between what Debian is
doing and what I presume most people do in software
On Sunday, 16 December 2012 at 03:59:33 UTC, Rob T wrote:
On Thursday, 13 December 2012 at 07:18:16 UTC, foobar wrote:
Per my answer to Rob:
D2 *is* the major version.
releases should be minor versions and largely backwards
compatible - some evolution is allowed given some reasonable
restrict
On Sunday, 16 December 2012 at 02:03:34 UTC, Jesse Phillips wrote:
On Saturday, 15 December 2012 at 20:39:22 UTC, deadalnix wrote:
Can we drop the LTS name ? It reminds me of ubuntu, and I
clearly hope that people promoting that idea don't plan to
reproduce ubuntu's scheme :
- it is not suitabl
On Thursday, 13 December 2012 at 07:18:16 UTC, foobar wrote:
Per my answer to Rob:
D2 *is* the major version.
releases should be minor versions and largely backwards
compatible - some evolution is allowed given some reasonable
restrictions like a proper migration path over several releases.
Cr
On Sunday, 16 December 2012 at 02:03:34 UTC, Jesse Phillips wrote:
On Saturday, 15 December 2012 at 20:39:22 UTC, deadalnix wrote:
Can we drop the LTS name ? It reminds me of ubuntu, and I
clearly hope that people promoting that idea don't plan to
reproduce ubuntu's scheme :
- it is not suitabl
On Saturday, 15 December 2012 at 20:39:22 UTC, deadalnix wrote:
Can we drop the LTS name ? It reminds me of ubuntu, and I
clearly hope that people promoting that idea don't plan to
reproduce ubuntu's scheme :
- it is not suitable for a programming language (as stated 3
time now, so just read b
On Saturday, 15 December 2012 at 19:03:49 UTC, Brad Roberts wrote:
On 12/15/2012 2:29 AM, Dmitry Olshansky wrote:
I think one of major goals is to be able to continue ongoing
development while at the _same time_ preparing a release.
To me number one problem is condensed in the statement "we are
12/15/2012 11:03 PM, Brad Roberts пишет:
On 12/15/2012 2:29 AM, Dmitry Olshansky wrote:
I think one of major goals is to be able to continue ongoing development while
at the _same time_ preparing a release.
To me number one problem is condensed in the statement "we are going to release do
not
On Saturday, 15 December 2012 at 20:39:22 UTC, deadalnix wrote:
On Saturday, 15 December 2012 at 20:32:42 UTC, Jesse Phillips
wrote:
On Saturday, 15 December 2012 at 10:29:55 UTC, Dmitry
Olshansky wrote:
Second point is about merging master into staging - why not
just rewrite it with master bra
On Saturday, 15 December 2012 at 20:32:42 UTC, Jesse Phillips
wrote:
On Saturday, 15 December 2012 at 10:29:55 UTC, Dmitry Olshansky
wrote:
Second point is about merging master into staging - why not
just rewrite it with master branch altogether after each
release?
master is the branch with cor
On Saturday, 15 December 2012 at 19:03:49 UTC, Brad Roberts wrote:
On 12/15/2012 2:29 AM, Dmitry Olshansky wrote:
I think one of major goals is to be able to continue ongoing
development while at the _same time_ preparing a release.
To me number one problem is condensed in the statement "we are
On Saturday, 15 December 2012 at 19:03:49 UTC, Brad Roberts wrote:
This is a forcing function that's just required.
There is a focusing that needs to happen, but as you say, you
can't really dictate where someone puts their time (for open
source). So it is best to let the person who decided
On 12/15/2012 2:29 AM, Dmitry Olshansky wrote:
> I think one of major goals is to be able to continue ongoing development
> while at the _same time_ preparing a release.
> To me number one problem is condensed in the statement "we are going to
> release do not merge anything but regressions"
> t
On Saturday, 15 December 2012 at 10:29:55 UTC, Dmitry Olshansky
wrote:
12/14/2012 3:34 AM, deadalnix пишет:
On Thursday, 13 December 2012 at 20:48:30 UTC, deadalnix wrote:
On Thursday, 13 December 2012 at 20:04:50 UTC, Dmitry
Olshansky wrote:
I think it's good.
But personally I'd expect:
* m
12/14/2012 3:34 AM, deadalnix пишет:
On Thursday, 13 December 2012 at 20:48:30 UTC, deadalnix wrote:
On Thursday, 13 December 2012 at 20:04:50 UTC, Dmitry Olshansky wrote:
I think it's good.
But personally I'd expect:
* master to be what you define as dev, because e.g. GitHub puts
master as d
12/14/2012 4:12 PM, Manu пишет:
One thing that I think would be really awesome when this is all rolling,
is attach a system that does nightly builds of the dev line every evening.
I've often had to pester Walter to produce a new build for us when a
critical bug/feature was fixed.
Then this coul
On Friday, 14 December 2012 at 19:01:23 UTC, H. S. Teoh wrote:
On Fri, Dec 14, 2012 at 06:17:15PM +0100, Rob T wrote:
[...]
BTW, the wiki page is looking very good guys. Well done!!!
[...]
Thanks, but we do still have issues to work out, details to
fill in,
etc.. We'd love to have your input
On Fri, Dec 14, 2012 at 06:17:15PM +0100, Rob T wrote:
[...]
> BTW, the wiki page is looking very good guys. Well done!!!
[...]
Thanks, but we do still have issues to work out, details to fill in,
etc.. We'd love to have your input too!
T
--
We've all heard that a million monkeys banging on a
On Friday, 14 December 2012 at 17:17:16 UTC, Rob T wrote:
However here's a cautionary note: I read that Walter has
specific motives right now concerning a timely release for a
strategic D user that can help move D into a more prominent
position, so if we're to support a release as smoothly as
On Friday, 14 December 2012 at 15:36:05 UTC, Jesse Phillips wrote:
From the discussion there appears to be more that believe that
master should remain the development branch.
From this, 'staging' is seen as the branch to prepare a release
from (bug fix only).
We are currently in the 2.61 fre
1 - 100 of 161 matches
Mail list logo
