public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
* 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-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

* 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

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).