On Wed, Dec 9, 2009 at 12:30 PM, Robert Godfrey <rob.j.godf...@gmail.com> wrote: > 2009/12/9 Rafael Schloming <rafa...@redhat.com> > >> Robbie Gemmell wrote: >> >>> Hi all, >>> >>> Now that we have entered another release phase I think it would be a good >>> time to discuss the release artifacts. I would like to see 0.6 ship with >>> some updates to the artifacts we produce to make things more useful and >>> obvious for our users. >>> >> >> I think it's a bit late for 0.6, if I understand the timeline correctly. >> >> >> The "Java broker, client, and tools" multi-component package appears to be >>> just a copy of the etc/ lib/ and bin/ directories from the qpid/java/build/ >>> dir after performing a build and this makes it quite messy. A lot of test >>> configuration files are left in the etc/ dir and there are loads of jars in >>> the lib/ dir, which make it very hard to know which is being used where or >>> allow splitting them up easily. You also end up with jars that just aren't >>> intended to be used from there (eg the eclipse-plugin used in the JMX >>> Management Console releases). We have single component packages for the Java >>> broker, client, and management tools so if we want a multi-component package >>> including any of these I think we should simply bundle those up instead of >>> just tarring the build folder and mashing everything together. >>> >> >> I sort of disagree with this. There is a "philosophy" behind using the >> "just a copy" approach. The benefit is that we can eliminate a whole class >> of bugs resulting from complex transformations necessary to turn the build >> artifacts into release artifacts. Not to mention it is easier for us to >> reproducer user issues if dev and user environments are as similar as >> possible. >> >> That said I'm fine cleaning up the release artifacts and what not, I'm just >> -1 on doing it by introducing complex transformations between build and >> release artifacts. If we want the release artifacts to look different we >> should make the build artifacts look different. >> >> As I've said before I'm happy to help with this, but we sort of need to >> figure out what we want things to look like first, and IMHO such an effort >> should also include making release artifacts more consistent across the >> whole project. >> >> > I think this is the key point - we need to work out how our build and > release artefacts look; since what we have today is clearly unsatisfactory. > > If there are quick, non-risky, changes that we could put in place for 0.6 > that are universally acknowledged as a step in the right direction, I > wouldn't necessarily be against them - however I don't think we want to > embark on anything that will negatively impact a 0.6 release date at this > stage. I am hugely +1 in doing this work before 0.7 (it's clearly a > necessity for us if we ever want to get to a 1.0 release)
Totally agree here. I think for the 0.7 release we definitely need to consider sorting out our documentation and release artifacts a top priority. I also agree that we need to have a consistent story across all our components than a per language approach. >> >> Another result of the above is that QMan is shipped in the Java >>> multi-component bundle despite the fact it is only useful if you have a C++ >>> broker. I realise it is written in Java, but those packages don't seem to me >>> like they should necessarily be language specific. If anything I would say >>> that QMan should surely ship in the multi-component bundle along with the >>> items it can actually be used with (ie the C++ broker and client bundle), or >>> just be made available standalone (which it already is). Users aren't >>> necessarily going to expect they need to download both multi-component >>> packages to make use of everything contained in one of them, and as >>> mentioned above, splitting QMan alone out of the java multi-component bundle >>> would be a bit hideous and non obvious anyway. >>> >>> I would also like to see us tagging the source-only release artifacts with >>> 'src', ie the C++ and the "full" release artifact that is just a copy of the >>> entire repo. It isn't exactly helpful for a user to download the 50MB file >>> then find out what they are looking for isn't actually in there. >>> >> >> I also think it's a shame that our artifacts look like they come from >> entirely different projects. Even little things like readme capitalization, >> general directory layout, etc is completely different from artifact to >> artifact, and this is even after the release script hacks to rearchive stuff >> to make things a bit more consistent. >> >> > Agree again completely. We have a lot of work to do - which we should do as > a matter of priority - in sorting out our artefacts to present a more > consistent appearance across the project. > > -- Rob > > >> --Rafael >> >> >> >> --------------------------------------------------------------------- >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:dev-subscr...@qpid.apache.org >> >> > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
