On 17/05/12 02:15, Carsten Haitzler (The Rasterman) wrote: > the point of releases and stability is that regardless if *YOU* care, you have > "users" (customers) who care and stability is about supporting them. making > bugfix releases with no nasty surprises they can DEPEND on. if you personally > care about the bug/widget or not is not really relevant. your USERS will care > - > some of them will, AND if you care about the project at all you care about > users and at least TRY to help them out and make them happy. there are of > course limits and there is the other side of being unreasonable, but doing a > backport of a fix is far from unreasonable.
It's painful and annoying. As I said, I do it. You I've done my share of backports in the past, it's not that I'm against them/strictly against them. I'm just saying it's maybe time to think about this process and fix it, because as I said *I* don't care (for my own sake, i.e scratching my own itches, like I said) about backports (and most users don't care much as well, but lets leave that aside) and it's a painful process for me to do. It just makes sense that people that care about the older version will maintain them. I.e just have an "old version" maintainer. > >> Though seriously, changelog: no way I'm adding a changelog entry for >> that, we are really getting nuts with the changelog, we have 10000 >> changes like this per release which just clutters the changelog. That's > > the changelog is a small fraction of the size of the svn log. the changelog is > for packagers and users to see what did change when they GET THE TARBALL. the > changelog is what i use to update NEWS files at release time. scm log is > everything. changelog is filtered down entries to the new additions, removals > and bug fixes done - any bug fix at all that may have affected someone and > their apps/code etc. (fixing a spelling mistakke in a comment, doc, readme > etc. > isn't going to affect people normally). I know what a changelog is for, but you have to put a line somewhere. I'm certain you'll agree that "Fixed elm_object_text_set to work when inserting the text 'aouaA<HA<*(KAo34'." hardly deserves a changelog entry, as no one complained about it. I'd argue that only major bugs or bug that were reported deserve changelog entries, but as I said, it's not really defined ATM. > >> what bug trackers and associating bugs with releases are for, not the >> changelog. If we plan on adding changelog entries for every small > > and then the bug tracker is "cluttered with 10000 changes". unlike the > changelog you have to wait 5 seconds for each bug report page to come up, as > opposed to a quick scan of a text file to see if your annoying bug has been > fixed this release or not. You can just show them all in a list and see all the titles, and it's grouped per release so no filtering is needed. > >> change, we might as well just paste the VCS log there on release (like >> some projects do). > > no - because scm logs contain all the junk in between. And changelog just contains a lot of other junk. > >> As for the backport. It's annoying to do with svn (and our directory >> structure), very annoying, also, it's driving me nuts. Again, comparing >> to other projects: that's why there are "version maintainers", just for >> backporting. When it comes to scratching my own itches: I couldn't care >> less about backports, I usually do it, but it's really just too annoying. > > <just before u svn commit the change> > svn diff | (cd ~/dev/svn/e/branches/elementary-1.0; patch -p0) > > that's annoying? you could script it trivially: > > cat backport.sh > #!/bin/sh > svn diff | (cd ~/dev/svn/e/branches/$1; patch -p0) > > so now it's a simple: > > backport.sh elementary-1.0 1. Yes, it's terribly annoying, and you have to maintain checkouts of all the branches. 2. It's not as simple as you'll may have conflicts. 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). > > reality is that often the changelogs (and patches) don't apply so there is a > manual fix anyway and no scm is going to magically fix that for you. this is > the cost of stability and doing releases. this is WHY on most large projects > there are DEDICATED people who just do the backporting (ie maintaining) of > stable releases. so please do this. it's the right and professional thing to > do. our tools are just fine That's the point of my mail! I wasn't trolling about git, we already said we'll move to git after e17 is out, I was just saying we need dedicated people to do the backporting, I'm glad we agree. > >> We just need to find something to do with backporting (which will be a >> lot easier but still annoying with git) and define guidelines for when > > no easier with git. see above. Is too, especially when you work with local commits, but also just because you don't need to maintain more than one checkout of the code. > >> to backport (and more importantly who), and when to add changelog >> entries. It's just too crazy to go on like that. People are motivated >> about improving EFL, not supporting the debian-afraid-of-updates gang. > > and then all your serious users run away because you can't be bothered > maintaining any stability that they RELY on in their > servers/products/devices/apps and they go and find somone else who bothers. 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. > if you just want to hack in a bubble then fine, but we are now in a position > of > needing to maintain stability. if you are uninterested in helping out and > instead now making others do your backport for you when it's easier to do > yourself at the time (much easier - see above), then perhaps this isn't the > project for you? You could say that in order to get people to comply with a lot of crazy things, this argument is just too generic to apply. I am helping out, but it's crazy that in many cases the overhead involved in fixing bugs is greater than actually fixing it. Lets take the fix I just did as an example. It's a 1 liner (actually ~10 chars) that took me 3 seconds to spot and 3 seconds to fix. On the other hand, writing the commit log + change log + backporting to elm1.0 (and that's even an easier example because we only have one backport to do) would have taking me a huge amount of time, and for what? For a bug only I noticed in a widget people seldom use? Yeah, if you happen to have this bug, it's nice to see it in the changelog, but you wouldn't be able to find it anyway because it's hidden between ~500 lines of changelog (evas1.0->1.1). Also, since our "widget toolkit" is actually split between many libraries, one can't really know if his bug has been fixed by looking at the changelog. My fix could have been in eina, edje, eio, evas, elementary... so really, why are we maintaining those damn changelogs like we do? 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. 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. -- 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
