Release File naming discussion in IRC

[Christopher <ct...@apache.org>]

Josh and I spoke in IRC for a bit, regarding his comments about the
filenames of the release artifacts.

The summary is: it would be nice if Maven could automatically produce
tarballs with the "apache-" prefix; it cannot, so the names are fine as is.

Transcript follows (minus interrupting bot and join/leave notices). Times
are EDT.
---
(03:00:16 PM) ctubbsii: elserj: I wanted to discuss your concerns about the
file naming conventions for Fluo release artifacts. You mentioned that you
thought future releases should be differently named/prefixed. I'd like to
address that sooner, rather than later, if we can, because I don't think it
would be a good idea.
(03:00:52 PM) elserj: hi
(03:00:57 PM) ctubbsii: hi :)
(03:01:02 PM) elserj: i need to double-check the official release docs
(03:01:15 PM) elserj: i _like_ to see apache-foo*.tar.gz
(03:01:20 PM) elserj: but I don’t think it’s explicitly required?
(03:01:44 PM) elserj: just because, when a user downloads it, it’s the
first real thing they see to reaffirm that this is “Apache Fluo"
(03:02:01 PM) ctubbsii: You mean first, after they've navigated our website
to get to it?
(03:02:10 PM) elserj: ok ok, 2nd?
(03:02:11 PM) elserj: :P
(03:02:16 PM) ctubbsii: Or 3dozenth.
(03:02:19 PM) elserj: well
(03:02:24 PM) ctubbsii: :)
(03:02:24 PM) elserj: consider `yum install fluo`?
(03:02:28 PM) elserj: i guess
(03:02:46 PM) elserj: but even that
(03:02:53 PM) elserj: might be based on an official apache release
(03:02:55 PM) elserj: anyways
(03:03:02 PM) elserj: i don’t think it’s required by policy
(03:03:07 PM) elserj: it’s just something I personally like to see
(03:03:13 PM) elserj: and seemed relevant to mention given recent drama
(03:04:19 PM) ctubbsii: I think there's good reasons not to do it. If you
want me to elaborate, I can, but I was hoping we could just avoid it by
dismissing the concern as relatively subjective.
(03:06:43 PM) ctubbsii: If there's a compelling reason to go that route, I
want to make sure to give it its full consideration, though.
(03:07:28 PM) elserj: No, I’m curious what your hesitation(s) is/are
(03:09:26 PM) elserj: my only concern is that using the full project name
in the areas most likely to hit user’s eyes
(03:09:42 PM) elserj: and, I was assuming that it would be a very
low-impact change to make (I think we do that in accumulo, no?)
(03:10:16 PM) ctubbsii: So, without doing any maven hoop-jumping, the way
this would work is we basically change the artifactId in all the artifacts.
This changes their maven coordinates, which has consequences. We could just
rename the tarball after producing it with the maven release process, but
that adds manual steps (and I prefer automation on releases, as much as
possible).
(03:12:31 PM) ctubbsii: We do not prefix the tarballs in accumulo with
"apache-" for the same reasons.
(03:13:23 PM) ctubbsii: For what it's worth, neither does httpd, hadoop,
thrift, hadoop, and many others (though their reasons may be different than
mine, especially for the non-maven builds).
(03:13:57 PM) elserj: Yeah, I would not be recommending changing
artifactId’s
(03:14:08 PM) elserj: i thought there was an easy finalName attribute that
would allow this
(03:14:36 PM) elserj: maybe that explains my confusion on why apache.pom
doesn’t just do this already
(03:14:38 PM) ctubbsii: finalName will change the directory name inside the
tarball, but not the artifact file name.
(03:14:51 PM) elserj: which would be ultimately attached and deployed?
(03:14:59 PM) elserj: (by the deploy phase)
(03:15:56 PM) ctubbsii: The file name is chosen by the deploy, based not on
the finalName, but on the actual artifactId. The only way you can change
this is by changing the artifactId, or by attaching the file to a different
module (with a different artifactId).
(03:17:02 PM) ctubbsii: Now... as I said, we can rename the tarball outside
of maven, but that makes the names inconsistent with what's in maven, which
can add confusion to users downloading from one place or another, and it
would be a manual step.
(03:43:27 PM) elserj: oops
(03:43:32 PM) elserj: sorry i got distracted
(03:44:00 PM) ctubbsii: np
(03:44:17 PM) elserj: it would be nice if the deploy-plugin (or
assembly-plugin) were smart enough to follow that artifact through
(03:44:48 PM) elserj: but can understand why that isn’t done by default
(03:47:37 PM) elserj: i don’t see anything on a quick glance through
official docs, so fine by me
(03:47:51 PM) elserj: most projects don’t have a fully-automated release
process
(03:48:17 PM) elserj: e.g. some script that prepares artifacts and requires
the RM to deploy them, so that’s probably where the named artifacts came
from
(03:54:43 PM) ctubbsii: The deploy plugin can't deploy to another
artifactId, because it's build tasks must remain limited to "this" project,
which has a pom, and artifacts. A pom for "artfactId1" cannot publish
artifacts for "artifactId2". That would cause all kinds of breakage if it
could.
(03:54:48 PM) ctubbsii: Yeah, even projects which do maven release
automation often have follow-on manual steps (often to remove the deployed
source-release and any binary tarballs).
(03:54:49 PM) ctubbsii: I prefer simplicity and let the automation work as
intended, with minimal modification... as much as possible, stick to the
conventions established by the automation.
(03:56:16 PM) elserj: yeah understood
(03:56:27 PM) elserj: irked by it
(03:56:29 PM) ctubbsii: You also mentioned that "fluo-" be part of the
"build-resources" artifact name. There are two reasons why I think we don't
need to do this:
(03:56:51 PM) elserj: but don’t like the steps required to make the
automation work as intended
(03:57:01 PM) elserj: still in g:o.a.f?
(03:57:26 PM) ctubbsii: Yes.
(03:57:28 PM) ctubbsii: 1) the artifact is primarily intended to be used by
the parent POM during development of Fluo. It is not intended primarily for
users. It is only being "released" (and going through the official source
tarball release process) because we need it in Maven Central for Fluo
builds.
(03:58:30 PM) elserj: maybe the disconnect there is because the maven
coordinates are only related to official release artifact
(03:58:33 PM) ctubbsii: 2) Since it is released, and not actually part of
"fluo" itself, I don't want to mislead people into thinking it is part of,
or required by Fluo. It has the groupId to denote where it came from, but
nothing it contains is special for Fluo.
(03:59:07 PM) elserj: i would assert that if the fluo ppmc is releasing it,
it’s a part of fluo :)
(03:59:26 PM) ctubbsii: No more than wikisearch is part of Accumulo...
(03:59:30 PM) elserj: sure
(03:59:34 PM) elserj: well
(03:59:38 PM) elserj: if we ever released wikisearch
(03:59:55 PM) elserj: simple enough: if you release foo, I believe it is a
part of that project
(04:00:10 PM) elserj: if not the softwar project, the community
(04:00:13 PM) ctubbsii: But this is even less related to fluo... because
it's just an arbitrary set of checkstyle/formatter rules.
(04:00:31 PM) elserj: community > code and what not
(04:00:54 PM) ctubbsii: We actually tried to keep these separate from
Apache Fluo, making use of a release which was not part of Fluo... but you
saw how that went.
(04:01:00 PM) elserj: lol
(04:01:22 PM) elserj: yeah, so i think i disagree on your point #2
(04:01:35 PM) elserj: and will concede that the final coordinate people
will use to access the release imply fluo for point #1
(04:01:44 PM) ctubbsii: Main thing is I don't want people looking for Fluo
artifacts in Maven Central, and wondering if they need this, and what to do
with it.
(04:01:57 PM) elserj: why would they look in central?
(04:02:10 PM) elserj: shouldn’t they look on fluo.i.a.o to see what they
should use?
(04:02:40 PM) elserj: i am used to seeing projects publish the coordinates
they expect users to need to use
(04:02:59 PM) elserj: it may be in other transitive things that the project
creates, but the user doesn’t explicitly need to know
(04:03:45 PM) ctubbsii: Because Maven Central is a huge index of pretty
much every available open source Java library out there... and it's easier
to do a search there than to try to figure out what website to go to. You
have to remember that most people don't start at our site. They are coming
from external.
(04:03:45 PM) ctubbsii: I've searched Maven Central many times for things
like gson, jetty, etc. I don't need their website... I need their artifacts.
(04:03:54 PM) elserj: i agree making it fluo-build-resources with a
G:org.apache.fluo would be duplicative
(04:04:31 PM) elserj: devil’s advocate, you did say earlier that the
website is the first landing place for users of fluo ;)
(04:06:09 PM) ctubbsii: Not quite what I said. I just meant that however
they download it, they're getting it from a place which is going to bombard
them with the fact that it's from Apache. This is true on our website, and
it's also true in Maven Central. (these are the only two places the PPMC is
going to deploy release artifacts).
(04:07:37 PM) elserj: do you have a problem with g:o.a.f a:build-resources ?
(04:07:44 PM) elserj: trying to refocus
(04:08:14 PM) ctubbsii: Not sure what you're asking.... that's what the
artifact is currently named.
(04:08:18 PM) elserj: yes
(04:08:21 PM) elserj: and are you happy with that
(04:09:14 PM) ctubbsii: Yes. I think the question is, are you?
(04:09:23 PM) elserj: yes, i’m fine with it
(04:09:34 PM) ctubbsii: Okay, so is there any other issue with the
artifactIds we should discuss as follow-on action from your vote-thread
concerns? Are you okay with the names of all of the artifacts as is?
(04:09:42 PM) elserj: i think there is a disconnect with GAV and
source-release names
(04:09:47 PM) elserj: but i don’t think that’s a blocker
(04:10:04 PM) ctubbsii: What disconnect?
(04:10:09 PM) elserj: e.g. someone downloading the release from dist.a.o
wouldn’t ever see the GAV, but the consumption of these artifacts is always
through maven'
(04:10:32 PM) elserj: if you go to dist.a.o, you would not know what the
gav was by tarball name only
(04:10:54 PM) elserj: but again, not a big worry. The people doing this are
effectively zero.
(04:11:02 PM) elserj: Just pointing it out
(04:11:24 PM) elserj: I am fine with the artifact names per asf release
policy
(04:11:42 PM) ctubbsii: Right... but you could search for the file by name
and find it.
(04:11:54 PM) elserj: I will continue to lament that we can’t have
apache-foo-source-release.tar.gz put in there easily by the apache.pom :)
(04:11:59 PM) elserj: yes, you could
(04:13:10 PM) ctubbsii: If we weren't a Maven project, I'd lament with you.
Most of what I'm pushing for is with respect to what makes sense as a Maven
project.
(04:13:24 PM) ctubbsii: Should I copy/paste this transcript to the dev list
for archival purposes?
(04:13:40 PM) elserj: I do not mind if you do. I leave it up to your
discretion