On 24/02/11 00:09, Colin Watson wrote:
On Thu, Feb 17, 2011 at 03:03:08PM -0500, Barry Warsaw wrote:
On Feb 17, 2011, at 10:33 AM, Steve Langasek wrote:
How do we distinguish commits that ought to be built from those that
don't? One way is to say we'll rebuild on things that add a new debian
changelog (with a higher version.) Some people commit changes with a
series target of 'unreleased' and we could then just actually assemble the
package when that flips to be a real series.
Either there needs to be a separate adjunct branch that gets pushed to
*from* lp:ubuntu/$package to trigger builds, or this needs to only build
when a new version (previously unknown to the archive) has been tagged on
the branch. A lot of time has been spent on socializing the idea that we
can use the existing lp:ubuntu branches to stage changes, and upload to the
archive for building only when we're ready; to have some branches diverge
>from this behavior and start building for the archive for each commit, even
if someone has nominated the branch in question for some sort of whitelist,
would result in a number of wrongly published packages.
I think the 'bzr mark-uploaded' interface, which sets the appropriate
version tag, is the natural fit for this.
Observing my recent use, I think there are two things that together indicate
that a particular source branch revision is ready to be uploaded. First, the
changelog entry's series is correct (i.e. natty, -proposed, etc.), *and* the
version number does not have a ~ in it.
I'm with others on this who find tagging a more explicit and safer
interface. ~ in changelogs isn't going to be a sufficient heuristic:
$ grep-aptavail -FVersion \~ -nsPackage | wc -l
1386
Even if you exclude cases where ~ is part of the upstream version (a
common way to indicate a pre-release):
$ grep-aptavail -rFVersion '.*-.*\~' -nsPackage | wc -l
39
~ was introduced so that it could be used in real versions in the
archive - it wasn't meant as just an unreleased marker.
Cheers,
Yes, I've been following this convention where:
$UPSTREAM-VERSION~bzr$(bzr revno)-0ubuntu1
== Upstream snapshot, before version is released.
$UPSTREAM-VERSION-0ubuntu1
== Upstream released version.
$UPSTREAM-VERSION+bzr$(bzr revno)-0ubuntu1
== Upstream released version, plus some some commits - but not yet
near new upstream version.
For projects that maintain a 'fixes' branch for a released version:
's/+bzr/+fixes/'
On another note, might it be a good idea to add build-from-branch
support initially as PPA functionality? This enables people to trial it
on /any/ package, identify goofs, make mistakes, try and break it, then
give reasoned feedback without any concern of destabilizing the real
archive.
Perhaps create a project called build-from-branch and use a convention
of lp:build-from-branch/$LPID, where I could then propose a merge from
lp:~davewalker/build-from-branch/$SOMETHING (or push directly), and
every user which requests to trial it gets a PPA called their LPID under
~build-from-branch-testers or similar.
It would be /nice/ if every bzr push to LP required the topmost commit
to GPG signed or at least present who pushed a commit to a branch based
on SSH key. I find it somewhat odd that i can:
bzr branch lp:~someoneelse/+junk/their-scratching-area
bzr push lp:somewhere-serious
... and the result appears that ~someonelese pushed their rough code
somewhere serious, which to the best of my knowledge cannot be linked to
myself without someone grepping logs. I feel the UI should at least
present that it was me that pushed their commit somewhere. This concern
becomes more important when pushing bzr to archive becomes involved.
Kind Regards,
Dave Walker
--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
