TSCDecisions - Revision history

Rpurdie: /* 2010/11/03 */

2010-11-03T17:16:51Z

2010/11/03

← Older revision		Revision as of 17:16, 3 November 2010
Line 11:		Line 11:
	* For the fetch/unpack issues, moving the unpack code into bitbake and calling into the fetchers to run the unpack command is looking like the preferred option. Using the opportunity to clean up the fetcher code is desirable with a "fetch2" implementation in bitbake being acceptable. The TSC supports the idea in principle subject to final review of the patches.		* For the fetch/unpack issues, moving the unpack code into bitbake and calling into the fetchers to run the unpack command is looking like the preferred option. Using the opportunity to clean up the fetcher code is desirable with a "fetch2" implementation in bitbake being acceptable. The TSC supports the idea in principle subject to final review of the patches.

	* FILESPATH - This doesn't scale well with layers and the TSC supports the idea of ~~having recipes specify which~~ directories ~~to search for files in principle~~. The ~~exactly~~ solution still needs to be determined.		* FILESPATH - This doesn't scale well with layers and the TSC supports the idea of reducing the number of directories listed. The exact solution still needs to be determined.

Rpurdie: /* 2010/11/03 */

2010-11-03T17:11:39Z

2010/11/03

← Older revision		Revision as of 17:11, 3 November 2010
Line 11:		Line 11:
	* For the fetch/unpack issues, moving the unpack code into bitbake and calling into the fetchers to run the unpack command is looking like the preferred option. Using the opportunity to clean up the fetcher code is desirable with a "fetch2" implementation in bitbake being acceptable. The TSC supports the idea in principle subject to final review of the patches.		* For the fetch/unpack issues, moving the unpack code into bitbake and calling into the fetchers to run the unpack command is looking like the preferred option. Using the opportunity to clean up the fetcher code is desirable with a "fetch2" implementation in bitbake being acceptable. The TSC supports the idea in principle subject to final review of the patches.

	* FILESPATH		* FILESPATH - This doesn't scale well with layers and the TSC supports the idea of having recipes specify which directories to search for files in principle. The exactly solution still needs to be determined.

Rpurdie: /* 2010/11/03 */

2010-11-03T17:04:43Z

2010/11/03

← Older revision		Revision as of 17:04, 3 November 2010
Line 8:		Line 8:

	* The TSC considered the issue of staggered election of its members. It felt that with members serving a one year term, staggering this could lead to a lot of "paperwork" without any real net benefit. If the OE members wish the TSC to do this, they are happy to do so though, they would just like to see member representation of this.		* The TSC considered the issue of staggered election of its members. It felt that with members serving a one year term, staggering this could lead to a lot of "paperwork" without any real net benefit. If the OE members wish the TSC to do this, they are happy to do so though, they would just like to see member representation of this.

			* For the fetch/unpack issues, moving the unpack code into bitbake and calling into the fetchers to run the unpack command is looking like the preferred option. Using the opportunity to clean up the fetcher code is desirable with a "fetch2" implementation in bitbake being acceptable. The TSC supports the idea in principle subject to final review of the patches.

			* FILESPATH

Rpurdie at 16:53, 3 November 2010

2010-11-03T16:53:04Z

← Older revision		Revision as of 16:53, 3 November 2010
Line 6:		Line 6:

	* The TSC feels bitbake 1.8 should be an option for the upcoming OE December stable release as switching to 1.10 before the release is too soon. After the release OE.master should switch to 1.10. For reference, standalone python binaries from Yocto can be used (https://lists.yoctoproject.org/pipermail/yocto/2010-November/000176.html) on systems which don't have a recent python version.		* The TSC feels bitbake 1.8 should be an option for the upcoming OE December stable release as switching to 1.10 before the release is too soon. After the release OE.master should switch to 1.10. For reference, standalone python binaries from Yocto can be used (https://lists.yoctoproject.org/pipermail/yocto/2010-November/000176.html) on systems which don't have a recent python version.

			* The TSC considered the issue of staggered election of its members. It felt that with members serving a one year term, staggering this could lead to a lot of "paperwork" without any real net benefit. If the OE members wish the TSC to do this, they are happy to do so though, they would just like to see member representation of this.

Rpurdie: /* 2010/11/03 */

2010-11-03T16:43:49Z

2010/11/03

← Older revision		Revision as of 16:43, 3 November 2010
Line 5:		Line 5:
	* The TSC supports the idea of regular patchwork days and proposes these should be on a regular timeslot around a Friday/Weekend/Monday on a monthly basis. Stefan Schmidt has kindly volunteered to coordinate these and has the support of the TSC. Mickey takes the action to communicate this to members via email.		* The TSC supports the idea of regular patchwork days and proposes these should be on a regular timeslot around a Friday/Weekend/Monday on a monthly basis. Stefan Schmidt has kindly volunteered to coordinate these and has the support of the TSC. Mickey takes the action to communicate this to members via email.

	* The TSC feels bitbake 1.8 should be an option for the upcoming OE December stable release as switching to 1.10 before the release is too soon. After the release OE.master should switch to 1.10. For reference, standalone python binaries from Yocto can be used (https://lists.yoctoproject.org/pipermail/yocto/2010-November/000176.html)		* The TSC feels bitbake 1.8 should be an option for the upcoming OE December stable release as switching to 1.10 before the release is too soon. After the release OE.master should switch to 1.10. For reference, standalone python binaries from Yocto can be used (https://lists.yoctoproject.org/pipermail/yocto/2010-November/000176.html) on systems which don't have a recent python version.

Rpurdie: /* 2010/11/03 */

2010-11-03T16:43:15Z

2010/11/03

← Older revision		Revision as of 16:43, 3 November 2010
Line 5:		Line 5:
	* The TSC supports the idea of regular patchwork days and proposes these should be on a regular timeslot around a Friday/Weekend/Monday on a monthly basis. Stefan Schmidt has kindly volunteered to coordinate these and has the support of the TSC. Mickey takes the action to communicate this to members via email.		* The TSC supports the idea of regular patchwork days and proposes these should be on a regular timeslot around a Friday/Weekend/Monday on a monthly basis. Stefan Schmidt has kindly volunteered to coordinate these and has the support of the TSC. Mickey takes the action to communicate this to members via email.

	* The TSC feels bitbake 1.8 should be an option for the upcoming stable release as switching to 1.10 before the release is too soon. After the release OE.~~dev~~ should ~~swicth~~ to 1.10. For reference, standalone python ~~bianries~~ from Yocto can be used (https://lists.yoctoproject.org/pipermail/yocto/2010-November/000176.html)		* The TSC feels bitbake 1.8 should be an option for the upcoming OE December stable release as switching to 1.10 before the release is too soon. After the release OE.master should switch to 1.10. For reference, standalone python binaries from Yocto can be used (https://lists.yoctoproject.org/pipermail/yocto/2010-November/000176.html)

Rpurdie: /* 2010/11/03 */

2010-11-03T16:42:36Z

2010/11/03

← Older revision		Revision as of 16:42, 3 November 2010
Line 5:		Line 5:
	* The TSC supports the idea of regular patchwork days and proposes these should be on a regular timeslot around a Friday/Weekend/Monday on a monthly basis. Stefan Schmidt has kindly volunteered to coordinate these and has the support of the TSC. Mickey takes the action to communicate this to members via email.		* The TSC supports the idea of regular patchwork days and proposes these should be on a regular timeslot around a Friday/Weekend/Monday on a monthly basis. Stefan Schmidt has kindly volunteered to coordinate these and has the support of the TSC. Mickey takes the action to communicate this to members via email.

	* The TSC feels bitbake 1.8 should be ~~used~~ for the upcoming stable release as switching to 1.10 before the release is too soon. After the release OE.dev should swicth to 1.10. For reference, standalone python bianries from Yocto can be used (https://lists.yoctoproject.org/pipermail/yocto/2010-November/000176.html)		* The TSC feels bitbake 1.8 should be an option for the upcoming stable release as switching to 1.10 before the release is too soon. After the release OE.dev should swicth to 1.10. For reference, standalone python bianries from Yocto can be used (https://lists.yoctoproject.org/pipermail/yocto/2010-November/000176.html)

Rpurdie at 16:41, 3 November 2010

2010-11-03T16:41:47Z

← Older revision		Revision as of 16:41, 3 November 2010
Line 5:		Line 5:
	* The TSC supports the idea of regular patchwork days and proposes these should be on a regular timeslot around a Friday/Weekend/Monday on a monthly basis. Stefan Schmidt has kindly volunteered to coordinate these and has the support of the TSC. Mickey takes the action to communicate this to members via email.		* The TSC supports the idea of regular patchwork days and proposes these should be on a regular timeslot around a Friday/Weekend/Monday on a monthly basis. Stefan Schmidt has kindly volunteered to coordinate these and has the support of the TSC. Mickey takes the action to communicate this to members via email.

	* The TSC feels bitbake 1.8 should be used for the upcoming stable release as switching to 1.10 before the release is too soon. After the release OE.dev should swicth to 1.10		* The TSC feels bitbake 1.8 should be used for the upcoming stable release as switching to 1.10 before the release is too soon. After the release OE.dev should swicth to 1.10. For reference, standalone python bianries from Yocto can be used (https://lists.yoctoproject.org/pipermail/yocto/2010-November/000176.html)

Rpurdie at 16:37, 3 November 2010

2010-11-03T16:37:23Z

← Older revision		Revision as of 16:37, 3 November 2010
Line 5:		Line 5:
	* The TSC supports the idea of regular patchwork days and proposes these should be on a regular timeslot around a Friday/Weekend/Monday on a monthly basis. Stefan Schmidt has kindly volunteered to coordinate these and has the support of the TSC. Mickey takes the action to communicate this to members via email.		* The TSC supports the idea of regular patchwork days and proposes these should be on a regular timeslot around a Friday/Weekend/Monday on a monthly basis. Stefan Schmidt has kindly volunteered to coordinate these and has the support of the TSC. Mickey takes the action to communicate this to members via email.

	* The TSC feels bitbake 1.~~10 doesn't have any blocking issues for adoption and that it~~ should ~~become the default~~ for ~~OE.dev. This changes~~ the ~~base python requirement from python 2.4~~ to ~~python 2~~.5. ~~We propose a target date of 24th November meaning it can be included in~~ the ~~proposed~~ release of OE.		* The TSC feels bitbake 1.8 should be used for the upcoming stable release as switching to 1.10 before the release is too soon. After the release OE.dev should swicth to 1.10

Rpurdie at 16:31, 3 November 2010

2010-11-03T16:31:20Z

← Older revision		Revision as of 16:31, 3 November 2010
Line 3:		Line 3:
	= 2010/11/03 =		= 2010/11/03 =

	The TSC supports the idea of regular patchwork days and proposes these should be on a regular timeslot around a Friday/Weekend/Monday on a monthly basis. Stefan Schmidt has kindly volunteered to coordinate these and has the support of the TSC. Mickey takes the action to communicate this to members via email.		* The TSC supports the idea of regular patchwork days and proposes these should be on a regular timeslot around a Friday/Weekend/Monday on a monthly basis. Stefan Schmidt has kindly volunteered to coordinate these and has the support of the TSC. Mickey takes the action to communicate this to members via email.

			* The TSC feels bitbake 1.10 doesn't have any blocking issues for adoption and that it should become the default for OE.dev. This changes the base python requirement from python 2.4 to python 2.5. We propose a target date of 24th November meaning it can be included in the proposed release of OE.