On 20/11/2007, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > sebb wrote: > > On 19/11/2007, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > >> Rahul Akolkar wrote: > >>> On 11/19/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > >>>> sebb wrote: > >>> <snip/> > >>>>> There does not seem to have been a final decision (or even summary) of > >>>>> the e-mail thread, which is a pity. Probably ought to be on the > >>>>> developer section of the commons site. > >>>> Consensus was not reached, so I didn't bother writing any docs for it. > >>>> > >>>>> However: > >>>>> http://www.nabble.com/Re%3A--all--What%27s-in-a-distribution--p8133008.html > >>>>> does ask for the whole of SVN to be included. > >>>>> > >>>>> AFAICS, only one message supported having a single combined archive; > >>>>> at least one other message referred to the need to keep archive sizes > >>>>> small. > >>>> There was a wide variety of opinions, but no clear direction. I have no > >>>> objections towards changing the assemblies. I just don't have the energy > >>>> to push for a standard for Commons assemblies at this time. So I would > >>>> like to use the assembly that we have now for this release. > >>>> > >>>> > >>> <snap/> > >>> > >>> As I mentioned in the thread referenced above, I do think each > >>> component needs to have some sense of communal responsibility, one > >>> that goes beyond this component and this release. I'm sure we can > >>> accomodate variations to distros as it makes sense, and we can > >>> collectively choose to change current styles. > >>> > >>> However, having components package releases differently hurts because > >>> (overarching sentiment is we have many interdependencies, anyone using > >>> one component is likely to need many): > >>> > >>> * For users, having the distros be familiar means less time / > >>> frustration to figure things out > >>> * For developers, having distros be familiar means less inertia to > >>> take on new releases > >> I agree with all of the above. > > > >> We need a common, well documented way of > >> packaging up our distributions. As I stated earlier, I'm not opposed to > >> changing to another form of distribution assemblies. I just don't have > >> the energy ATM to be the driving force behind how such assemblies should > >> look. If someone says "Hey, do it like this" and everyone agrees on > >> that, then I'll change to it. > > > > I've created Jira issue LOGGING-118 which has a patch to create both > > source and binary distribution archives. > > > > I just copied the relevant bits from another commons project (lang). > > > > Seems to work for me. > > I think you are missing my point. I can copy those files too, but it's > the easy way out. We (the whole of Commons) wouldn't gain anything by > doing that. To gain something we should have a proposal for how > assemblies should be done in Commons and which files should be included. > That proposal should then be voted on and documented. Template assembly > files should be committed to commons-build, so that everyone knows how > it is done.
I was just looking for a way forward. I assumed that if lang had done it, then it would be a suitable solution for logging as well. You already fixed a problem with the parent pom by a local change to the logging pom, so there is a precedent. I still have a problem with is the change in the distribution archives for logging. A combined archive is different from previous releases of logging, and is different from all the other commons projects that I have looked at. All of those use separate binary and source archives. I'm saying that logging should not change its distribution strategy without good reason and agreement from the commons PMC. That does not seem to have happened. I may be wrong, but it seems the only reason that the distribution archives have changed is because of the change in build procedures, which happens to have resulted in a combined archive. That does not seem a good enough reason to me. > >>> Finally, for clarity, if you really want to proceed the way you have > >>> things set up, I don't consider that to be a blocking factor. In any > >>> case, the time you're spending on v1.1.1 is appreciated. > >>> > >>> -Rahul > >> Thanks > >> > >> -- > >> Dennis Lundberg > > > -- > Dennis Lundberg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
