* meeting 2008-03-19 - version numbers @ 2008-03-19 15:11 Andrew Cagney 2008-03-19 16:00 ` Phil Muldoon 2008-03-19 16:00 ` Andrew Cagney 0 siblings, 2 replies; 5+ messages in thread From: Andrew Cagney @ 2008-03-19 15:11 UTC (permalink / raw) To: frysk Here's a transcript from using the hpd today (please note kernel "issues" mean it may not work on your system): $ ./frysk/bindir/fhpd ./frysk/pkglibdir/funit-hello [0.0] Loaded executable file: /home/scratch/frysk/git/native/frysk-core/./frysk/pkglibdir/funit-hello (fhpd) run Attached to process 7518 starting/running with this command: ./frysk/pkglibdir/funit-hello Running process 7518 (fhpd) Task 7518 is terminating from signal SIGSEGV(11) list [0.0] 34 // exception to your version of the file, but you are not obligated to 35 // do so. If you do not wish to provide this exception without 36 // modification, you must delete this exception statement from your 37 // version and license this file solely under the GPL without 38 // exception. 39 40 #include <unistd.h> 41 42 void 43 print(char *what) { -> 44 while (*what != '\0') { 45 write(1, what, 1); 46 what++; 47 } 48 } 49 50 int 51 main(int argc, char** argv) { 52 // XXX: This forgets to check ARGC. 53 print(argv[1]); (fhpd) where #0 0x080483da in print(char * what) /home/scratch/frysk/git/frysk/frysk-core/frysk/pkglibdir/funit-hello.c#44 #1 0x08048435 in main(int argc,char ** argv) /home/scratch/frysk/git/frysk/frysk-core/frysk/pkglibdir/funit-hello.c#53 #2 0x00808390 in __libc_start_main () from /lib/libc-2.7.so #3 0x08048311 in _start () from /home/scratch/frysk/git/native/frysk-core/frysk/pkglibdir/funit-hello (fhpd) print what (char *) 0x0 " < Memory Error > " (fhpd) which is the most straight forward of debugging sessions; and a major milestone. In the meeting, this brought forward two proposals: a) move frysk forward to 0.8.x, from 0.0.x This is to signal that we consider all our tools are minimally at alpha (key functionality is present but more to come); and for many tools they are actually beta/release quality (e.g., fstack, fcore, fcatch). As fhpd and frysk mature we can move to 0.9 and 1.0. b) move to regular (monthly?) patch-level releases; e.g., 0.8.1, 0.8.2, ... Since we've now reached a good code baseline we're able to, over shorter periods, show significant fixes and improvements. Making slightly more formal regular releases would provide us with a way to highlight this; and highlight the work completed over each of those periods. "discuss" Andrew ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: meeting 2008-03-19 - version numbers 2008-03-19 15:11 meeting 2008-03-19 - version numbers Andrew Cagney @ 2008-03-19 16:00 ` Phil Muldoon 2008-03-26 11:53 ` Mark Wielaard 2008-04-01 21:13 ` Sami Wagiaalla 2008-03-19 16:00 ` Andrew Cagney 1 sibling, 2 replies; 5+ messages in thread From: Phil Muldoon @ 2008-03-19 16:00 UTC (permalink / raw) To: Andrew Cagney; +Cc: frysk Andrew Cagney wrote: > > a) move frysk forward to 0.8.x, from 0.0.x > > This is to signal that we consider all our tools are minimally at > alpha (key functionality is present but more to come); and for many > tools they are actually beta/release quality (e.g., fstack, fcore, > fcatch). As fhpd and frysk mature we can move to 0.9 and 1.0. > There was quite a bit of discussion about this in the meeting. My biggest issue was messaging to the user/community why we have decided to do this change. What is our reason for changing from 0.0.1* to 0.8. Is it a saner system? Are we signaling we are much more stable? In all aspects or just some? Anyway ... My questions, (mercifully rendered ;) down to several points: - I've no objection to this. It moves us to a saner versioning system. But: - Discussion: How/should we maintain all the tools at a similar level of quality, and progression. Is moving to 0.9 going to mean the that the UI is in step with fcore, fhpd, and all the others? - Discussion: What are the criteria for moving major version numbers: ie 0.9, 1.0 and so on? Stability only? Are we going to gate version number on features? What's the release number to feature road-map? (there was a long discussion about feature embargo here which is something to really avoid). - Discussion: What current tools now merit the alpha (feature complete, known bugs exist), beta (feature complete, no known bug exist) and released state? - Discussion: Wildcard. Because the tools are of varying maturity, which differs from the maturity of the ui, which differs from the maturity of the frysk-core, should a move to 3 (or 4 with -devel) rpms be considered. Right now I believe we have one srpm/spec file that produces 3 sub-packages. (I know a lot of these questions were asked and answered in the meeting, I'm just asking them here as question to answer for the the mailing list crowd) > > b) move to regular (monthly?) patch-level releases; e.g., 0.8.1, > 0.8.2, ... I've no objections to this. But: - What release schedule? Weekly? Monthly? - How will we be smoke testing the results to ensure sanity (ie the last patch pushed screwed some stuff up). Our test cases can catch a lot of this? What is the release checklist? - Because we are moving to a more formal release deadline, how do development practices change, if at all? - What is our release matrix. Fedora 8 now, and Rawhide. But will it then be F8, F9 and rawhide all in sync? Will the release be to rawhide first, then a monthly push from rawhide to Fedora *? - How can we detect regressions in stability and features Overall I'm really happy to see this. There's lots to think about. Regards Phil ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: meeting 2008-03-19 - version numbers 2008-03-19 16:00 ` Phil Muldoon @ 2008-03-26 11:53 ` Mark Wielaard 2008-04-01 21:13 ` Sami Wagiaalla 1 sibling, 0 replies; 5+ messages in thread From: Mark Wielaard @ 2008-03-26 11:53 UTC (permalink / raw) To: Phil Muldoon; +Cc: Andrew Cagney, frysk Hi Phil, On Wed, 2008-03-19 at 15:59 +0000, Phil Muldoon wrote: > Andrew Cagney wrote: > > > > a) move frysk forward to 0.8.x, from 0.0.x > > > > This is to signal that we consider all our tools are minimally at > > alpha (key functionality is present but more to come); and for many > > tools they are actually beta/release quality (e.g., fstack, fcore, > > fcatch). As fhpd and frysk mature we can move to 0.9 and 1.0. > > > There was quite a bit of discussion about this in the meeting. My > biggest issue was messaging to the user/community why we have decided to > do this change. What is our reason for changing from 0.0.1* to 0.8. Is > it a saner system? Are we signaling we are much more stable? In all > aspects or just some? Anyway ... > > My questions, (mercifully rendered ;) down to several points: > > - I've no objection to this. It moves us to a saner versioning system. But: No real objection here either. Any versioning/naming system is really fine with me. As long as we try to push out regular releases with updated news entries so people know what they can expect to have improved/changed. > - Discussion: How/should we maintain all the tools at a similar level of > quality, and progression. Is moving to 0.9 going to mean the that the > UI is in step with fcore, fhpd, and all the others? Clearly different tools are at different maturity levels, lets not worry too much about this till we are truly thinking of a 1.0 release. Lets just mention in the release notes what works/doesn't work for now. If you are worried about version number inflation or giving the wrong impression about stability to our users then lets do either release names or release versions based on the date/month. Or just start at 0.4.x or something low to better reflect where we think frysk stands maturity wise. > - Discussion: What are the criteria for moving major version numbers: ie > 0.9, 1.0 and so on? Stability only? Are we going to gate version number > on features? What's the release number to feature road-map? (there was a > long discussion about feature embargo here which is something to really > avoid). I think it is way too early for feature based releases. Lets just do regular time based releases for now. > - Discussion: What current tools now merit the alpha (feature complete, > known bugs exist), beta (feature complete, no known bug exist) and > released state? Probably the focus should be on ftrace, fstack, fcore, fcatch, then fhpd, then the rest of the f* utils and finally the gui. But lets not stretch ourselves too thin. > - Discussion: Wildcard. Because the tools are of varying maturity, which > differs from the maturity of the ui, which differs from the maturity of > the frysk-core, should a move to 3 (or 4 with -devel) rpms be > considered. Right now I believe we have one srpm/spec file that produces > 3 sub-packages. Splitting at least the core, utilities, maybe fhpd and the gui would be good to show our users they are on separate development tracks. Being able to build frysk without the gui parts at least would be good thing seeing how little development goes into the gui these days. It would help packagers because then they don't have to deal with java-gnome dependencies. > (I know a lot of these questions were asked and answered in the meeting, > I'm just asking them here as question to answer for the the mailing list > crowd) Thanks. The meetings are often a bit too long to keep focused. Having this archived on the list is a good thing imho. > > b) move to regular (monthly?) patch-level releases; e.g., 0.8.1, > > 0.8.2, ... > I've no objections to this. But: > > - What release schedule? Weekly? Monthly? Monthly/Bi-Monthly seems like the time needed to really work on new stuff. Anything shorter means there is only time for (emergency) bugfixes. > - How will we be smoke testing the results to ensure sanity (ie the last > patch pushed screwed some stuff up). Our test cases can catch a lot of > this? What is the release checklist? This is a good question. A good idea would be to make sure each manpage includes an example section for each utility and make sure the release master at least runs each example by hand to make sure there are no embarrassing bugs on first run for our users. > - Because we are moving to a more formal release deadline, how do > development practices change, if at all? I would suggest to just declare a commit stop for a couple of days around the release. Later on we can create proper release branches, but git makes it easy to do development without having to push to mainline all the time anyway. > - What is our release matrix. Fedora 8 now, and Rawhide. But will it > then be F8, F9 and rawhide all in sync? Will the release be to rawhide > first, then a monthly push from rawhide to Fedora *? I would suggest decoupling the distro packaging from the actual release process. Even though the same people might also do the packaging for fedora, debian, etc. It is probably a good idea to at least run the testsuite and smoke tests on the latest releases of the most popular distros (or just what any of the developers have available). If possible include test results in the release notes so packagers know what to expect (or tests sometimes rely heavily on the compiler/kernel, so it would be good to get packager feedback on the test results). > - How can we detect regressions in stability and features Well if the unit tests are pretty complete, and the smoke tests well defined... :) > Overall I'm really happy to see this. There's lots to think about. Cheers, Mark ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: meeting 2008-03-19 - version numbers 2008-03-19 16:00 ` Phil Muldoon 2008-03-26 11:53 ` Mark Wielaard @ 2008-04-01 21:13 ` Sami Wagiaalla 1 sibling, 0 replies; 5+ messages in thread From: Sami Wagiaalla @ 2008-04-01 21:13 UTC (permalink / raw) To: Phil Muldoon; +Cc: Andrew Cagney, frysk >> b) move to regular (monthly?) patch-level releases; e.g., 0.8.1, >> 0.8.2, ... > I've no objections to this. But: > > - What release schedule? Weekly? Monthly? I propose: - monthly releases with news items. - We create a NEWS file that we dump every release. > > - How will we be smoke testing the results to ensure sanity (ie the last > patch pushed screwed some stuff up). Our test cases can catch a lot of > this? What is the release checklist? > We make sure all the tests pass, and add tests are user report problems. We can also push a package to updates testing test it for a week then move it. Although I personally prefer the smoke test it and get it out there ASAP approach. > - Because we are moving to a more formal release deadline, how do > development practices change, if at all? > I dont know. Depends on what is motivating this change and what options we have to solve it. > - What is our release matrix. Fedora 8 now, and Rawhide. But will it > then be F8, F9 and rawhide all in sync? Will the release be to rawhide > first, then a monthly push from rawhide to Fedora *? > We are a young project so we want to stay agile as much as possible. So I suggest we release to rawhide and the latest fedora. > - How can we detect regressions in stability and features > Tests, and users(frysk team ? :)) ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: meeting 2008-03-19 - version numbers 2008-03-19 15:11 meeting 2008-03-19 - version numbers Andrew Cagney 2008-03-19 16:00 ` Phil Muldoon @ 2008-03-19 16:00 ` Andrew Cagney 1 sibling, 0 replies; 5+ messages in thread From: Andrew Cagney @ 2008-03-19 16:00 UTC (permalink / raw) To: frysk Tromey, on irc, was asking what in the below is new: Andrew Cagney wrote: > Here's a transcript from using the hpd today (please note kernel > "issues" mean it may not work on your system): > > $ ./frysk/bindir/fhpd ./frysk/pkglibdir/funit-hello > [0.0] Loaded executable file: > /home/scratch/frysk/git/native/frysk-core/./frysk/pkglibdir/funit-hello > (fhpd) run > Attached to process 7518 > starting/running with this command: ./frysk/pkglibdir/funit-hello > Running process 7518 > (fhpd) Task 7518 is terminating from signal SIGSEGV(11) It's here. Previously the behavior was: (fhpd) Task 9989 is terminating from signal SIGSEGV(11) focus Target set pid id path-to-executable (fhpd) notice how the thread isn't a member of the focus group as it wasn't being stopped during termination; it now is. Being able to wait until a process really is terminating makes things easier; you don't have to second guess which of many potential signals will be lethal. Instead just wait for the lethal signal to come along. > list > [0.0] > 34 // exception to your version of the file, but you are not > obligated to > 35 // do so. If you do not wish to provide this exception without > 36 // modification, you must delete this exception statement from > your > 37 // version and license this file solely under the GPL without > 38 // exception. > 39 40 #include <unistd.h> > 41 42 void > 43 print(char *what) { > -> 44 while (*what != '\0') { > 45 write(1, what, 1); > 46 what++; > 47 } > 48 } > 49 50 int > 51 main(int argc, char** argv) { > 52 // XXX: This forgets to check ARGC. > 53 print(argv[1]); > (fhpd) where > #0 0x080483da in print(char * what) > /home/scratch/frysk/git/frysk/frysk-core/frysk/pkglibdir/funit-hello.c#44 > #1 0x08048435 in main(int argc,char ** argv) > /home/scratch/frysk/git/frysk/frysk-core/frysk/pkglibdir/funit-hello.c#53 > #2 0x00808390 in __libc_start_main () from /lib/libc-2.7.so > #3 0x08048311 in _start () from > /home/scratch/frysk/git/native/frysk-core/frysk/pkglibdir/funit-hello > (fhpd) print what > (char *) 0x0 " < Memory Error > " > (fhpd) > > which is the most straight forward of debugging sessions; and a major > milestone. In the meeting, this brought forward two proposals: ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-04-01 21:13 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-03-19 15:11 meeting 2008-03-19 - version numbers Andrew Cagney 2008-03-19 16:00 ` Phil Muldoon 2008-03-26 11:53 ` Mark Wielaard 2008-04-01 21:13 ` Sami Wagiaalla 2008-03-19 16:00 ` Andrew Cagney
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).