* TSC Meeting 2010/03/02 @ 2010-03-03 11:35 Richard Purdie 2010-03-03 12:59 ` Frans Meulenbroeks 0 siblings, 1 reply; 9+ messages in thread From: Richard Purdie @ 2010-03-03 11:35 UTC (permalink / raw) To: openembedded-devel TSC Meeting 2010/03/02 We moved the time to Tuesday since I couldn't make Thursday. Unfortunately Mickey couldn't make Tuesday due to a last minute meeting but four of us met anyway to discuss various issues. The outcome of various topics was: Code of Conduct =============== We agreed we need one but also that its outside the remit of what the TSC should be discussing. We don't feel something heavy and draconian with every action spelt out is a sensible idea but we should have some guidelines behaviour can be judged against. In this respect we could do a lot worse than adopt the Ubuntu CoC (http://www.ubuntu.com/community/conduct). We'd like to propose to the e.V. board and members that the Ubuntu CoC should be adopted (wording adjusted to suit OE) by the OE e.V. The one problem here is that we don't have a community council. The TSC could serve as this but we'd prefer to split this work to a dedicated group. We'd like to ask the members to discuss this and see what people feel is the best thing to do. Elections ========= We agreed to hold TSC elections in April which means calling for candidates soon. We'd like to see active people wanting to move OE forward and would love to see come competition for the TSC places. Now we've established the format and input required hopefully more people will feel comfortable coming forward. For more information about what the role involves please talk to any existing TSC member. Angstrom ======== People do seem to use Angstrom as a target for certain discussions. The people involved have got on and made a success of a distribution and people should respect that. There are some customisations which could be more generic so other people would be more comfortable using them. These should be discussed and the Angstrom devs are amenable to that but breaking Angstrom for the benefit of others isn't really fair. Splitting Angstrom into its own directories (e.g. for images) is going a full circle as Angstrom did have that and was coerced into merging things. No solution will please everyone but before the TSC can get involved, discussions need to happen with clear proposals. Angstrom is not perfect but it has gone out there and achieved things which is worth keeping in mind. Developer Effort ================ Rather than discussions such as the above, how about injecting that energy into adopting the new staging, BBCLASSEXTEND and -nativesdk code? BBLayers ======== Mentioned briefly, no concerned we raised above those expressed already. Having coherent layer handling is desirable and the bitbake team will continue its work accordingly. Other Business ============== Apologies have been made to the TSC for my absence at the last meeting. There was some confusion on my part over the protocols and I didn't think the meeting was happening. Regards, Your TSC Graeme Gregory (XorA) Koen Kooi Chris Larson (kergoth) Michael 'Mickey' Lauer (mickeyl) Richard Purdie (RP) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: TSC Meeting 2010/03/02 2010-03-03 11:35 TSC Meeting 2010/03/02 Richard Purdie @ 2010-03-03 12:59 ` Frans Meulenbroeks 2010-03-03 13:26 ` Marcin Juszkiewicz 2010-03-03 13:47 ` Richard Purdie 0 siblings, 2 replies; 9+ messages in thread From: Frans Meulenbroeks @ 2010-03-03 12:59 UTC (permalink / raw) To: openembedded-devel Richard, thanks for the report. There are some remarks I want to make, see below. 2010/3/3 Richard Purdie <rpurdie@rpsys.net>: > TSC Meeting 2010/03/02 [...] > > Developer Effort > ================ > > Rather than discussions such as the above, how about injecting that > energy into adopting the new staging, BBCLASSEXTEND and -nativesdk code? Ehm. there was already a similar remark in the recent pango thread (angstrom: sync pango and pango-native versions) I'd say the tone in that email and in the two lines above does not really meet the 'be considerate" and 'be respectful' as described in the ubuntu code of conduct. Also note that most of the work is done by volunteers/hobbyists/whatever you want to name them. I feel it is not really for the TSC (or for me) to say what others should do. Suggestions could be made but I think it could be worded more polite. And wrt the new staging/BBCLASSEXTEND/nativesdk topic: In my opinion it is useful to clean up the existing recipes (or move them to 'obsolete' or whatever). That way less recipes need to be adopted, and no energy is wasted on adopting legacy recipes. (apart from the fact that having lots of recipes for lots of variants does not really give a professional and mature impression). BTW: The recipes I feel responsible for are all converted to both new staging and BBCLASSEXTEND. I have considered converting some of the others to new staging. Actually I even started it, but soon stopped with it for the following reasons: - the actual verification process is fairly cumbersome. (5) diff the 2 packaged-staging recipes (which I read as packaged-staging packages as there are no packaged-staging recipes) is imho a pita) - i have no idea what recipes are actually used and worthwhile my effort - some people seem to be picky if you touch their recipes (although some are a lot less considerate when it comes to recipes of others :-( ) Together for me that has lead to the conclusion that this is work with low satisfaction and high chance of getting negative feedback (e.g. because despite your efforts something breaks, or because by accident you step on someones toes), and that I'd better work on something else. Frans. PS: and wrt the remark "we have been discussed this before and the conclusion then was...": great, but if you do not document those decisions they will pop up every once in a while (e.g. by someone who is not aware of the decision; e.g. I for me, was unaware that angstrom initially had its own directory). ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: TSC Meeting 2010/03/02 2010-03-03 12:59 ` Frans Meulenbroeks @ 2010-03-03 13:26 ` Marcin Juszkiewicz 2010-03-03 13:47 ` Richard Purdie 1 sibling, 0 replies; 9+ messages in thread From: Marcin Juszkiewicz @ 2010-03-03 13:26 UTC (permalink / raw) To: openembedded-devel Dnia środa, 3 marca 2010 o 13:59:19 Frans Meulenbroeks napisał(a): > - the actual verification process is fairly cumbersome. (5) diff the 2 > packaged-staging recipes (which I read as packaged-staging packages as > there are no packaged-staging recipes) is imho a pita) I am comparing two IPK packages using midnight commander. Fast and easy. Regards, -- JID: hrw@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: TSC Meeting 2010/03/02 2010-03-03 12:59 ` Frans Meulenbroeks 2010-03-03 13:26 ` Marcin Juszkiewicz @ 2010-03-03 13:47 ` Richard Purdie 2010-03-03 14:04 ` Martin Jansa 2010-03-03 14:28 ` Frans Meulenbroeks 1 sibling, 2 replies; 9+ messages in thread From: Richard Purdie @ 2010-03-03 13:47 UTC (permalink / raw) To: openembedded-devel On Wed, 2010-03-03 at 13:59 +0100, Frans Meulenbroeks wrote: > 2010/3/3 Richard Purdie <rpurdie@rpsys.net>: > > Developer Effort > > ================ > > > > Rather than discussions such as the above, how about injecting that > > energy into adopting the new staging, BBCLASSEXTEND and -nativesdk code? > > Ehm. there was already a similar remark in the recent pango thread > (angstrom: sync pango and pango-native versions) > > I'd say the tone in that email and in the two lines above does not > really meet the 'be considerate" and 'be respectful' as described in > the ubuntu code of conduct. The wording could perhaps be better but I don't think its bad enough that it falls foul of the CoC. The TSC fully appreciates the work people put into OE and is just frustrated so much energy gets lost on what amount to relatively minor issues where there are many other things that need work. Put things into context - is whether a variable name has the word angstrom in the name really a massive insurmountable problem stopping people from using OE? > Also note that most of the work is done by > volunteers/hobbyists/whatever you want to name them. > I feel it is not really for the TSC (or for me) to say what others > should do. Suggestions could be made but I think it could be worded > more polite. The above is simply a suggestion. The TSC in no way controls what volunteers/hobbyists/employees/companies or anyone else working on OE actually works on. We can make a suggestion of where we feel effort would be well spent which is what the above states. No matter how many policies, groups or anything else we put into place this is an open source project which by the nature anyone is free to do pretty much anything. This can and does lead to friction at times and people do have strong opinions which there are no plans to censor. What we do need to stop is the personal attack side of things. "Attacking" someone's proposal on technical grounds is perfectly fair game IMO as long as it has a constructive and/or reasoned basis. The one thing it should never be is personal. > And wrt the new staging/BBCLASSEXTEND/nativesdk topic: > In my opinion it is useful to clean up the existing recipes (or move > them to 'obsolete' or whatever). > That way less recipes need to be adopted, and no energy is wasted on > adopting legacy recipes. > (apart from the fact that having lots of recipes for lots of variants > does not really give a professional and mature impression). Legacy recipes are a source of contention. We're bad at tracking who needs them and why. There some some factions of OE who'd like to never see any recipe deleted and there are some who feel any old recipe should be removed. We do have a problem in that the people who use old recipes use them as they don't like change and the staging changes are change and hence we either don't convert them (and hence never complete the transition we *need* to make) or we convert them and cause those people pain anyway. I could see a case for having a mass clear out of old recipes in OE to get the new staging changes in. Anyone wanting old versions could either add them back specifically (converted), make sure they were converted by a deadline or use an older tree. Someone would have to take an effort like that on, announce it and lead it but I suspect it could actually be made to work. It will need some time commitment though, any volunteers? :) > BTW: The recipes I feel responsible for are all converted to both new > staging and BBCLASSEXTEND. Great, thanks for doing that! > I have considered converting some of the others to new staging. > Actually I even started it, but soon stopped with it for the following > reasons: > - the actual verification process is fairly cumbersome. (5) diff the 2 > packaged-staging recipes (which I read as packaged-staging packages as > there are no packaged-staging recipes) is imho a pita) It would be better to have some kind of automated way of doing this I agree. Its technically possible, just nobody has found the time needed to implement it. We're all volunteers as you point out. > - i have no idea what recipes are actually used and worthwhile my effort Ultimately its desirable to convert everything. > - some people seem to be picky if you touch their recipes (although > some are a lot less considerate when it comes to recipes of others :-( > ) There are ways of handling this (RFC the patches, delay the commit for a few days. If no answer, then make the changes). > Together for me that has lead to the conclusion that this is work with > low satisfaction and high chance of getting negative feedback (e.g. > because despite your efforts something breaks, or because by accident > you step on someones toes), and that I'd better work on something > else. Well, we all feel like this at times. If I took all the negative stuff I see about my work to heart, I'd not be doing it. Hopefully people do feel some of the things I've done are some kind of benefit to OE. I have broken things before, I probably will again despite my best efforts but its how you deal with these things the people ultimately judge you on. I have yet to see a "thank you for helping set up the TSC, getting involved in the nastiest arguments OE has and putting your neck on the line all the time email" and don't expect one either. I doubt the e.V. board has either but for the record I do appreciate what they do and am trying to do my bit through the TSC. > PS: and wrt the remark "we have been discussed this before and the > conclusion then was...": great, but if you do not document those > decisions they will pop up every once in a while (e.g. by someone who > is not aware of the decision; e.g. I for me, was unaware that angstrom > initially had its own directory). Document where? How? Do you document the outcome of every email discussion you have on the OE list? It was a "decision" that came about as the result of an email discussion on this mailing list, nothing more, nothing less. Volunteers doing this would be very welcome... Cheers, Richard ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: TSC Meeting 2010/03/02 2010-03-03 13:47 ` Richard Purdie @ 2010-03-03 14:04 ` Martin Jansa 2010-03-03 14:28 ` Frans Meulenbroeks 1 sibling, 0 replies; 9+ messages in thread From: Martin Jansa @ 2010-03-03 14:04 UTC (permalink / raw) To: openembedded-devel On Wed, Mar 03, 2010 at 01:47:42PM +0000, Richard Purdie wrote: > > I have considered converting some of the others to new staging. > > Actually I even started it, but soon stopped with it for the following > > reasons: > > - the actual verification process is fairly cumbersome. (5) diff the 2 > > packaged-staging recipes (which I read as packaged-staging packages as > > there are no packaged-staging recipes) is imho a pita) > > It would be better to have some kind of automated way of doing this I > agree. Its technically possible, just nobody has found the time needed > to implement it. We're all volunteers as you point out. Today while checking diff of pango and libxml I noticed that bumping PR/INC_PR to target value before building it the old way helps a lot. Even the binaries were a bit different when they were built from different workdir because of PR (probably because of unstripped data in workdir/image). So now I first bump PR/INC_PR to target combination, then build without BBCLASSEXTEND without rm_work inherit or -c build, backup workdir, make BBCLASSEXTEND change, -c clean, -c build, and diff -rq workdir with backuped version. If it's different only in temp/run* temp/log* then it's great :). But usually static libs are still a bit different but probably in harmless way. Regards, -- uin:136542059 jid:Martin.Jansa@gmail.com Jansa Martin sip:jamasip@voip.wengo.fr JaMa ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: TSC Meeting 2010/03/02 2010-03-03 13:47 ` Richard Purdie 2010-03-03 14:04 ` Martin Jansa @ 2010-03-03 14:28 ` Frans Meulenbroeks 2010-03-03 15:19 ` Richard Purdie 1 sibling, 1 reply; 9+ messages in thread From: Frans Meulenbroeks @ 2010-03-03 14:28 UTC (permalink / raw) To: openembedded-devel 2010/3/3 Richard Purdie <rpurdie@rpsys.net>: > On Wed, 2010-03-03 at 13:59 +0100, Frans Meulenbroeks wrote: >> 2010/3/3 Richard Purdie <rpurdie@rpsys.net>: >> > Developer Effort >> > ================ >> > >> > Rather than discussions such as the above, how about injecting that >> > energy into adopting the new staging, BBCLASSEXTEND and -nativesdk code? >> >> Ehm. there was already a similar remark in the recent pango thread >> (angstrom: sync pango and pango-native versions) >> >> I'd say the tone in that email and in the two lines above does not >> really meet the 'be considerate" and 'be respectful' as described in >> the ubuntu code of conduct. > > The wording could perhaps be better but I don't think its bad enough > that it falls foul of the CoC. For the wording above I agree. The message in the pango thread, I felt as a snide remark directed directly to me (as I initiated the discussions). > > The TSC fully appreciates the work people put into OE and is just > frustrated so much energy gets lost on what amount to relatively minor > issues where there are many other things that need work. > > Put things into context - is whether a variable name has the word > angstrom in the name really a massive insurmountable problem stopping > people from using OE? I have not too much problems with the variable name as is. My intention was sincere and I felt that I was just following the procedure. Then someone started to claim that as author of the recipe he was not consulted and claimed he had the final say in it. Fine with me, but then please make clear what recipes you "own" and move them out of the common area. > >> Also note that most of the work is done by >> volunteers/hobbyists/whatever you want to name them. >> I feel it is not really for the TSC (or for me) to say what others >> should do. Suggestions could be made but I think it could be worded >> more polite. > > The above is simply a suggestion. The TSC in no way controls what > volunteers/hobbyists/employees/companies or anyone else working on OE > actually works on. We can make a suggestion of where we feel effort > would be well spent which is what the above states. > > No matter how many policies, groups or anything else we put into place > this is an open source project which by the nature anyone is free to do > pretty much anything. This can and does lead to friction at times and > people do have strong opinions which there are no plans to censor. What > we do need to stop is the personal attack side of things. "Attacking" > someone's proposal on technical grounds is perfectly fair game IMO as > long as it has a constructive and/or reasoned basis. The one thing it > should never be is personal. I fully agree. However this is a community project so I find statements like "If you're touching a recipe at least make sure the creator/maintainer agrees with your changes" like happened in a recent commit somewhat against the open source policy. And *if* we feel that creators/maintainers have a final say here, then I'd suggest to list the name in the recipe. Git log is only partially accurate due to the move from mtn to git and the rename from packages to recipes. > >> And wrt the new staging/BBCLASSEXTEND/nativesdk topic: >> In my opinion it is useful to clean up the existing recipes (or move >> them to 'obsolete' or whatever). >> That way less recipes need to be adopted, and no energy is wasted on >> adopting legacy recipes. >> (apart from the fact that having lots of recipes for lots of variants >> does not really give a professional and mature impression). > > Legacy recipes are a source of contention. We're bad at tracking who > needs them and why. There some some factions of OE who'd like to never > see any recipe deleted and there are some who feel any old recipe should > be removed. > > We do have a problem in that the people who use old recipes use them as > they don't like change and the staging changes are change and hence we > either don't convert them (and hence never complete the transition we > *need* to make) or we convert them and cause those people pain anyway. > > I could see a case for having a mass clear out of old recipes in OE to > get the new staging changes in. Anyone wanting old versions could either > add them back specifically (converted), make sure they were converted by > a deadline or use an older tree. Someone would have to take an effort > like that on, announce it and lead it but I suspect it could actually be > made to work. It will need some time commitment though, any > volunteers? :) I'm more than happy on converting some stuff. And wrt the old recipes. Note that in the glib case I investigated which ones were actually needed and proposed only to remove the ones which were not used by any recipe or distro. (and ofc someone can have a local overlay, then he/she takes a risk and probably should keep a local copy and/or stick to a specific snapshot). I am also all in favour of the suggestion from Otavio. The dev head should use the latest version where possible. If you need stability use the stable branch. > >> BTW: The recipes I feel responsible for are all converted to both new >> staging and BBCLASSEXTEND. > > Great, thanks for doing that! > >> I have considered converting some of the others to new staging. >> Actually I even started it, but soon stopped with it for the following >> reasons: >> - the actual verification process is fairly cumbersome. (5) diff the 2 >> packaged-staging recipes (which I read as packaged-staging packages as >> there are no packaged-staging recipes) is imho a pita) > > It would be better to have some kind of automated way of doing this I > agree. Its technically possible, just nobody has found the time needed > to implement it. We're all volunteers as you point out. > >> - i have no idea what recipes are actually used and worthwhile my effort > > Ultimately its desirable to convert everything. I beg to disagree. Converting legacy recipes seems pointless, and converting recipes that are not touched for ages and that do not appear in any image also might be less useful. But that is my opinion. > >> - some people seem to be picky if you touch their recipes (although >> some are a lot less considerate when it comes to recipes of others :-( >> ) > > There are ways of handling this (RFC the patches, delay the commit for a > few days. If no answer, then make the changes). Agree (but on the other hand that makes it even more work). I feel we should also have some mutual respect, and assume people do things in good faith. > >> Together for me that has lead to the conclusion that this is work with >> low satisfaction and high chance of getting negative feedback (e.g. >> because despite your efforts something breaks, or because by accident >> you step on someones toes), and that I'd better work on something >> else. > > Well, we all feel like this at times. If I took all the negative stuff I > see about my work to heart, I'd not be doing it. Hopefully people do > feel some of the things I've done are some kind of benefit to OE. I have > broken things before, I probably will again despite my best efforts but > its how you deal with these things the people ultimately judge you on. > > I have yet to see a "thank you for helping set up the TSC, getting > involved in the nastiest arguments OE has and putting your neck on the > line all the time email" and don't expect one either. I doubt the e.V. > board has either but for the record I do appreciate what they do and am > trying to do my bit through the TSC. Well then let me say a big thank you on what you did for OE. It is indeed rarely said, but it is definitely appreciated! > >> PS: and wrt the remark "we have been discussed this before and the >> conclusion then was...": great, but if you do not document those >> decisions they will pop up every once in a while (e.g. by someone who >> is not aware of the decision; e.g. I for me, was unaware that angstrom >> initially had its own directory). > > Document where? How? Do you document the outcome of every email > discussion you have on the OE list? It was a "decision" that came about > as the result of an email discussion on this mailing list, nothing more, > nothing less. Volunteers doing this would be very welcome... I guess some of the things (like our way of working) could be documented in the wiki. And before you ask: sorry, no volunteer here. There are just too many conflicting opinions outside & I feel I've opened enough cans of worms recently. > > Cheers, > > Richard Best regards, Frans ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: TSC Meeting 2010/03/02 2010-03-03 14:28 ` Frans Meulenbroeks @ 2010-03-03 15:19 ` Richard Purdie 2010-03-05 17:47 ` Rolf Leggewie 0 siblings, 1 reply; 9+ messages in thread From: Richard Purdie @ 2010-03-03 15:19 UTC (permalink / raw) To: openembedded-devel On Wed, 2010-03-03 at 15:28 +0100, Frans Meulenbroeks wrote: > For the wording above I agree. > The message in the pango thread, I felt as a snide remark directed > directly to me (as I initiated the discussions). I haven't looked at that thread so I'm not going to comment on that. > I have not too much problems with the variable name as is. > My intention was sincere and I felt that I was just following the procedure. > Then someone started to claim that as author of the recipe he was not > consulted and claimed he had the final say in it. > Fine with me, but then please make clear what recipes you "own" and > move them out of the common area. Following the procedure includes listening to feedback and acting on it. In the case I suspect we're talking about the commit was premature and a consensus was not reached. If it had been the problems introduced by the commit would not have happened. The revert then had its own issues. But I'd suggest we call that one dealt with as I don't see what going over it again will achieve. "ownership" in OE is nowhere near as simple as you make out. There is a file which lists areas which people take some responsibility for. > I fully agree. > However this is a community project so I find statements like > "If you're touching a recipe at least make sure the creator/maintainer > agrees with your changes" > like happened in a recent commit somewhat against the open source policy. No, its not. People have areas of expertise and areas they look after/maintain. We all need to be considerate to that in our commits. This is true of many open source projects. > And *if* we feel that creators/maintainers have a final say here, then > I'd suggest to list the name in the recipe. We've done that before and it was a disaster after a while. The maintainers file came into being instead. > Git log is only partially accurate due to the move from mtn to git and > the rename from packages to recipes. By combining common sense, the output from git log (which can probably be told to track renames) and the maintainers file, there is already plenty of information out there. > I am also all in favour of the suggestion from Otavio. The dev head > should use the latest version where possible. If you need stability > use the stable branch. That is a decision for the distro ultimately but yes, I'd generally agree. > > Ultimately its desirable to convert everything. > > I beg to disagree. Converting legacy recipes seems pointless, and > converting recipes that are not touched for ages and that do not > appear in any image also might be less useful. But that is my opinion. Either convert or remove. My point is the end result of no legacy staging. > > There are ways of handling this (RFC the patches, delay the commit for a > > few days. If no answer, then make the changes). > > Agree (but on the other hand that makes it even more work). > I feel we should also have some mutual respect, and assume people do > things in good faith. The whole commit policy relies on mutual respect and in general works well. It just breaks down on some corner cases :(. > > Document where? How? Do you document the outcome of every email > > discussion you have on the OE list? It was a "decision" that came about > > as the result of an email discussion on this mailing list, nothing more, > > nothing less. Volunteers doing this would be very welcome... > > I guess some of the things (like our way of working) could be > documented in the wiki. > And before you ask: sorry, no volunteer here. There are just too many > conflicting opinions outside & I feel I've opened enough cans of worms > recently. There lies the problem. People have limited time and/or a limited amount of patience in dealing with disagreements. The end result is compromise, we do the best we can... Cheers, Richard ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: TSC Meeting 2010/03/02 2010-03-03 15:19 ` Richard Purdie @ 2010-03-05 17:47 ` Rolf Leggewie 2010-03-06 12:25 ` Frans Meulenbroeks 0 siblings, 1 reply; 9+ messages in thread From: Rolf Leggewie @ 2010-03-05 17:47 UTC (permalink / raw) To: openembedded-devel Richard, let me first express my gratitude for your efforts. Richard Purdie wrote: > Following the procedure includes listening to feedback and acting on it. > In the case I suspect we're talking about the commit was premature and a > consensus was not reached. Sorry, disagree here. Unless you define consensus as a unanimous decision. This POV is out there with some people, sometimes in the form of "I feel free to veto and block just about anything, but I will gladly override negative feedback for my own commits". I don't share the "You have to have a unanimous decision" POV especially if the veto is IMHO obviously out there for the sole reason to stall changes indefinitely (and keep the breakage for others, which it seems some people would like to spin as Angstrom-hunting, which is of course, bull). Let's also not forget, this was a non-core change and did not even need an RFC. I strongly object to the notion that the feedback given until the commit in question wasn't taken into account. I feel it's quite a stunt to even suggest otherwise, especially since there's ample and public evidence to the contrary. I'm not saying that suggestions made *after* the commit couldn't and shouldn't have improved on the solution (instead of reverting). I do agree with Frans that there are still very many fuzzy areas as to what is permittable in OE and what not. I also agree with Frans that it's becoming increasingly difficult to "move OE forward", whatever that means for the individual. And yes, I see the conflict between fixing those two things. Both effects greatly decrease the fun to hack on OE, though, and has given OE a very slerotic feeling on my end lately. I fully understand Frans' feeling of "whatever you do in OE, you'll likely get burned". Frans, I hope I did not paraphrase your sentiments incorrectly. Feel free to correct me if I did. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: TSC Meeting 2010/03/02 2010-03-05 17:47 ` Rolf Leggewie @ 2010-03-06 12:25 ` Frans Meulenbroeks 0 siblings, 0 replies; 9+ messages in thread From: Frans Meulenbroeks @ 2010-03-06 12:25 UTC (permalink / raw) To: openembedded-devel 2010/3/5 Rolf Leggewie <no2spam@nospam.arcornews.de>: [...] > > Frans, I hope I did not paraphrase your sentiments incorrectly. Feel > free to correct me if I did. You didn't :-) I've indeed come to the conclusion that apparently OE has come to a point where it is very hard to move forward. One of the reasons is the perception of quality for some people. Quality to me does not mean having 26 glib recipes around or 8 abiword ones or whatever most of which are likely to be unused and even more likely to be unmaintained. We currently have close to 9000 recipes, 3000+of which are older versions. I understand why people feel they should keep old versions, but that is where a version control system is for. Development head should reflect the latest state-of-the-art, and probably should have only one version per recipe. (probably with the exception of things like gcc, linux and u-boot). If things do not work with a version, they should be fixed. Keeping the old version around and pin it, means that in the end you end up with a system which is lagging behind. If you want stability use a stable branch. head should focus on moving forward. Some people seem to think differently about it. As an alternative an obsolete directory has been proposed. The latter does not really help. It gives the crud a home, but it does not really solve the problem. However as discussions on what to remove are time consuming and progress is hard, I have abandoned that path. Instead I decided to create a branch called sanity (for now local, but once it is more reliable I'll probably push it) In this branch I intend to - remove all old versions of recipes (sometimes tough as there are recipes that have both numbered and cvs/svn/git variants (I believe there is a case where there is even cvs and svn for package)) exceptions: gcc (but some versions will go there), linux, u-boot) - crude convert to BBCLASSEXTEND="native". I feel this should in general work. (btw and I noticed we have packaged that do have native variants for older versions but not for the recent one, and I have even seen a case where the native recipe is newer than the target one). Plan was also to remove all do_deploy stuff, but apart from u-boot/linux this is nearly done. Note that the above edits may sound harsh, but frankly I doubt that anyone will ever convert those 3000 legacy devices, and even if they are converted, I strongly doubt that they are tested. This seems to be a better way forward. After that I have some ideas for further improvements, but let's get this started first. If anyone wants to work with me on this, feel free to get in touch with me. And for those who feel that effort should be directed elsewhere. Make me an interesting offer and we can talk. But until that it are my weekends and evenings I am spending on this, and I'll spend them as I see fit, not as someone else sees fit (ok, with the exception of the Mrs :-) ) Have fun! Frans ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2010-03-06 12:28 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-03-03 11:35 TSC Meeting 2010/03/02 Richard Purdie 2010-03-03 12:59 ` Frans Meulenbroeks 2010-03-03 13:26 ` Marcin Juszkiewicz 2010-03-03 13:47 ` Richard Purdie 2010-03-03 14:04 ` Martin Jansa 2010-03-03 14:28 ` Frans Meulenbroeks 2010-03-03 15:19 ` Richard Purdie 2010-03-05 17:47 ` Rolf Leggewie 2010-03-06 12:25 ` Frans Meulenbroeks
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.