Hot on the heels on yesterday's meeting, I had this little conversation with António in #foresight-devel today about how we triage bugs in FL-2.x now that we have decided to all but put it in maintenance mode.
Pragmatic and practical suggestions for how to deal with this in the most efficient manner possible are most welcome. /ermo ## Begin excerpt <ermo> http://issues.foresightlinux.org/secure/IssueNavigator.jspa?mode=hide&requestId=10147 <- the 1.9.9.x list has been slimmed down considerably. What do we do with the installer issues? <ermo> doniphon: ^^ <doniphon> ermo: good question. create a new target. 2.99.xx. and move all those to there for now. <ermo> why 2.99.xx? <ermo> as in: "What are you thinking, d00d?" <ermo> What does the 2.99.xx artifact stand for in your intricate mind? <doniphon> pre3 <ermo> And what is pre3 based on? <ermo> You see, I need to add a description to 2.99.xx so that people will know when to assign issues to it :) <ermo> (that's why it's important that I understand what you want with it) <doniphon> 2.99.xx is stuff that only makes sense to SOLVE in the scope of f3. <ermo> Then why do the 2.99.xx dance and not just 3.x (to denote "stuff that makes sense to solve in the scope of f3")? <ermo> I know gnome does the 2.9x.x dance <ermo> doniphon: For the record, you just said yesterday that we needed to have a proper policy. Well, consider this policy making and buckle up. <doniphon> ermo: because for pure 3.x I'm thinkering about a clean bug namespace... something like FLP or something. (Foresight Linux Platform) to denote the radical changes. but i need to think better about it. <ermo> And can we stop talking about this 'pure' nonsense? Yes, we need a staging area for bugs that cannot be solved in the context of 2.x. But we also need to define what we do with those bugs, how we sort them, how we resolve them. <ermo> It's one thing to archive old releases (which is what I'm working on). It's another thing to mine FITS for genuinely useful Feature Suggestions and real bugs that we need to solve. <ermo> The Feature Suggestions are (somewhat) easy -- they can be assigned to a 'pool of cool ideas' which we can draw on for f3. <ermo> The genunine bugs, however, need to be triaged properly. <doniphon> ermo: on those pack there are 2 classes of issues. one that a simple move to a refreshed upstream base (in the case upstream anaconda) will be enough to wipe them. and ones which are plain features that we may or not want to have in the future but that we know _now_ in (2.x_ scope) that aren't worth the effort. <ermo> punting on the genuine bugs in the current installer is a cop-out in my opinion -- we need to be realistic and say either 'yes, we will try to fix this' or 'we acknowledge the bug, but we won't fix it. Ever'. The alternative is 'we acknowledge the bug, we won't fix it now, but we will consider a solution for f3' <ermo> yeah, then we agree. <ermo> The point being, we need to make a decision so both we and the reporter can take it at face value. If we don't we'll just keep being bogged down. <doniphon> ALL anaconda bugs not strictly related to FL specific features (use of conary) are byDefault upstream bugs. (this doesn't mean ignoring them all - they may force a look on HOW we are refactoring anaconda on our side, *but* anyway current anaconda is frozen. no chance we 'll ever look or fix current issues. <ermo> now that's plain speak I can understand. <ermo> doniphon: Tell you what, I'll look at the Acx driver stuff and then you can do some more thinkering on the above and we can pick it up again this afternoon or over the weekend. No need to rush it as we still have, oh, a gazillion bugs to triage. ## End excerpt _______________________________________________ Foresight-devel mailing list Foresight-devel@lists.rpath.org http://lists.rpath.org/mailman/listinfo/foresight-devel
