Brian, > Ok then, I assert they are all fine. Now you can provide a list and > refute me ;-). In this case (if they were all fine) here is your list: http://repo2.maven.org/maven2/.index/ (But unfortunately they are not all fine.)
> Seriously, the definition of "broken" depends on the observer. True. This is why maybe there should be different "Good lists" and users should be allowed to choose, depending on their taste. > Before we can > "fix" anything "broken" we need to start by defining what you think is > broken and why. One of the possible Definitions of "Good list", which I would like call "Maven Central Compliance" is defined here: http://maven.apache.org/guides/mini/guide-central-repository-upload.html If artifacts are on Central which are not on this list (which list should really be realized soon), I don't mind, as long as I could search or filter by this list. You cannot objectively define what is "broken" only if you specify which Lists you are talking about. Do you mean, the "Maven Central Compliance" list? On Mon, Oct 5, 2009 at 12:38 PM, Brian Fox <bri...@infinity.nu> wrote: >> >> 2. >>> Provide a detailed list of artifacts and metadata you consider broken. >> I think this approach will not work. >> You should really work on providing list of artifacts which are not >> broken (Certified good list), and having a Maven client which is able >> to use this list (or multiple lists) for filtering and searching. > > Ok then, I assert they are all fine. Now you can provide a list and > refute me ;-). > > Seriously, the definition of "broken" depends on the observer. A pom > that doesn't mark something as optional only appears broken to users > who don't otherwise need that dependency for example. Before we can > "fix" anything "broken" we need to start by defining what you think is > broken and why. > >> >> 3. >>> When these artifacts are identified, work with the teams producing >>> these poms to educate them on the proper pom constructs to eliminate >>> them. >> If you have a list (or multiple lists which classify them by testing >> different qualities) of good artifacts, teams will try to deliver >> their artifacts to these lists by educating themselves. >> Trying to police these teams, you will just receive resistance. > > Not true from experience, again this is subject to the definition of broken. > >> >> >> >> Regards, >> Albert >> >> >> >> >> On Thu, Oct 1, 2009 at 6:51 PM, Brian Fox <bri...@infinity.nu> wrote: >>> Albert, >>> Clearly you seem to have plenty of enthusiasm for helping to provide >>> better metadata, and I don't want to discourage that. >>> >>> Providing and hosting a repository containing 90 thousand files that >>> serves greater than 12TB of data a month is not as easy as you might >>> imagine. Starting over with a new repository is not the answer here. >>> >>> Getting 90k artifacts vetted and cleaned is a significant undertaking. >>> Frankly many of the artifacts in there are old, underused versions and >>> spending effort on those will have much less immediate impact than >>> stopping new artifacts getting in that have bad (or missing) data. We >>> have chosen to attack this problem by raising the barrier to entry for >>> new artifacts. This work started months ago and we'll be able to put >>> something in place in the next few weeks. >>> >>> This will be done in an automated fashion, starting with artifacts >>> that are uploaded manually. Then we will apply the same rules >>> (automatically) to anything coming in via rsync. Besides improving and >>> vetting the data coming in, this more automated process is designed at >>> drastically improving the turnaround time to get new artifacts and >>> sync's configured. >>> >>> If you really want to assist here, I can see several ways you >>> personally can assist this process: >>> >>> 1) Contribute _code_ that validates the various conditions you think >>> are important to validate. We already have an interface developed that >>> I can point you at if you're interested. These rules will help in many >>> ways because it will help check new artifacts, check old artifacts, >>> and allow people to use them with their repository manager internally >>> if they choose. >>> >>> 2) Provide a detailed list of artifacts and metadata you consider >>> broken. We can sit around and theorize about how things could be >>> better, but first having a concrete list of broken poms and other data >>> will help us focus on the most prominent problems first. The MEV >>> project in Jira is where we collect these. I don't care much if you >>> produce one jira or a jira with a huge list, it's the gathering of the >>> list that is most important. >>> >>> 3) When these artifacts are identified, work with the teams producing >>> these poms to educate them on the proper pom constructs to eliminate >>> them. Generally the teams don't produce bad data on purpose so some >>> education is required. >>> >>> 4) Assuming we have identified a significant number of the problems >>> from work done in #2, we would then need concrete proposals for how to >>> fix this without breaking people's builds. Proposals can be posted on >>> the MAVENUSER wiki space for futher discussion and refinement. >>> >>> 5) Assuming the proposals gather momentum, someone would need to code >>> the proposals >>> >>> 6) Then assistance would be needed to actually cleanup the metadata in >>> the context of the implementation. >>> >>> Things get done around here by people actually stepping in to get them >>> done. You're enthusiastic and we'd be glad to accept help in the areas >>> above. I think further theorizing at this point is going to get >>> diminishing returns, and I personally think attempting to fork an >>> entire repository is not going to help the users as much as even >>> items #1,2,3 above. >>> >>> Brian Fox >>> Apache Maven PMC Chair-Elect >>> >>> >>> >>> >>> >>> On Thu, Oct 1, 2009 at 12:13 PM, Albert Kurucz <albert.kur...@gmail.com> >>> wrote: >>>> I would like to see some votes: >>>> >>>> 1. Big Rotten Onion >>>> 2. Starting Over After Writing New Policies >>>> >>>> On Thu, Oct 1, 2009 at 2:04 PM, Albert Kurucz <albert.kur...@gmail.com> >>>> wrote: >>>>> You know where Option1 will drive us? >>>>> When the added metadata which hides current corruption will become >>>>> corrupt, we need another layer. >>>>> At the end, it will look like a big onion. :) >>>>> >>>>> Where will Option2 will get us? >>>>> The new repo will get corrupted again. >>>>> Unless the policy of repo-ing something will get rewritten, like this: >>>>> only source code can be uploaded in packages to a public repo. >>>>> Compile can only take place locally when you are checking out >>>>> something or after (lazy checkout). >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
