-----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
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.
On 2014/12/08 06:30 PM, Slávek Banko wrote:
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
On Monday 08 of December 2014 10:34:32 Michele Calgaro wrote:
On 2014/12/08 06:30 PM, Slávek Banko wrote:
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
I suppose after tagging can be created a branch. The name for the branch v14.0.x or v14.0-sru? Or otherwise?
On 2014/12/08 06:51 PM, Slávek Banko wrote:
On Monday 08 of December 2014 10:34:32 Michele Calgaro wrote:
On 2014/12/08 06:30 PM, Slávek Banko wrote:
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
I suppose after tagging can be created a branch. The name for the branch v14.0.x or v14.0-sru? Or otherwise?
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
Dne po 8. prosince 2014 Michele Calgaro napsal(a):
On 2014/12/08 06:51 PM, Slávek Banko wrote:
On Monday 08 of December 2014 10:34:32 Michele Calgaro wrote:
On 2014/12/08 06:30 PM, Slávek Banko wrote:
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
I suppose after tagging can be created a branch. The name for the branch v14.0.x or v14.0-sru? Or otherwise?
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
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.
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
Dne út 9. prosince 2014 Michele Calgaro napsal(a):
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
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.
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
On Wednesday 10 of December 2014 03:41:19 Michele Calgaro wrote:
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
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.
On 12/11/2014 06:54 AM, Slávek Banko wrote:
On Wednesday 10 of December 2014 03:41:19 Michele Calgaro wrote:
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
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
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
On Wednesday 10 of December 2014 05:51:40 Michele Calgaro wrote:
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.
- Bug 2246 - R14.0.1 resolved bug list (meta bug)
- Bug 2247 - R14.1.0 resolved bug list (meta bug)
- 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
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?
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
On Friday 12 of December 2014 02:38:37 Michele Calgaro wrote:
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:
- initial bug request from users goes into bug 2233
- 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
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.
-
Michele Calgaro -
Slávek Banko -
Timothy Pearson