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