Re: releasing 1.9 soon...

[David Nečas (Yeti) <yeti physics muni cz>]

On Sun, Sep 23, 2007 at 02:41:00PM +0300, Stefan Kost wrote:
> 
> Well then our understanding differs here. If a bug is closed as a reporter I
> would like to know which release will have the fix. In the case of libraries I
> could e.g. add a configure check for that version and disable a workaround if
> the user has a recent enough version.

This is not about understanding, this is about misuse.
However worthy your goal might be, misuse of bugzilla fields
should not be the solution.

> > The list is incomplete anyway.  What about 322035, 383456,
> > 445596, 450338, 465365, 466559?
> > 
> > If you want to know bugs fixed since the last gtk-doc
> > release, just ask bugzilla for it.
> >
> Exactly, therefore I use the field.

And my list is an illustration it does not work[*].  These
bugs were fixed by 1.9 byt they are not marked with 1.9
target milestone -- yet I easily found them by asking
bugzilla.

Exporting both bug lists to CSV and running diff on them
would reveal the complete set of fixed bugs that cannot be
found by looking for target milestone 1.9.

[*] Of course, you can run the proper query and then use the
mass bug changer to add a milestone to each in the list --
but what's the point when you can use the query?

> How will the user then know that it actaully happend. Once we release 1.10 one
> has to make a query to bugzilla to get all open bug with that target milestone
> and either postpone the release or move that target-milestone to 1.11.

At the moment we release 1.10 there should be no open bugs
with target milestone 1.10.

I'm not sure who `one' is in your description -- target
milestone is a developers' tool to keep track of issues that
should/must be resolved in a particular version or time
frame.

*Before* we (developers) release 1.10 we should deal with
all issues with target milestone 1.10: either resolve them
or decide to postpone them and change the target milestone.

> > Considering interesting error messages vary wildly (from perl
> > complaints such as `Use of uninitialized value...' to various
> > WARNINGs to xsltproc messages), how we find them in the
> > flood?
> >
> I am open to ideas here. Its more a sanity check that ensure that now build
> aborts etc.

If I knew how to find the start and end of documentation
build in the logs reliably, I'd just filter out everything
known to be harmless (Writing foo for refentry(bar)..., ID
recommended on..., gtk-doc: Running baz..., make:
Leaving/Entering directory ..., \-continued blocks that
looks like our commands, ...) and look at what remained.

Perhaps we can assume there is no interesting message before
`gtk-doc: Scanning header files' and that `touch
html-build.stamp' is the last thing printed, but it's not
exactly reliable.

Well, I don't even know how to get the actual logs from
build.gnome.org.  Moreover it seems most interestring builds
started failing on 16 September due to some infrastructure
change.

Yeti

--
http://gwyddion.net/