Re: [Libreoffice-qa] Lifecycle of builds?
Robinson Tryon píše v Po 15. 04. 2013 v 11:21 -0400: BTW: ESC has had nothing against the one month after the last planned release. If you update the wiki pages with the dates that would be cool. Great! Pages are now updated. I think we're basically done with our EOL Action Item now. Great. Thanks a lot for help. Best Regards, Petr ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Lifecycle of builds?
Robinson Tryon píše v Pá 12. 04. 2013 v 13:24 -0400: On Fri, Apr 12, 2013 at 4:00 AM, Petr Mladek pmla...@suse.cz wrote: Regarding the EOL date, I've mocked-up an example of how we could display it on the wiki page: https://wiki.documentfoundation.org/Talk:ReleasePlan#Draft:_Adding_EOL_to_the_table (I grabbed the date from the image; Petr's date was Aug 14, 2013, which also sounds fine to me) I like the first proposal. Thanks a lot for looking at it. BTW: ESC has had nothing against the one month after the last planned release. If you update the wiki pages with the dates that would be cool. Best Regards, Petr ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Lifecycle of builds?
On Mon, Apr 15, 2013 at 5:53 AM, Petr Mladek pmla...@suse.cz wrote: Robinson Tryon píše v Pá 12. 04. 2013 v 13:24 -0400: On Fri, Apr 12, 2013 at 4:00 AM, Petr Mladek pmla...@suse.cz wrote: Regarding the EOL date, I've mocked-up an example of how we could display it on the wiki page: https://wiki.documentfoundation.org/Talk:ReleasePlan#Draft:_Adding_EOL_to_the_table (I grabbed the date from the image; Petr's date was Aug 14, 2013, which also sounds fine to me) I like the first proposal. Thanks a lot for looking at it. You're welcome :-) BTW: ESC has had nothing against the one month after the last planned release. If you update the wiki pages with the dates that would be cool. Great! Pages are now updated. I think we're basically done with our EOL Action Item now. -R ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Lifecycle of builds?
Robinson Tryon píše v Čt 11. 04. 2013 v 12:26 -0400: On Thu, Apr 11, 2013 at 4:08 AM, Petr Mladek pmla...@suse.cz wrote: Robinson Tryon píše v St 10. 04. 2013 v 11:29 -0400: I think that only the single EOL date make sense. We do not provide bugfix releases for bugfix releases. We provide bugfix releases for the minor version X.Y. +1 Perhaps we could add some language on the ReleasePlan page to help telegraph the impending end of the series? ... I have updated the table title at https://wiki.documentfoundation.org/ReleasePlan to mention basic dates for the initial and bugfix releases. I wonder if this might be enough. I think that helps a bit. I believe I understand the situation a bit better now that we've had the conversation, but I'm still slightly confused about the versioning, and that makes me wonder if users would also find themselves confused :-) Taking the 3.6 branch as an example, the first release came out by Aug 12th., after which point there were no new major/minor builds until 4.0 was released just after 3.6.5 in February. That means that for 6 months, the 3.6 branch was our most up-to-date release. That also means (if I understand correctly) that we didn't ship any new features for 6 months. Is that correct? Yes, it is correct. I have just tried to slightly improve https://wiki.documentfoundation.org/ReleasePlan#Summary and https://wiki.documentfoundation.org/ReleasePlan#Schedule You might want to read the rules for committing into the different branches, see https://wiki.documentfoundation.org/Development/Branches In theory, it is possible to get feature even into the bugfix release. In practice, it happens only for .1 or .2 bugfix release and only very rarely. And it is never anything big. These are usually some changes where it is hard to decide if it is a feature or a bug fix. Also you might want to look at http://cgit.freedesktop.org/libreoffice/core/log/ http://cgit.freedesktop.org/libreoffice/core/log/?h=libreoffice-4-0 It shows that master branch got more commits within last 24 hours than the stable 4-0 branch within 2 weeks. It shows that we are pretty conservative about the stable and feature complete branches. Best Regards, Petr ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Lifecycle of builds?
On Fri, Apr 12, 2013 at 4:00 AM, Petr Mladek pmla...@suse.cz wrote: Taking the 3.6 branch as an example, the first release came out by Aug 12th., after which point there were no new major/minor builds until 4.0 was released just after 3.6.5 in February. That means that for 6 months, the 3.6 branch was our most up-to-date release. That also means (if I understand correctly) that we didn't ship any new features for 6 months. Is that correct? Yes, it is correct. I have just tried to slightly improve https://wiki.documentfoundation.org/ReleasePlan#Summary and https://wiki.documentfoundation.org/ReleasePlan#Schedule Looking good. You might want to read [...a bunch of stuff...] So much to read! :-) I've read a bit of that, but I'll try to find time to read more of that soon when I take a break from updating wiki pages... Regarding the EOL date, I've mocked-up an example of how we could display it on the wiki page: https://wiki.documentfoundation.org/Talk:ReleasePlan#Draft:_Adding_EOL_to_the_table (I grabbed the date from the image; Petr's date was Aug 14, 2013, which also sounds fine to me) --R ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Lifecycle of builds?
Robinson Tryon píše v St 10. 04. 2013 v 11:29 -0400: On Wed, Apr 10, 2013 at 10:33 AM, Petr Mladek pmla...@suse.cz wrote: I see that you both use a bit different logic, so we need to decide how we count the 6 and 9 months. I understand it the following way: + the release is defined by the minor version release, e.g. 3.6 or 4.0 + regular and extra bugfix releases are provided during the life time + the life starts with the .0 release + the life ends when we are not willing to provide any new bugfix release So would we provide an EOL date for each point release in a series, or just a single EOL date for all of our 3.6.x released builds? I think that only the single EOL date make sense. We do not provide bugfix releases for bugfix releases. We provide bugfix releases for the minor version X.Y. I think that it would be fair to make it live at least 4 weeks after the last scheduled bugfix release. By other words, we should provide extra bugfix release if we add serious regression into the last bugfix release. 4 weeks of support for a regular build seems pretty short, but when you describe it as a bugfix release, it makes a lot more sense in my mind. Yes, I think that it can't work any other way. For example, if we supported 3.6.7 for 6 months, we might need to release 3.6.8 to fix a security problem. 3.6.8 would trigger another 6 months, ... We simply need to cat it at some stage :-) Perhaps we could add some language on the ReleasePlan page to help telegraph the impending end of the series? Maybe in the tables of releases: 3.6.0 ... 3.6.6 bugfix 3.6.7 bugfix I have updated the table title at https://wiki.documentfoundation.org/ReleasePlan to mention basic dates for the initial and bugfix releases. I wonder if this might be enough. It is basically what Michael mentioned because the .0 release is for early adopters. The release is stable around .3 bugfix relase which is 3 months after the .0 release. Ah, okay, so perhaps a new column in the table: 3.6.0 - early adopters 3.6.1 - (or maybe 'unstable'? marketing would hate that..) 3.6.2 - (Better: leave it empty until we can mark it 'stable' :-) 3.6.3 - stable ... 3.6.6 - bugfix 3.6.7 - bugfix I would prefer to avoid these statements. Every release is different. Some are pretty good from the .0 release. Some need more love. In addition, it is individual. Some bugs might be critical for a certain group of users and uninteresting for others. In each case, we need to be in sync with the statement on the official download page that is created by the marketing team. I wonder if there is a list of certified developers somewhere. I have found only the description at https://wiki.documentfoundation.org/TDFCertification https://www.documentfoundation.org/certification/developers/ Thanks for the link. I would suggest that you link to some internal page on the wiki (say TDF/certification), as it's likely that other pages will want to mention the certification program or the currently-certified developers. I am not sure how you mean this. Feel free to update the wiki. Note that there is https://wiki.documentfoundation.org/TDFCertification but the text need to be approved by BoD. You might need to discuss it with them. Best Regards, Petr ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Lifecycle of builds?
On Thu, Apr 11, 2013 at 4:08 AM, Petr Mladek pmla...@suse.cz wrote: Robinson Tryon píše v St 10. 04. 2013 v 11:29 -0400: So would we provide an EOL date for each point release in a series, or just a single EOL date for all of our 3.6.x released builds? I think that only the single EOL date make sense. We do not provide bugfix releases for bugfix releases. We provide bugfix releases for the minor version X.Y. +1 Perhaps we could add some language on the ReleasePlan page to help telegraph the impending end of the series? ... I have updated the table title at https://wiki.documentfoundation.org/ReleasePlan to mention basic dates for the initial and bugfix releases. I wonder if this might be enough. I think that helps a bit. I believe I understand the situation a bit better now that we've had the conversation, but I'm still slightly confused about the versioning, and that makes me wonder if users would also find themselves confused :-) Taking the 3.6 branch as an example, the first release came out by Aug 12th., after which point there were no new major/minor builds until 4.0 was released just after 3.6.5 in February. That means that for 6 months, the 3.6 branch was our most up-to-date release. That also means (if I understand correctly) that we didn't ship any new features for 6 months. Is that correct? Ah, okay, so perhaps a new column in the table: 3.6.0 - early adopters 3.6.1 - (or maybe 'unstable'? marketing would hate that..) 3.6.2 - (Better: leave it empty until we can mark it 'stable' :-) 3.6.3 - stable ... 3.6.6 - bugfix 3.6.7 - bugfix I would prefer to avoid these statements. Every release is different. Some are pretty good from the .0 release. Some need more love. In addition, it is individual. Some bugs might be critical for a certain group of users and uninteresting for others. Fair enough. As I said above, I guess I'm just trying to make better sense of the nature of the point releases. Cheers, --R ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Lifecycle of builds?
Hi Robinson, On Tue, 2013-04-09 at 19:52 -0400, Robinson Tryon wrote: As Pedro mentioned, and as far as I understand it, our next step is to pick an EOL date for each of our builds and then go update the wiki pages. I'd be happy to help update the ReleaseNotes wiki pages, or to ping pmladek and hand that task over to him. Well - I guess Petr is the best guy to hack that page :-) Mmeeks suggested in this thread that 3.5.x should be considered EOL at this point. As the last release (3.5.7) shipped about 6 months ago, I suggest 6 months as the standard lifetime for our stable, shipped builds. Seems reasonable - 3.6.x will last a bit longer because of the jump to 4.0 I think; currently planned at 9 months. Would changing 'Old Releases' to End of Life Releases in: https://wiki.documentfoundation.org/ReleasePlan do it ? with a bit of text saying: A release normally has a lifetime of around six months, however if you want longer term support for a release, you're encouraged to engaged any certified L3 provider to provide you with support. or something. Why add that marketing blurb ? I don't want people to think the code is un-supportable after 6 months; in fact we (SUSE) continue to support branches based on old releases for our customers, and the lifetime can play into product choice decisions. How does that sound ? Thanks for following this up ! All the best, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Lifecycle of builds?
Michael Meeks-2 wrote Seems reasonable - 3.6.x will last a bit longer because of the jump to 4.0 I think; currently planned at 9 months. So End of Life occurs 6 months after the official release date of the final release for each branch (usually final version is x.x.7) and occurs after 9 months for the final release before a major version change (e.g from 3.x to 4.x)? Can it be assumed that the official release date is the date when it is announced on the official blog? http://blog.documentfoundation.org/ Therefore EOL for branch 3.5 is on April 18th (http://blog.documentfoundation.org/2012/10/18/the-document-foundation-announces-libreoffice-3-5-7/), right? EOL for branch 3.6 should be removed from the image since release x.x.7 isn't out yet Does this also mean that 3.4 versions can already be removed from the bugzilla Version picker? And 3.5 versions after the 18th of this month? Cheers, Pedro -- View this message in context: http://nabble.documentfoundation.org/Libreoffice-qa-Lifecycle-of-builds-tp4048583p4048978.html Sent from the QA mailing list archive at Nabble.com. ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Lifecycle of builds?
Pedro wrote: Does this also mean that 3.4 versions can already be removed from the bugzilla Version picker? And 3.5 versions after the 18th of this month? Hi Pedro, no, we can't. Version info in BZ should show where the bug appeared (or at least has been observed the first time), also see https://wiki.documentfoundation.org/BugReport_Details#Version. That has nothing to do with our maintenance for a Version branch. Please also see [Libreoffice-qa] Removing LibO 3.3 from Versions dropdown in Bugzilla, where I demonstrated some criteria for versions removal. I think End of 2013 we can think about something similar for 3.4. Best regards Rainer ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Lifecycle of builds?
Hi Rainer Rainer Bielefeld-2 wrote Version info in BZ should show where the bug appeared (or at least has been observed the first time) The point here is that if a version is past the EOL and nobody will fix bugs in that branch, there is no point in reporting bugs first observed in 3.4 or 3.5 (otherwise you should NOT remove 3.3 from the list either) Rainer Bielefeld-2 wrote I think End of 2013 we can think about something similar for 3.4. Isn't that up to the BOD to decide? If the EOL was after 6 months why End of 2013? Cheers, Pedro -- View this message in context: http://nabble.documentfoundation.org/Libreoffice-qa-Lifecycle-of-builds-tp4048583p4049029.html Sent from the QA mailing list archive at Nabble.com. ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Lifecycle of builds?
Pedro schrieb: The point here is that if a version is past the EOL and nobody will fix bugs in that branch, there is no point in reporting bugs first observed in 3.4 or 3.5 (otherwise you should NOT remove 3.3 from the list either) Hi Pedro, you are completely wrong, I doubt that you read the linked texts. Isn't that up to the BOD to decide? If the EOL was after 6 months why End of 2013? I do not see to what you refer, my comment was concerning removal of 3.4 versions from BZ Version picker (the same way I will do for 3.3 this week), what is completely out of BODs interest. CU Rainer ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Lifecycle of builds?
On Wed, Apr 10, 2013 at 8:02 AM, Rainer Bielefeld libreoff...@bielefeldundbuss.de wrote: Pedro wrote: Does this also mean that 3.4 versions can already be removed from the bugzilla Version picker? And 3.5 versions after the 18th of this month? Hi Pedro, no, we can't. Version info in BZ should show where the bug appeared (or at least has been observed the first time) It sounds like we're got a balancing act: Provide enough versions in the picker that one has some granularity, but not clog-up the picker with tons of old version numbers, including beta builds, etc.. https://wiki.documentfoundation.org/BugReport_Details#Version. That has nothing to do with our maintenance for a Version branch. Not sure what's relevant on that page... Please also see [Libreoffice-qa] Removing LibO 3.3 from Versions dropdown in Bugzilla, where I demonstrated some criteria for versions removal. Link for easy reading :-) http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.qa/3962 Rainer wrote: So I believe we should mark the not-release-3.3 as inactive, what means they will stay for the bugs where they are used, but can not be used for new bug reports (except by the LibO Bugzilla Administrators) because they will no longer be shown in the Versions selector. To riff off of your suggestion, perhaps we can do our cleanup in stages: 1) When we EOL a stable release such as 3.5.5, we remove (i.e. mark as inactive) all of the not-release-3.5.5.x versions from the bugtracker. This will still allow us to report bugs against the stable release, and if someone wants to test against a beta build and insert that information into the bug report (or even into the Summary), then that possibility remains. 2) When we EOL a release series such as 3.5, we *could* do more cleanup, but there still may be end users running those stable builds. As Michael pointed out, we still have companies interested in maintenance on those older versions. Ubuntu 12.04 still has a 3.5 build, and I'm not sure if/when that will be upgraded. Realistically, I think we can punt on this piece of the puzzle until another day. Thoughts? Cheers, --R ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Lifecycle of builds?
Hi Rainer Rainer Bielefeld-2 wrote you are completely wrong, I doubt that you read the linked texts. I did read the texts. Have you considered the hypothesis that YOU might be wrong? You are confusing QA work with a reporter's work. Someone who submits a bug is going to report the version where he found the bug. He is not going to install previous versions to check back. That is QA work. So maybe there should be two separate fields: one for the reporter to indicate in which version he observed the bug and another field for the QA (or the reporter if he is willing to do that) to report in which version it was first observed (if it is a new bug, i.e. not a regression then both fields match) In the QA field ALL versions including the 3.3 branch should show up. Maybe in the user field only actively developed versions should show up? If bugs are not going to be fixed in EOL branches it makes more sense to advise the user to update to a live branch and then to report the bug if it still exists... Regards, Pedro -- View this message in context: http://nabble.documentfoundation.org/Libreoffice-qa-Lifecycle-of-builds-tp4048583p4049059.html Sent from the QA mailing list archive at Nabble.com. ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Lifecycle of builds?
Michael Meeks píše v St 10. 04. 2013 v 10:25 +0100: Hi Robinson, On Tue, 2013-04-09 at 19:52 -0400, Robinson Tryon wrote: As Pedro mentioned, and as far as I understand it, our next step is to pick an EOL date for each of our builds and then go update the wiki pages. I'd be happy to help update the ReleaseNotes wiki pages, or to ping pmladek and hand that task over to him. Well - I guess Petr is the best guy to hack that page :-) Mmeeks suggested in this thread that 3.5.x should be considered EOL at this point. As the last release (3.5.7) shipped about 6 months ago, I suggest 6 months as the standard lifetime for our stable, shipped builds. Seems reasonable - 3.6.x will last a bit longer because of the jump to 4.0 I think; currently planned at 9 months. I see that you both use a bit different logic, so we need to decide how we count the 6 and 9 months. I understand it the following way: + the release is defined by the minor version release, e.g. 3.6 or 4.0 + regular and extra bugfix releases are provided during the life time + the life starts with the .0 release + the life ends when we are not willing to provide any new bugfix release I think that it would be fair to make it live at least 4 weeks after the last scheduled bugfix release. By other words, we should provide extra bugfix release if we add serious regression into the last bugfix release. If we do it this way, the numbers would look like: version start endlength + 3.6 Aug 8, 2012 Aug 14, 2013 12 months + 4.0 Feb 6, 2013 Nov 20, 2013 9 months + 4.1 Jul 24, 2013May 28, 2013 9 months It is basically what Michael mentioned because the .0 release is for early adopters. The release is stable around .3 bugfix relase which is 3 months after the .0 release. Would changing 'Old Releases' to End of Life Releases in: https://wiki.documentfoundation.org/ReleasePlan Done, including the marketing hint, see https://wiki.documentfoundation.org/ReleasePlan#End_of_Life_Releases I wonder if there is a list of certified developers somewhere. I have found only the description at https://wiki.documentfoundation.org/TDFCertification ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Lifecycle of builds?
Robinson Tryon wrote Oh, certainly. Perhaps Pedro meant that we shouldn't remove *all* of the 3.3 builds from the picker, for this very reason. Rainer described this as not-release-3.3 [builds]. I think we're mostly in agreement here :-) Yes, exactly. I just read the title of Rainer other thread. I wrongly assumed he meant removing ALL 3.3 versions except for version LibO 3.3.0 Beta2. Apologies on the confusion. See my previous mail with suggestion on having two separate fields: one for the version reported (where the user observed it) and one for the first occurrence (determined by QA) Regards, Pedro -- View this message in context: http://nabble.documentfoundation.org/Libreoffice-qa-Lifecycle-of-builds-tp4048583p4049069.html Sent from the QA mailing list archive at Nabble.com. ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Lifecycle of builds?
Robinson Tryon píše v St 10. 04. 2013 v 10:12 -0400: On Wed, Apr 10, 2013 at 8:02 AM, Rainer Bielefeld Rainer wrote: So I believe we should mark the not-release-3.3 as inactive, what means they will stay for the bugs where they are used, but can not be used for new bug reports (except by the LibO Bugzilla Administrators) because they will no longer be shown in the Versions selector. Nice feature To riff off of your suggestion, perhaps we can do our cleanup in stages: Makes sense. 1) When we EOL a stable release such as 3.5.5, we remove (i.e. mark as inactive) all of the not-release-3.5.5.x versions from the bugtracker. I think that it is hard to define life time for a bugfix release. It is basically obsoleted by the next bugfix release for the given minor version. If we accept this, it would mean to remove betas and rcs for X.Y.Z when X.Y.Z+1 bugfix release is released. For example, remove 4.0.2 RCs when 4.0.3 is released. It could work. The logic here is that people, who install RCs from prerelease, usually install newer RCs when they are available. The RCs granularity gets outdated with next release because most people do not have them installed. If anyone wants to find when it exactly got broken, they probably use bibisect which uses another identification. Maybe we could wait one more bugfix release, just for sure. See below. 2) When we EOL a release series such as 3.5, we *could* do more cleanup, but there still may be end users running those stable builds. As Michael pointed out, we still have companies interested in maintenance on those older versions. Ubuntu 12.04 still has a 3.5 build, and I'm not sure if/when that will be upgraded. Realistically, I think we can punt on this piece of the puzzle until another day. I would probably leave it a bit longer. It seems that people still use different 3.4.x bugfix releases. I did a query for bugs reported this year: + 64 bugs are marked against the version 3.4.* + 1 is against 3.4.*RC.* (fdo#53725) + 2 are against 3.4.6 release (last one) + 61 are against other 3.4.x releases Best Regards, Petr ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Lifecycle of builds?
On Wed, Apr 10, 2013 at 10:33 AM, Petr Mladek pmla...@suse.cz wrote: I see that you both use a bit different logic, so we need to decide how we count the 6 and 9 months. I understand it the following way: + the release is defined by the minor version release, e.g. 3.6 or 4.0 + regular and extra bugfix releases are provided during the life time + the life starts with the .0 release + the life ends when we are not willing to provide any new bugfix release So would we provide an EOL date for each point release in a series, or just a single EOL date for all of our 3.6.x released builds? Granularity is nice, but one EOL for the entire release series might be easier to manage. I'd often thought of each 3.5.x build as a separate release, but as you describe it, it's mostly just a maintenance schedule. I think that it would be fair to make it live at least 4 weeks after the last scheduled bugfix release. By other words, we should provide extra bugfix release if we add serious regression into the last bugfix release. 4 weeks of support for a regular build seems pretty short, but when you describe it as a bugfix release, it makes a lot more sense in my mind. Perhaps we could add some language on the ReleasePlan page to help telegraph the impending end of the series? Maybe in the tables of releases: 3.6.0 ... 3.6.6 bugfix 3.6.7 bugfix Is there a better/shorter label we could apply there? If we do it this way, the numbers would look like: version start endlength + 3.6 Aug 8, 2012 Aug 14, 2013 12 months + 4.0 Feb 6, 2013 Nov 20, 2013 9 months + 4.1 Jul 24, 2013May 28, 2013 9 months It is basically what Michael mentioned because the .0 release is for early adopters. The release is stable around .3 bugfix relase which is 3 months after the .0 release. Ah, okay, so perhaps a new column in the table: 3.6.0 - early adopters 3.6.1 - (or maybe 'unstable'? marketing would hate that..) 3.6.2 - (Better: leave it empty until we can mark it 'stable' :-) 3.6.3 - stable ... 3.6.6 - bugfix 3.6.7 - bugfix Then if we had to add an extra bugfix, we could do something like 3.6.8 - special bugfix Unlike the rest of the information in the table, the labels in this column could be added at each new release, especially as we don't know at the outset which point release we'll feel confident to mark as 'stable'. I wonder if there is a list of certified developers somewhere. I have found only the description at https://wiki.documentfoundation.org/TDFCertification https://www.documentfoundation.org/certification/developers/ I would suggest that you link to some internal page on the wiki (say TDF/certification), as it's likely that other pages will want to mention the certification program or the currently-certified developers. --R ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Lifecycle of builds?
On Mon, 2013-04-08 at 09:05 -0700, Pedro wrote: I think End of Life in that image doesn't mean the same as it does for Microsoft software (or any other software I know)... http://en.wikipedia.org/wiki/End-of-life_%28product%29 :-) and of course these versions can be supported, and have patches pushed to them in git for many years to come if people care about them. As Pedro says we have a 3.6.7 planned for that branch. But I do agree that it would make a LOT of sense to have that established so that not only some stuff can be cleaned up but also so that people at AskLibO (or any other support channel) can tell people that the version x is no longer supported and that they really need to update their software :) Right - so anyone using 3.5.x or earlier at this stage needs to either buy commercial support for that version or upgrade (IMHO) there is ~no-one that I know of interested in providing security fixes / updates for that tree. We're also feature-freezing 4.1 in ~six weeks ... What we call that - FWIW I like End of Life better than End of Support - because (really) support is a bit misleading and sounds like an entitlement, and EOL is a well-known acroynm. Is there a better name ? HTH, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Lifecycle of builds?
Hi Michael, all Michael Meeks-2 wrote Right - so anyone using 3.5.x or earlier at this stage needs to either buy commercial support for that version or upgrade (IMHO) there is ~no-one that I know of interested in providing security fixes / updates for that tree. I think the BOD should officially set some dates and post them on the wiki. Something like this http://support.microsoft.com/lifecycle/default.aspx?LN=en-usx=5y=13c2=1173 Michael Meeks-2 wrote What we call that - FWIW I like End of Life better than End of Support - because (really) support is a bit misleading and sounds like an entitlement, and EOL is a well-known acroynm. Is there a better name ? I believe EOL is fine. The image just needs to be corrected by user uroveits. I would simply remove that EOL thing until the BOD has some official dates. In any case I think he/she just copied the dates from the release plan... Version 3.5.7 was officially announced on October 18th so it could not be EOL even before it was announced... Maybe he/she meant End of Line or End of Development for the branch??? But doesn't apply (yet) to the 3.6 branch... Cheers, Pedro -- View this message in context: http://nabble.documentfoundation.org/Libreoffice-qa-Lifecycle-of-builds-tp4048583p4048810.html Sent from the QA mailing list archive at Nabble.com. ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Lifecycle of builds?
Hi *, Am 09.04.2013 15:53, schrieb Pedro: The image just needs to be corrected by user uroveits. I´m uroveits. I've been watching this thread and I will change the graphic when EOL has been set. Regards Jochen ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Lifecycle of builds?
On Tue, Apr 9, 2013 at 3:08 PM, Jochen oo...@jochenschiffers.de wrote: Hi *, Am 09.04.2013 15:53, schrieb Pedro: The image just needs to be corrected by user uroveits. I´m uroveits. I've been watching this thread and I will change the graphic when EOL has been set. :-) Great. As Pedro mentioned, and as far as I understand it, our next step is to pick an EOL date for each of our builds and then go update the wiki pages. I'd be happy to help update the ReleaseNotes wiki pages, or to ping pmladek and hand that task over to him. Mmeeks suggested in this thread that 3.5.x should be considered EOL at this point. As the last release (3.5.7) shipped about 6 months ago, I suggest 6 months as the standard lifetime for our stable, shipped builds. Thoughts? --R ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Lifecycle of builds?
Hi Robinson I think End of Life in that image doesn't mean the same as it does for Microsoft software (or any other software I know)... http://en.wikipedia.org/wiki/End-of-life_%28product%29 In fact version 3.6.6 will be released on April 14th, so I doubt that is the End of Life, especially because branch 3.6 is not dead (yet) http://dev-builds.libreoffice.org/daily/libreoffice-3-6/Win-x86@6/current/ There is possibly going to be a 3.6.7 release? But I do agree that it would make a LOT of sense to have that established so that not only some stuff can be cleaned up but also so that people at AskLibO (or any other support channel) can tell people that the version x is no longer supported and that they really need to update their software :) Cheers, Pedro -- View this message in context: http://nabble.documentfoundation.org/Libreoffice-qa-Lifecycle-of-builds-tp4048583p4048605.html Sent from the QA mailing list archive at Nabble.com. ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
