[jvanek at redhat.com: visual vm 1.3.1]

Sun Jan 9 16:19:14 PST 2011

On 21:56 Sun 09 Jan     , Jiri Vanek wrote:
> On 01/07/2011 10:26 PM, Dr Andrew John Hughes wrote:
> > [Forwarding to distro-pkg-dev as public items such as releases should be discussed there]
> >
> > ----- Forwarded message from Jiri Vanek<jvanek at redhat.com>  -----
> >
> > Date: Thu, 06 Jan 2011 15:08:49 +0100
> > From: Jiri Vanek<jvanek at redhat.com>
> > Subject: visual vm 1.3.1
> > User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100907 Fedora/3.1.3-1.fc13 Thunderbird/3.1.3
> >
> > Hi!
> > I had prepared visualvm harness 1.1. and uploaded to download/sources
> > as 1.0 was used to be.
> > I have also updated our package to visualvm to 1.3.1, harness 1.1,
> > profiler 6.9-1.
> > It is awaiting in testrepo, and will be here, untill way "how with"
> > visualvm  will be set.
> >
> > Regards J.
> >
> > ----- End forwarded message -----
> >
> > I don't believe we have even properly discussed a 1.1 release of the
> > VisualVM harness yet, let alone made such a release.  Such releases
> > need to be discussed on the public list (distro-pkg-dev) so that everyone
> > has a chance to give their input.
> >
> > I have asked, both by e-mail and on IRC, for you to post any patches
> > you want for such a release but have only seen one so far
> > (http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-January/011643.html). The
> > discussion on https://bugzilla.redhat.com/show_bug.cgi?id=640205
> > suggests that more changes are needed before we make a new release and
> > a quick look at the spec file in Fedora confirmed this to me.
> >
> > I tried to make some of the necessary changes but found that my work
> > was being ignored by the Fedora build as it was downloading a 1.1
> > tarball.  This seems to have been published to the IcedTea server
> > without any discussion.  I'm afraid I've had to remove this in order
> > to proceed with work on VisualVM.  Apologies to anyone who may have
> > been depending on it, but it doesn't seem to have been announced
> > anywhere.
> >
> > We provide the VisualVM harness as an upstream project so that all
> > distributions can benefit.  Thus, where possible, we expect changes
> > to be pushed to the harness rather than being kept locally in the
> > distribution packages so that more people can benefit.  At present,
> > the Fedora spec file for VisualVM seems to have several modifications
> > (patches and the movement of installed files) which can be upstreamed
> > for the benefit of all, and I would like to see these in the repository
> > before any further releases are made.
> >
> > Additionally, when submitting patches for review, please attach them
> > to an e-mail describing fully the motivation for it with a ChangeLog
> > entry.  It is very hard to review a patch if we don't know why it is
> > being submitted in the first place or what it does.
> >
> > Thanks,
> > --
> > Andrew :)
> >
> > Free Java Software Engineer
> > Red Hat, Inc. (http://www.redhat.com)
> >
> > Support Free Java!
> > Contribute to GNU Classpath and IcedTea
> > http://www.gnu.org/software/classpath
> > http://icedtea.classpath.org
> > PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> > Fingerprint = F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
> 
> This is little bit unfair. When vm 1.3  was "released", we agreed that 
> You will do the changes in harness according to specfile, because you 
> wrote the harness. 

I agreed to help, yes.  You're new to the harness still, so I would have been
happy to show you where to make the needed changes to the build or even make such
changes.  But for your side, you've never even provided a list of the issues
you've encountered or how you fixed them (see
https://bugzilla.redhat.com/show_bug.cgi?id=640205#c30)

It simply doesn't scale for upstream to go looking into every distro's repository
for local patches and doing the work of incorporating those changes.  That's part
of your role as the package maintainer (or at least filing bugs).

> Also was sugested to dont release 1.3 until 1.3.1 
> will be build - probably with new harness. 1.3.1 Is available more then 
> 2months. 

I don't follow this.  I said that the Mercurial repository had support for VisualVM
1.3.1, provided by Tomas Hurka, and so it would make sense to have a new VisualVM
harness release (1.1) to get 1.3.1 into the Fedora packages.  Given we were moving
to a new release anyway, it makes sense to incorporate your changes (again see
comment #30 on the bug report).

> So why to wait when everything is prepared? I have asked you 
> several times if things are moving. They didn't:(. At least my rash 
> action moved them.
> 

Provoking people is not a way to get what you want.  It just inspires bad feeling
and doesn't help the community work together.

You may not believe it, but I do have other tasks to do other than
incorporating your changes, including security updates for IcedTea
(e.g. http://blog.fuseyism.com/index.php/2010/11/24/icedtea6-176-183-and-192-released/)
which take a higher priority.  Please have more patience.

> My apologise for uploading 1.1 to download/sources. I underestimate its 
> full purpose as distribution channel. I should at least name it pre or 
> work off-line at all.  

I don't see why there's any reason to put such a tarball on a public server
other than to try and subvert the release process.  I'd have a little more
sympathy if this seemed like a genuine mistake, but you were told, when you
asked to upload the file, to contact the mailing list and you ignored this.

There's obviously no problem with doing test builds against your own
locally created tarballs (as I did on Friday to do the required work).
You shouldn't publish these tarballs publicly or make released RPMs
out of them
e.g. https://admin.fedoraproject.org/updates/visualvm-1.3.1-1.fc14
(BTW, the versioning there should indicate the version of VisualVM
harness used; please incorporate this).

A release needs to first be discussed on the public mailing list
(distro-pkg-dev) to give everyone chance to contribute or at least
make them aware of it.  You then need to do basic administration work
like updating the version, tagging the tree and rolling a tarball
against that tag with the correct version.

The reason the tree carries a 'pre' suffix through most of its life is
explicitly to distinguish test/pre-release tarballs from the real
releases we make and you shouldn't just rename them to '1.1' or whatever.

The full release process is described on the wiki:

http://icedtea.classpath.org/wiki/ReleasingIcedTea

(this is for IcedTea but most of the same applies to VisualVM & IcedTea-Web).

That handles the technical side, but the most important side to a
release is handling it socially with the participation of the
community and not just making random releases as you feel like it.

> Also I'm sorry for not to notice distro-pkg. I 
> informed only java-team as I'm used to. 

Ok, now you know.  You've posted to the list before, so it's not completely alien.

> Although I consider most of 
> things as misscommuncation, I apologise..."road to hell is paved with 
> good intentions."
> 

The best way to apologise is by learning from such mistakes and doing the right
thing in future :-)

> Regards J.
> 
> 
> 
> 
> 
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint = F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8