Andreas Ericsson <ae <at> op5.se> writes:
> > * make releases without tags: For example, the weekly trunk snapshots of
> > KDE don't get tags, nor do the extragear tarball releases.
>
> I'm not sure if you saw my email regarding the requirements on the SCM for it
> to be useful in the scenario Doug Ledford proposes, but right at the top of
> the list comes the ability to uniquely name one particular commit. If you
> have that, you don't need tags.
The problem with commit IDs is that they're a lot less readable and intuitive
than tags.
> It would be extremely poor project policy to move a tag after it's made
> public
Are you trying to imply that KDE has "extremely poor project policy"? I think
it only makes sense to do respins that way. A release isn't always perfect on
the first try.
> For centralized scms, moving tags doesn't matter in the slightest, since
> they can't name a commit uniquely anyway.
That's not true, a SVN commit is uniquely named by the revision number. And in
fact, being centralized allows SVN to actually use totally-ordered numbers, not
random IDs coming from the checksum of something (which are bound to break the
day you run into a collision, by the way).
The best way to reproducibly name a tag in SVN would be to use the tag name
(which would be part of the URL) _and_ the revision number. Tags in SVN are
just directories, so you can use the directory at the given revision and you'll
get the exact thing you originally checked out.
> Me, being mostly a user who also happens to be a programmer, would love
> to have an easy way to be able to get a clone of <insert-package-here>,
> find the sources corresponding exactly to my version of the package and
> then fix whatever issues I have with it. Even if it was just me willing
> to do that (which I highly doubt), you'd have a net gain of one extra
> spare-time developer. You can't possibly argue that making it easier for
> casual developers to get involved is a bad thing.
With the current system, you just have to check out the package and run "make"
in one of the branches to get all source files (usually just a tarball)
downloaded from the lookaside cache. Extract the tarball and you have your
sources. The patches aren't applied there, but that's by design. Patches are
supposed to be independent, so (with some exceptions, e.g. the kernel which
often includes series of interdependent patches automatically generated from
some git repository) we develop each patch against the _original_ sources, then
only when actually building the package we apply them all.
My workflow when I develop a patch for KDE is:
1. I extract the tarball (e.g. kdebase-workspace-4.0.98.tar.bz2).
2. This creates a directory (e.g. kdebase-workspace-4.0.98).
3. I copy this directory, appending the name of the patch I intend to write
(e.g. kdebase-workspace-4.0.98-consolekit-kdm).
4. I make my changes in that directory (e.g.
kdebase-workspace-4.0.98-consolekit-kdm).
5. I diff the original vs. the patched directory (e.g. diff -Nur
kdebase-workspace-4.0.98 kdebase-workspace-4.0.98-consolekit-kdm
>kdebase-workspace-4.0.98-consolekit-kdm.patch).
6. I copy the patch to the package branch.
7. I cvs add it to the repository.
8. I apply it in the specfile (2 lines, e.g. Patch1:
kdebase-workspace-4.0.98-consolekit-kdm.patch in the header
and %patch1 -p1 -b .consolekit-kdm in the %prep section).
9. I commit.
10. I run make tag.
11. I run make build BUILD_FLAGS=--nowait.
12. Koji sends me the results.
13. If the build failed, I:
* repeat steps 4, 5, 6 and 9
* run make force-tag
* resubmit the failed build through the Koji web interface
as often as needed until it builds.
I know this sounds overly complicated, but keep in mind that most of these
steps are just a couple of mouse clicks or one line in a terminal, I
intentionally detailed them so a beginner can understand what's going on. I'm
not sure a SCM with fully-exploded sources would really make that easier.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
