On 17/05/12 11:26, Stefan Schmidt wrote: > Well, if you don't have a special case for 'aouaA<HA<*(KAo34' this bug > would also affect other text entries. Rare sure, but not as rare as you > might think. Adding a changelog with the fixed _root cause_ would still > make sense.
I'm talking about a specific case bug here, not "we didn't allocate enough space for strings longer than 5 characters"... > > About the only-a-bug-when-reported I can just say this will not work. I > agree that reported bugs have higher priority and should get an entry, > but just because it was not reported does not mean it nobody was > affected by it. Users are as lazy as developers in this regard. :) Yes, I was trying to be lazy, well either that, or trying to make people use trac more. :) > >> 1. Yes, it's terribly annoying, and you have to maintain checkouts of >> all the branches. > > I actually would expect this from developers. I would not. I expect developers to have the code they work on available and that's it. > >> 2. It's not as simple as you'll may have conflicts. > > Sure. And form time to time its even not sensible to do so because too > much internals changed. Naturally backports will slow down to the most > important ones while code in the dev branch moves on. More likely to > happen with elementary right now then say for embryo. So, we only backport "easy to merge" fixes? We don't fix issues that are found in newer versions that also apply to older versions? The backporting we do just feels so random. > >> 3. It's not as easy when you work with git-svn and have multiple commits >> in your queue (can be done, just not as trivial). > > I'm sorry, but that really reads like an excuse because do don't want to > use your tools in a better way. Making a new branch and bringing over > the commits you want to commit and then backport is not that hard with > git. You can then rebase, or merge. Local changes come with a cost. True, was an excuse. As I said, it can be done, just also annoying. > >> As I said, I know it's important, I'm just saying my "direct" motivation >> is to improve the EFL and not to support users. I do support users, I >> help on the ML/IRC and generally available. I care about EFL flourishing >> and that's why I even bother about arguing. I'm just saying it's getting >> a bit annoying. >> Heck, I've been bugging everyone for years to write proper commit logs, >> doc the code and write unit tests, which achieves stability and more. > > We all pester for efl and e17 releases for years and now that we have > some we need to take care about doing some maintenance as well. Price to > pay. Yes, there is a price, but the price shouldn't be retarded and undefined. :) >> We need to "optimise" the way we work, not only the code we write, and >> at the moment, we are very far from ideal in that field. > > I heartfully agree with you on this. Still just ripping out parts of the > workflow that are useful for others is no optimisation but a simple > feature removal to save time. :) That's part of it. That's why I said, we need version maintainers makes things easier. > >> Just think about the time wasted, people annoyed by it (me for one) and >> compare it to the outcome and the benefits we get from it and let us >> know if you still think we should go on the way we do. > > Interestingly it seems to be easy enough to do backports for raster and > cedric. For me it looks like your own setup makes it harder then needed. > (No complete checkout, local commits). There is nothing in git and > git-svn that would block you from having a good setup for this. > It also seems to be easy enough for me to write unit tests, proper commit logs and doxygen, and yet I'm one of the only ones who do it. I guess things are not like they seem, raster and cedric work hard to do it. And maybe, I have lower tolerance for repetitive work. And I'm sorry, but local commits are a huge bonus and a must have for me. Before I knew about git-svn I used to work with a local svn repo which was painful as well, but still better than not having local commits. Complete checkouts - I don't care about all the crap in trunk and furthermore, I use git's local branches to have a better workflow. Git and git-svn don't block me from doing it, I block me from doing it. You can't have a good setup with a complete checkout as it makes it hard to do bisects for specific libraries/changesets as you'd have to recompile everything all the time, you can't have the local branches I was talking about and generally it makes a lot of things more difficult and it's not how on should work. I know we have the tech limitation of using SVN, and I'm fine with that, as a move to git is planned and everyone will be happy soon enough, but what I'm talking about is beyond git-vs-svn it's about our work methodology. -- Tom. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
