Re: GOP-PROP 8: issue priorities (radical update)
On Tue, Aug 09, 2011 at 09:27:07AM +0100, Trevor Daniels wrote: Jan Warchoł wrote Tuesday, August 09, 2011 12:27 AM Because having some issue officially block stable release is the only way of seriously pushing developers to fix it? Wouldn't work. Few, if any, developers use lily-git.tcl so are unlikely to be in a position to fix it. Using lily-git.tcl and being able to fix it are completely different things. IIRC the only people who have worked on lily-git.tcl are the original author of it, Carl, and me -- none of these people actually use lily-git.tcl. Besides, lily-git.tcl is only a small fraction of the things which may stop a contributor from helping out. If savannah is down, then nobody can push (or pull) anything. Developers seem to become more productive when releases are make frequently. If releases stop, for whatever reason, development slows down. So if this is intended as a means of coercion I think it is misguided. I disagree; developers are more productive when there's more *unstable* releases; stable releases don't really affect things (other than the prospect of a stable release increasing work). No, there's no doubt in my mind that including stops development as a Critical issue would help get them solved sooner. The only question in my mind is whether this is an acceptable departure from the describe bugs in neutral terms... each contributor can interpret the results as he or she sees fit idea. I honestly think that we *should* depart from that overall idea in this case, but I'm troubled by my inability to give a convincing reason (even to myself) as to why. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (radical update)
Graham Percival wrote Wednesday, August 10, 2011 9:09 AM On Tue, Aug 09, 2011 at 09:27:07AM +0100, Trevor Daniels wrote: Wouldn't work. Few, if any, developers use lily-git.tcl so are unlikely to be in a position to fix it. Using lily-git.tcl and being able to fix it are completely different things. IIRC the only people who have worked on lily-git.tcl are the original author of it, Carl, and me -- none of these people actually use lily-git.tcl. I don't believe either you or Carl needs any coercion to fix lily-git.tc. Besides, lily-git.tcl is only a small fraction of the things which may stop a contributor from helping out. If savannah is down, then nobody can push (or pull) anything. Neither can a release be made anyway. So these reasons are no justification for this policy. You still haven't convinced me it will actually have any effect. Don't get me wrong. Whether we place these issues in a critical category or not is hardly a vital decision, but here we're talking about deciding Policy. Policy decisions must be based on sound and justifiable arguments, not opinion or expediency. So my concern is that we are not following a sufficiently sound approach here. Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3824 - Release Date: 08/09/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (radical update)
On Wed, Aug 10, 2011 at 10:32:01AM +0100, Trevor Daniels wrote: Graham Percival wrote Wednesday, August 10, 2011 9:09 AM Using lily-git.tcl and being able to fix it are completely different things. IIRC the only people who have worked on lily-git.tcl are the original author of it, Carl, and me -- none of these people actually use lily-git.tcl. I don't believe either you or Carl needs any coercion to fix lily-git.tc. Think of a release as more of a stamp of approval and less of coercion. Besides, lily-git.tcl is only a small fraction of the things which may stop a contributor from helping out. If savannah is down, then nobody can push (or pull) anything. Neither can a release be made anyway. Technically I could still make a release using a local git repo. Don't get me wrong. Whether we place these issues in a critical category or not is hardly a vital decision, but here we're talking about deciding Policy. Policy decisions must be based on sound and justifiable arguments, not opinion or expediency. So my concern is that we are not following a sufficiently sound approach here. Completely agreed! I've taken a stab at this with the stamp of approval concept of a release -- please take a look at the updated GOP-PROP 8...(probable decision) and let me know what you think. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (radical update)
Graham, you wrote Wednesday, August 10, 2011 5:48 PM On Wed, Aug 10, 2011 at 10:32:01AM +0100, Trevor Daniels wrote: Don't get me wrong. Whether we place these issues in a critical category or not is hardly a vital decision, but here we're talking about deciding Policy. Policy decisions must be based on sound and justifiable arguments, not opinion or expediency. So my concern is that we are not following a sufficiently sound approach here. Completely agreed! I've taken a stab at this with the stamp of approval concept of a release -- please take a look at the updated GOP-PROP 8...(probable decision) and let me know what you think. Well, OK, it's a better point, if a little contrived :) I can live with it, though. Let's move on. The key point is dropping the priority field and replacing it with the stars, and I like that. Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3825 - Release Date: 08/10/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (radical update)
On Wed, Aug 10, 2011 at 06:44:51PM +0100, Trevor Daniels wrote: Graham, you wrote Wednesday, August 10, 2011 5:48 PM Completely agreed! I've taken a stab at this with the stamp of approval concept of a release -- please take a look at the updated GOP-PROP 8...(probable decision) and let me know what you think. Well, OK, it's a better point, if a little contrived :) I can live with it, though. Let's move on. Well, it's not /entirely/ contrived. I mean, Janek wants us to use fontforge 20110222 or higher; I want to say no way until lilydev has that version of fontforged installed. And if we ever did push such a change without lilydev being updated, I certainly wouldn't want to make a new stable release before fixing that! We haven't had many build-dependency updates in the past few years, but before that we used to require really cutting-edge libraries. I'm not opposed to requiring new libraries, and I don't care if it's something that no linux distro includes -- as long as we have a customized, downloadable, lilydev iso image available. (I could argue that anything less would be a regression, i.e. I used to be able to contribute to development, but because of changes to git master I can no longer do so. However, I'd rather make this particular case of regression explicit.) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (radical update)
Jan Warchoł wrote Tuesday, August 09, 2011 12:27 AM 2011/8/8 Trevor Daniels t.dani...@treda.co.uk: Graham Percival wrote Monday, August 08, 2011 6:06 AM Type-critical: * anything which stops contributors from helping out (e.g. lily-git.tcl not working, source tree(s) not being available). To limit this scope of this point, we will assume that the contributor is using the latest lilydev and has read the relevant part(s) of the Contributor’s Guide. I agree this is important, but I don't see why it should prevent a new release per se. Because having some issue officially block stable release is the only way of seriously pushing developers to fix it? Wouldn't work. Few, if any, developers use lily-git.tcl so are unlikely to be in a position to fix it. Developers seem to become more productive when releases are make frequently. If releases stop, for whatever reason, development slows down. So if this is intended as a means of coercion I think it is misguided. Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3822 - Release Date: 08/08/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (radical update)
Graham Percival wrote Monday, August 08, 2011 6:06 AM ** Proposal summary Let’s get rid of priorities. We will simply describe bugs in neutral terms; each contributor can search and interpret the results as he or she sees fit. This is a better approach than haggling over priority. We will make a “Type-Critical”; a new stable release will only occur if there are 0 type-Critical issues. ** Proposal details We will delete “priority” altogether. The “type” system will be tweaked. Type-critical: [snipped] * anything which stops contributors from helping out (e.g. lily-git.tcl not working, source tree(s) not being available). To limit this scope of this point, we will assume that the contributor is using the latest lilydev and has read the relevant part(s) of the Contributor’s Guide. I agree this is important, but I don't see why it should prevent a new release per se. More new/changed types [snipped] * Type-ignorance: (fixme name?) it is not clear what the correct output should look like. We need scans, references, examples, etc. I don't think this is a stand-alone type. It's more a label which could be applied to several types. ** Shutting up users We can remind users that they can “star” an issue to indicate that they care about it. I could not possibly care less about what users think, but if any contributors want to look at that info and organize their work schedule according to that, they’re welcome to do so. Also, the stars might serve as a placebo for users. I like this suggestion. There are already 6 open issues with more than 7 stars, so it's already being used. In spite of that we'd need to explain more clearly how to star an issue so all users can play, with a disclaimer that some issues might not receive attention however many stars they get. It will give quite a different rating cf to the priority field. Of the 6 issues with more than 7 stars, 2 are low, 3 medium and 1 abandoned! Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1391 / Virus Database: 1520/3821 - Release Date: 08/08/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (radical update)
On Mon, Aug 08, 2011 at 10:50:02PM +0100, Trevor Daniels wrote: Graham Percival wrote Monday, August 08, 2011 6:06 AM * anything which stops contributors from helping out (e.g. lily-git.tcl not working, source tree(s) not being available). To limit this scope of this point, we will assume that the contributor is using the latest lilydev and has read the relevant part(s) of the Contributor’s Guide. I agree this is important, but I don't see why it should prevent a new release per se. Hmm. I must admit that this rather contrasts with the we should let each contributor make their own judgement sentiment. * Type-ignorance: (fixme name?) it is not clear what the correct output should look like. We need scans, references, examples, etc. I don't think this is a stand-alone type. It's more a label which could be applied to several types. Well... it depends on how much we trust users (and even developers!) to be able to search the tracker, and/or pay attention to the labels. I'd like to make it Really Bleeding Obvious (tm) to users that an issue is in limbo; no programming will or can take place until some non-technical work is done (i.e. finding the references). The most visible sign is to have a Type specifically for such issues, but as you point out, this isn't really a type kind of thing. I guess that at the moment, I still have a slight preference for this abuse of the type system... but I could be convinced otherwise. Especially if there's another way of making this clear? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 8: issue priorities (radical update)
2011/8/8 Trevor Daniels t.dani...@treda.co.uk: Graham Percival wrote Monday, August 08, 2011 6:06 AM Type-critical: * anything which stops contributors from helping out (e.g. lily-git.tcl not working, source tree(s) not being available). To limit this scope of this point, we will assume that the contributor is using the latest lilydev and has read the relevant part(s) of the Contributor’s Guide. I agree this is important, but I don't see why it should prevent a new release per se. Because having some issue officially block stable release is the only way of seriously pushing developers to fix it? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GOP-PROP 8: issue priorities (radical update)
Thanks for the discussion so far! Based on that, I have a radically different proposal. http://lilypond.org/~graham/gop/gop_8.html ** Proposal summary Let’s get rid of priorities. We will simply describe bugs in neutral terms; each contributor can search and interpret the results as he or she sees fit. We will make a “Type-Critical”; a new stable release will only occur if there are 0 type-Critical issues. ** Rationale There is wide disagreement on what “priorities” should mean, or how they should be interpreted. Do they represent which “milestone” we want a fix by? How bad are crashes? How important are matters which hinder future development? Assuming that “GOP-PROP 7: developers as resources” is resolved in favor of “treat developers as independent volunteers” (which seems extremely likely), the notion of an externally-imposed “priority” seems a stretch. ** Proposal details We will delete “priority” altogether. The “type” system will be tweaked. Type-critical: * a reproducible failure to build either make or make doc, from an empty build tree, in a first run, if configure does not report any errors. * any program behaviour which is unintentionally worse than the previous stable version or the current development version. Developers may always use the “this is intentional”, or even the “this is an unavoidable effect of an improvement in another area”, reason to move this to a different type. * anything which stops contributors from helping out (e.g. lily-git.tcl not working, source tree(s) not being available). To limit this scope of this point, we will assume that the contributor is using the latest lilydev and has read the relevant part(s) of the Contributor’s Guide. More new/changed types * Type-crash: any segfault, regardless of what the input file looks like or which options are given. Disclaimer: this might not be possible in some cases, for example certain guile programs (we certainly can’t predict if a piece of scheme will ever stop running, i.e. the halting problem), or if we rely on other programs (i.e. ghostscript). If there are any such cases that make segfault-prevention impossible, we will document those exceptions (and the issue will remain as a crash instead of documentation until the warning has been pushed). * Type-maintainability: anything which makes it difficult for serious contributors to help out (e.g. difficult to find the relevant source tree(s), confusing policies, problems with automatic indentation tools, etc). * Type-ugly: replaces Type-collision, and it will include things like bad slurs in addition to actual collision. * Type-ignorance: (fixme name?) it is not clear what the correct output should look like. We need scans, references, examples, etc. ** Shutting up users We can remind users that they can “star” an issue to indicate that they care about it. I could not possibly care less about what users think, but if any contributors want to look at that info and organize their work schedule according to that, they’re welcome to do so. Also, the stars might serve as a placebo for users. ** Implementation notes Yes, revising the current issue tracker will take a fair amount of effort, but I have a plan for this. Don’t waste time pointing this out. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
