8 Dec
2014
8 Dec
'14
8:03 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
All,
TDE R14.0.0 is now in HARD FREEZE for release. I will be updating the
version number and tagging R14.0.0 in GIT shortly.
Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iFYEARELAAYFAlSFW2QACgkQLaxZSoRZrGEtOADcD5KX4gEsXqF8h/5GHzLp73AC
9Fuu61fYCQYGFQDfYNjXEmUilYvS0EpjzzolWewZ/Crovjk7BFsvJQ==
=wZeK
-----END PGP SIGNATURE-----
8 Dec
8 Dec
9:30 a.m.
New subject: [trinity-devel] TDE R14 Hard Freeze
On Monday 08 of December 2014 09:03:49 Timothy Pearson wrote:
All,
TDE R14.0.0 is now in HARD FREEZE for release. I will be updating the
version number and tagging R14.0.0 in GIT shortly.
Tim
In the tag you remain current syntax == 'v14.0.0'? It's just that the use
of 'r' instead of 'v' would probably have had the effect that in the
listing
were depicted as older - below under 'v3.5.13.x', which would be confusing.
--
Slávek
9:34 a.m.
New subject: [trinity-devel] TDE R14 Hard Freeze
On 2014/12/08 06:30 PM, Slávek Banko wrote:
On Monday 08 of December 2014 09:03:49 Timothy Pearson
wrote:
I also think v14.0.0 is better than R14.0.0.
By the way, beside tagging it, what are we going to do about branching?
Cheers
Michele
All,
TDE R14.0.0 is now in HARD FREEZE for release. I will be updating the
version number and tagging R14.0.0 in GIT shortly.
Tim
In the tag you remain current syntax == 'v14.0.0'? It's just that the use
of 'r' instead of 'v' would probably have had the effect that in the
listing
were depicted as older - below under 'v3.5.13.x', which would be confusing.
9:51 a.m.
New subject: [trinity-devel] TDE R14 Hard Freeze
On Monday 08 of December 2014 10:34:32 Michele Calgaro wrote:
On 2014/12/08 06:30 PM, Slávek Banko wrote:
I suppose after tagging can be created a branch. The name for the branch
v14.0.x or v14.0-sru? Or otherwise?
--
Slávek
On Monday 08 of December 2014 09:03:49 Timothy
Pearson wrote:
I also think v14.0.0 is better than R14.0.0.
By the way, beside tagging it, what are we going to do about branching?
Cheers
Michele
All,
TDE R14.0.0 is now in HARD FREEZE for release. I will be updating the
version number and tagging R14.0.0 in GIT shortly.
Tim
In the tag you remain current syntax == 'v14.0.0'? It's just that the use
of 'r' instead of 'v' would probably have had the effect that in the
listing were depicted as older - below under 'v3.5.13.x', which would be
confusing.
10:09 a.m.
New subject: [trinity-devel] TDE R14 Hard Freeze
On 2014/12/08 06:51 PM, Slávek Banko wrote:
On Monday 08 of December 2014 10:34:32 Michele Calgaro
wrote:
I would go for v14.0.x, easier IMO.
By the way, is the idea of releasing a maintenance version (v14.0.x)
every 3 months or so still valid/accepted? Maybe given the freeze and
preparation time required, every 4 months would be more reasonable?
Minor releases (v14.y.x) would instead be released less frequently
(maybe once a year).
Cheers
Michele
On 2014/12/08 06:30 PM, Slávek Banko wrote:
I suppose after tagging can be created a branch. The name for the branch
v14.0.x or v14.0-sru? Or otherwise?
On Monday 08 of December 2014 09:03:49 Timothy
Pearson wrote:
I also think v14.0.0 is better than R14.0.0.
By the way, beside tagging it, what are we going to do about branching?
Cheers
Michele
All,
TDE R14.0.0 is now in HARD FREEZE for release. I will be updating the
version number and tagging R14.0.0 in GIT shortly.
Tim
In the tag you remain current syntax == 'v14.0.0'? It's just that the use
of 'r' instead of 'v' would probably have had the effect that in the
listing were depicted as older - below under 'v3.5.13.x', which would be
confusing.
5:53 p.m.
New subject: [trinity-devel] TDE R14 Hard Freeze
Dne po 8. prosince 2014 Michele Calgaro napsal(a):
On 2014/12/08 06:51 PM, Slávek Banko wrote:
In this we agree - tag v14.0.0, branch v14.0.x.
Three months seemed like a good time. The good news is that builds for armel
and armhf are now significantly faster. Tim recently announced a change in
the mirror system. All this should speed up the process of releasing a new
version. The question therefore is whether we will have enough capacity to
fixing bugs. We can do this, we will assume that three months for release
14.0.1 and in the process we'll see if that's enough time.
--
Slávek
On Monday 08 of December 2014 10:34:32 Michele
Calgaro wrote:
I would go for v14.0.x, easier IMO.
By the way, is the idea of releasing a maintenance version (v14.0.x)
every 3 months or so still valid/accepted? Maybe given the freeze and
preparation time required, every 4 months would be more reasonable?
Minor releases (v14.y.x) would instead be released less frequently
(maybe once a year).
Cheers
Michele
On 2014/12/08 06:30 PM, Slávek Banko wrote:
I suppose after tagging can be created a branch. The name for the branch
v14.0.x or v14.0-sru? Or otherwise? On Monday 08 of December 2014 09:03:49 Timothy
Pearson wrote:
> All,
>
> TDE R14.0.0 is now in HARD FREEZE for release. I will be updating the
> version number and tagging R14.0.0 in GIT shortly.
>
> Tim
In the tag you remain current syntax == 'v14.0.0'? It's just that the
use of 'r' instead of 'v' would probably have had the effect that in
the listing were depicted as older - below under 'v3.5.13.x', which
would be confusing.
I also think v14.0.0 is better than R14.0.0.
By the way, beside tagging it, what are we going to do about branching?
Cheers
Michele
9 Dec
9 Dec
2:42 a.m.
New subject: [trinity-devel] TDE R14 Hard Freeze
On 12/09/2014 02:53 AM, Slávek Banko wrote:
Three months seemed like a good time. The good news is
that builds for armel
and armhf are now significantly faster. Tim recently announced a change in
the mirror system. All this should speed up the process of releasing a new
version. The question therefore is whether we will have enough capacity to
fixing bugs. We can do this, we will assume that three months for release
14.0.1 and in the process we'll see if that's enough time.
Very good assessment Slavek, fully agree with you. Let's plan for 3 month release
period, but if for any reason we are
not able to fix a reasonable amount of bugs (let's say at least 20 or 30 bugs, other
opinions are welcome) in that time,
we should delay until we hit such minimum requirement.
Also, talking about v14.1.0 and v14.0.1, IMO we should slightly rearrange the meta bugs.
1) Bug 2233 should be renamed from "v14.0.1 official bug list (meta-bug)" to
"v14.1.0 official bug list (meta-bug)" and
would contain bugs to fix in the next release / improvement suggestions
2) We should add a new meta bug called "v14.0.1 resolved bug list". When we
resolve a bug that will go into v14.0.1, we
will link that bug to the meta bug. This meta bug will serve as a summary of all the fixes
made for v14.0.1.
Later there will be a v14.0.2, v14.0.3... meta bugs, while bug 2233 will continue to serve
as meta bug for the next
minor release.
What do you think? If you agree, I can do the changes required.
Cheers
Michele
7:11 p.m.
New subject: [trinity-devel] TDE R14 Hard Freeze
Dne út 9. prosince 2014 Michele Calgaro napsal(a):
On 12/09/2014 02:53 AM, Slávek Banko wrote:
I agree that we should have a meta-bug for R14.1.0. It probably does not
matter it will renamed an existing 2233 or create a new one.
Regarding the meta-bug for R14.0.x. I would suggest for each 'patch' release
separate meta-bug. Thus, one for R14.0.1, separate for R14.0.2, and as well
as for next patch releases. It allows to plan assignment bug reports for each
patch release. A meta-bug also will then be an overview of bugs fixed in any
particular patch release.
I would suggest for patch releases not focus only on the number of fixed bugs.
Substantial could be, for example, the importance of fixed bugs. Sufficiently
frequent release of new versions also seems like a good card viability of the
project.
--
Slávek
Three months seemed like a good time. The good
news is that builds for
armel and armhf are now significantly faster. Tim recently announced a
change in the mirror system. All this should speed up the process of
releasing a new version. The question therefore is whether we will have
enough capacity to fixing bugs. We can do this, we will assume that three
months for release 14.0.1 and in the process we'll see if that's enough
time.
Very good assessment Slavek, fully agree with you. Let's plan for 3 month
release period, but if for any reason we are not able to fix a reasonable
amount of bugs (let's say at least 20 or 30 bugs, other opinions are
welcome) in that time, we should delay until we hit such minimum
requirement.
Also, talking about v14.1.0 and v14.0.1, IMO we should slightly rearrange
the meta bugs. 1) Bug 2233 should be renamed from "v14.0.1 official bug
list (meta-bug)" to "v14.1.0 official bug list (meta-bug)" and would
contain bugs to fix in the next release / improvement suggestions 2) We
should add a new meta bug called "v14.0.1 resolved bug list". When we
resolve a bug that will go into v14.0.1, we will link that bug to the meta
bug. This meta bug will serve as a summary of all the fixes made for
v14.0.1.
Later there will be a v14.0.2, v14.0.3... meta bugs, while bug 2233 will
continue to serve as meta bug for the next minor release.
What do you think? If you agree, I can do the changes required.
Cheers
Michele
10 Dec
10 Dec
2:41 a.m.
New subject: [trinity-devel] TDE R14 Hard Freeze
On 12/10/2014 04:11 AM, Slávek Banko wrote:
I agree that we should have a meta-bug for R14.1.0. It
probably does not
matter it will renamed an existing 2233 or create a new one.
Regarding the meta-bug for R14.0.x. I would suggest for each 'patch' release
separate meta-bug. Thus, one for R14.0.1, separate for R14.0.2, and as well
as for next patch releases. It allows to plan assignment bug reports for each
patch release. A meta-bug also will then be an overview of bugs fixed in any
particular patch release.
Ok, we are saying the same thing :-)
I would suggest for patch releases not focus only on
the number of fixed bugs.
Substantial could be, for example, the importance of fixed bugs. Sufficiently
frequent release of new versions also seems like a good card viability of the
project.
Agree as well. Anyhow substantial or major bug fixes would probably be better done in
minor releases, not in the
maintenance ones. Or should be incorporated in the maintenance ones only after a
reasonable amount of test time.
IMO, maintenance releases should address bugs that do not require major rework/changes. I
think of them as a way to
improve v14.0.0 without major changes on it.
Instead I consider v14.x.0 releases at the same strength of the old KDE 3.5.x releases.
Just another 2 cents.
Cheers
Michele
9:54 p.m.
New subject: [trinity-devel] TDE R14 Hard Freeze
On Wednesday 10 of December 2014 03:41:19 Michele Calgaro wrote:
I have a concrete example - bug 2222 - fortunately fixed before final R14.0.0.
But imagine a situation that could not be fixed and now we should decide.
I dare say that is certainly, it is a fix for very crucial issue. At the same
time, in my opinion, this is not a fix that should mean release R14.1.0. For
such a fix I would suggest release R14.0.1. And that's just the situation
that I had in mind - a situation where, in my opinion, is inappropriate to
wait for the completion of the specified number of patches for release.
--
Slávek
I would
suggest for patch releases not focus only on the number of fixed
bugs. Substantial could be, for example, the importance of fixed bugs.
Sufficiently frequent release of new versions also seems like a good card
viability of the project.
Agree as well. Anyhow substantial or major bug fixes would probably be
better done in minor releases, not in the maintenance ones. Or should be
incorporated in the maintenance ones only after a reasonable amount of test
time. IMO, maintenance releases should address bugs that do not require
major rework/changes. I think of them as a way to improve v14.0.0 without
major changes on it.
Instead I consider v14.x.0 releases at the same strength of the old KDE
3.5.x releases.
Just another 2 cents.
Cheers
Michele
11 Dec
11 Dec
2:01 a.m.
New subject: [trinity-devel] TDE R14 Hard Freeze
On 12/11/2014 06:54 AM, Slávek Banko wrote:
On Wednesday 10 of December 2014 03:41:19 Michele
Calgaro wrote:
I have a concrete example - bug 2222 - fortunately fixed before final R14.0.0.
But imagine a situation that could not be fixed and now we should decide.
I dare say that is certainly, it is a fix for very crucial issue. At the same
time, in my opinion, this is not a fix that should mean release R14.1.0. For
such a fix I would suggest release R14.0.1. And that's just the situation
that I had in mind - a situation where, in my opinion, is inappropriate to
wait for the completion of the specified number of patches for release.
Ok, I see what you mean. That's fine for me too then.
Cheers
Michele
I would
suggest for patch releases not focus only on the number of fixed
bugs. Substantial could be, for example, the importance of fixed bugs.
Sufficiently frequent release of new versions also seems like a good card
viability of the project.
Agree as well. Anyhow substantial or major bug fixes would probably be
better done in minor releases, not in the maintenance ones. Or should be
incorporated in the maintenance ones only after a reasonable amount of test
time. IMO, maintenance releases should address bugs that do not require
major rework/changes. I think of them as a way to improve v14.0.0 without
major changes on it.
Instead I consider v14.x.0 releases at the same strength of the old KDE
3.5.x releases.
Just another 2 cents.
Cheers
Michele
10 Dec
10 Dec
4:51 a.m.
New subject: [trinity-devel] TDE R14 Hard Freeze
On 12/10/2014 04:11 AM, Slávek Banko wrote:
Regarding the meta-bug for R14.0.x. I would suggest
for each 'patch' release
separate meta-bug. Thus, one for R14.0.1, separate for R14.0.2, and as well
as for next patch releases. It allows to plan assignment bug reports for each
patch release. A meta-bug also will then be an overview of bugs fixed in any
particular patch release.
Dear all,
I have renamed and created the following meta bugs.
1) Bug 2246 - R14.0.1 resolved bug list (meta bug)
2) Bug 2247 - R14.1.0 resolved bug list (meta bug)
3) Bug 2233 - Next version bug request list (meta-bug)
Each "resolved bug list" meta bug will list the bugs solved in the corresponding
TDE release version.
Later meta bug for R14.0.2, R14.0.3, etc... will be created.
Bug 2247 will depend on all R14.0.x meta bugs.
Bug 2233 should serve as "request list" for bugs to be fixed in the next TDE
version. Once solved, each bug should be
moved to the appropriate "resolved bug list" meta bug.
These meta bugs will serve as a good tool to keep track of what is fixed in each release.
Cheers
Michele
11 Dec
11 Dec
7:55 p.m.
New subject: [trinity-devel] TDE R14 Hard Freeze
On Wednesday 10 of December 2014 05:51:40 Michele Calgaro wrote:
On 12/10/2014 04:11 AM, Slávek Banko wrote:
I expected it with meta-bugs a little differently. I had an idea that meta-bug
for each release will be used in the same manner as it was now used meta-bug
2014 == for adding bugs that "we want to fix" in appropriate release. I will
try to illustrate reason on concrete example - bug in 2234 - is related to
previous example from http://trinity-devel.pearsoncomputing.net/?0::14181
Bug 2234 at first glance looked like a serious problem that needs to be fixed
quickly by adding "unconditional" retract yakuake window when the screen is
locked => include to R14.0.1. Upon further examination, it appeared that the
problem is not related to yakuake, but is related to a bug 2222. Bug report
was closed 2234. However, retract yakuake window when screen is locked seem
like a good idea - could be added as a new option == new feature => include
to R14.1.0. If the meta-bug for R14.0.1 and R14.1.0 were used as was now used
meta-bug 2014 for R14.0.0, there would be no problem. But common
meta-bug "Next version bug request list" is for such cases totally
insufficient. And I would anticipate that there will be more such cases.
Therefore, my suggestion is to use meta-bugs 2246 and 2247 in exactly the same
manner as was used meta-bug 2014. And 2233 will be wasted.
What is your opinion?
--
Slávek
Regarding the meta-bug for R14.0.x. I would
suggest for each 'patch'
release separate meta-bug. Thus, one for R14.0.1, separate for R14.0.2,
and as well as for next patch releases. It allows to plan assignment bug
reports for each patch release. A meta-bug also will then be an overview
of bugs fixed in any particular patch release.
Dear all,
I have renamed and created the following meta bugs.
1) Bug 2246 - R14.0.1 resolved bug list (meta bug)
2) Bug 2247 - R14.1.0 resolved bug list (meta bug)
3) Bug 2233 - Next version bug request list (meta-bug)
Each "resolved bug list" meta bug will list the bugs solved in the
corresponding TDE release version. Later meta bug for R14.0.2, R14.0.3,
etc... will be created.
Bug 2247 will depend on all R14.0.x meta bugs.
Bug 2233 should serve as "request list" for bugs to be fixed in the next
TDE version. Once solved, each bug should be moved to the appropriate
"resolved bug list" meta bug.
These meta bugs will serve as a good tool to keep track of what is fixed in
each release.
Cheers
Michele
12 Dec
12 Dec
1:38 a.m.
New subject: [trinity-devel] TDE R14 Hard Freeze
On 12/12/2014 04:55 AM, Slávek Banko wrote:
Therefore, my suggestion is to use meta-bugs 2246 and
2247 in exactly the same
manner as was used meta-bug 2014. And 2233 will be wasted.
That is the option I had considered initially as well, but I was looking for a better way
to let users suggest what bugs
are more important for them.
I think we could do something like this:
1) initial bug request from users goes into bug 2233
2) when we(developers) analyze the bug (which could be several weeks/months later if there
are many bugs in the list),
we decide in which release we should fix it and we move the bug to one of the other
metabugs, even if still open.
3) when the bug is fixed, we close it.
What do you think? Otherwise if you think it is wiser that just us(developers) choose what
bug to fix for each release,
we can just ignore bug 2233 and use bug 2246/2247 as we did with bug 2014.
Cheers
Michele
1:58 a.m.
New subject: [trinity-devel] TDE R14 Hard Freeze
On Friday 12 of December 2014 02:38:37 Michele Calgaro wrote:
On 12/12/2014 04:55 AM, Slávek Banko wrote:
Yes, that sounds good to me. Perhaps it would be good to amend the
descriptions that meta-bugs are not just for fixed bugs.
Over time we will see what will be important bug 2233. Theoretically, users
want to have fixed "all" reported bugs in "some next version". So,
they could
be tempted to put into 2233 completely all reported bugs. But it would do
dubious sense to bug 2233. Practice will show it.
--
Slávek
Therefore, my suggestion is to use meta-bugs 2246
and 2247 in exactly the
same manner as was used meta-bug 2014. And 2233 will be wasted.
That is the option I had considered initially as well, but I was looking
for a better way to let users suggest what bugs are more important for
them.
I think we could do something like this:
1) initial bug request from users goes into bug 2233
2) when we(developers) analyze the bug (which could be several weeks/months
later if there are many bugs in the list), we decide in which release we
should fix it and we move the bug to one of the other metabugs, even if
still open.
3) when the bug is fixed, we close it.
What do you think? Otherwise if you think it is wiser that just
us(developers) choose what bug to fix for each release, we can just ignore
bug 2233 and use bug 2246/2247 as we did with bug 2014.
Cheers
Michele
3633
days inactive
3637
days old
14 comments
3 participants
participants (3)
-
Michele Calgaro -
Slávek Banko -
Timothy Pearson