Question about tagging

[Rick L. Vinyard, Jr.]

I'm trying to build cairomm 1.8.4 in devel, but the tags that I get are
dist-f12, and when I try and actually do the build I get an error saying:

/usr/bin/koji  build  dist-f12
'cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/cairomm/devel#cairomm-1_8_4-1_fc12'
Usage: koji build [options] target URL
(Specify the --help global option for a list of other help options)

koji: error: Destination tag dist-f12 is locked
make: *** [koji] Error 1


Shouldn't I be getting f13 tags with "make tag"?

[Tom Callaway]

On 11/18/2009 10:29 AM, Rick L. Vinyard, Jr. wrote:
>  Shouldn't I be getting f13 tags with "make tag"?
If you run: cvs update -d in the top level checkout directory, you will. ;)

~spot

[Rick L. Vinyard, Jr.]

Tom \"spot\" Callaway wrote:
>  On 11/18/2009 10:29 AM, Rick L. Vinyard, Jr. wrote:
> > Shouldn't I be getting f13 tags with "make tag"?
>
>  If you run: cvs update -d in the top level checkout directory, you will.
>  ;)
>  
I did. What I generally run is 'cvs -PAd'

I even removed the devel directory and re-checked it out by running 'cvs
-PAd' in the top level directory.

[Tom Callaway]

On 11/18/2009 10:53 AM, Rick L. Vinyard, Jr. wrote:
>  Tom \"spot\" Callaway wrote:
> > On 11/18/2009 10:29 AM, Rick L. Vinyard, Jr. wrote:
> >> Shouldn't I be getting f13 tags with "make tag"?
> >
> > If you run: cvs update -d in the top level checkout directory, you will.
> > ;)
> >
>  
>  I did. What I generally run is 'cvs -PAd'
>  
>  I even removed the devel directory and re-checked it out by running 'cvs
>  -PAd' in the top level directory. 
Hmm, then something else odd is going on.

~spot

[Michael Schwendt]

On Wed, 18 Nov 2009 08:53:16 -0700, Jr. wrote:

>  Tom \"spot\" Callaway wrote:
>  > On 11/18/2009 10:29 AM, Rick L. Vinyard, Jr. wrote:
>  >> Shouldn't I be getting f13 tags with "make tag"?
>  >
>  > If you run: cvs update -d in the top level checkout directory, you will.
>  > ;)
>  >
>  
>  I did. What I generally run is 'cvs -PAd'
>  
>  I even removed the devel directory and re-checked it out by running 'cvs
>  -PAd' in the top level directory. 
What about the "common" directory? That's the important one, one level
above "devel".

$ cat cairomm/common/branches|grep devel
devel:dist-f13:.fc13:fedora:13

[Rick L. Vinyard, Jr.]

Michael Schwendt wrote:
>  On Wed, 18 Nov 2009 08:53:16 -0700, Jr. wrote:
>
> > Tom \"spot\" Callaway wrote:
> > > On 11/18/2009 10:29 AM, Rick L. Vinyard, Jr. wrote:
> > >> Shouldn't I be getting f13 tags with "make tag"?
> > >
> > > If you run: cvs update -d in the top level checkout directory, you
> > will.
> > > ;)
> > >
> >
> > I did. What I generally run is 'cvs -PAd'
> >
> > I even removed the devel directory and re-checked it out by running 'cvs
> > -PAd' in the top level directory.
>
>  What about the "common" directory? That's the important one, one level
>  above "devel".
>
>  $ cat cairomm/common/branches|grep devel
>  devel:dist-f13:.fc13:fedora:13
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>  

That was it. Thanks.

[Alex Lancaster]

> >>>> "-" == Rick L Vinyard,  writes: 
-> Michael Schwendt wrote:
> > On Wed, 18 Nov 2009 08:53:16 -0700, Jr. wrote:
>
> > Tom \"spot\" Callaway wrote:
> > > On 11/18/2009 10:29 AM, Rick L. Vinyard, Jr. wrote:
> > >> Shouldn't I be getting f13 tags with "make tag"?
> >> >
> >> > If you run: cvs update -d in the top level checkout directory, you
> >> will.  > ;)
> >> >
> >> 
> >> I did. What I generally run is 'cvs -PAd'
> >> 
> >> I even removed the devel directory and re-checked it out by running
> >> 'cvs -PAd' in the top level directory.
> > 
> > What about the "common" directory? That's the important one, one
> > level above "devel".
> > 
> > $ cat cairomm/common/branches|grep devel
> > devel:dist-f13:.fc13:fedora:13
> > 
> > -- fedora-devel-list mailing list fedora-devel-list(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> >  
>  That was it. Thanks. 
This has bitten me (and other users judging from the earlier reports
here) before.  It would be better if "make tag" was to check that the
"common" directory that it checked for "branches" was up to date
*before* allowing "make tag" to proceed.

This is the kind of thing that is very easy to overlook when you are
away from maintaining packages for a while and should be automated.

Which component would be best to open a trac ticket for this
functionality against?

Alex

[Jesse Keating]

On Wed, 2009-11-18 at 20:32 -0500, Alex Lancaster wrote:
>  
>  Which component would be best to open a trac ticket for this
>  functionality against?  
It basically needs to be fixed in Makefile.common, but my plan to fix it
involves getting rid of CVS all together, and while doing that getting
rid of the need for a common/ dir to carry around and update.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Mat Booth]

2009/11/19 Jesse Keating <jkeating(a)redhat.com&gt;:
>  On Wed, 2009-11-18 at 20:32 -0500, Alex Lancaster wrote:
> >
> > Which component would be best to open a trac ticket for this
> > functionality against?
>
>  It basically needs to be fixed in Makefile.common, but my plan to fix it
>  involves getting rid of CVS all together, and while doing that getting
>  rid of the need for a common/ dir to carry around and update.
>  

Exciting times. In your plan, what will be replacing CVS?

-- 
Mat Booth

[Jesse Keating]

On Thu, 2009-11-19 at 12:02 +0000, Mat Booth wrote:
>  Exciting times. In your plan, what will be replacing CVS? 
If I had my way and did it today, git.  Each package would be its own
module, and each fedora release would be represented by a real branch in
the git module.  We'd have a userland tool, as part of fedora-packager,
that would allow simple commands to clone the module (and get master,
which would build things for rawhide), or clone the module and all its
release branches and construct a directory layout much like dist-cvs is
today.

Build commands would be part of fedora-packager, not makefiles in every
module.  Decisions on where to build the package would be based on what
branch is being built from, programatically so that we don't have to
keep updating some file somewhere to figure it out.  Maintainers would
not tag themselves, as the buildsystem would build from git hashsums,
and only successful builds would have a human readable tag applied to a
given hashsum, and that would be done by the build system.  There would
be no need to translate %dist values on the local user's system.

That's what I got so far, I'm hoping to walk through a typical scenario
with folks at FUDCon to see how well my plan stands up.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Kevin Kofler]

Jesse Keating wrote:
>  If I had my way and did it today, git.  Each package would be its
> own
>  module, and each fedora release would be represented by a real branch in
>  the git module.  We'd have a userland tool, as part of fedora-packager,
>  that would allow simple commands to clone the module (and get master,
>  which would build things for rawhide), or clone the module and all its
>  release branches and construct a directory layout much like dist-cvs is
>  today.
>  
>  Build commands would be part of fedora-packager, not makefiles in every
>  module.  Decisions on where to build the package would be based on what
>  branch is being built from, programatically so that we don't have to
>  keep updating some file somewhere to figure it out.  Maintainers would
>  not tag themselves, as the buildsystem would build from git hashsums,
>  and only successful builds would have a human readable tag applied to a
>  given hashsum, and that would be done by the build system.  There would
>  be no need to translate %dist values on the local user's system.
>  
>  That's what I got so far, I'm hoping to walk through a typical scenario
>  with folks at FUDCon to see how well my plan stands up. 
And why can't all this be done with s/git/SVN/? All we really need apart 
from what CVS already provides is atomic commit IDs, to make the 
"maintainers would not tag themselves" part easily implementable. I don't 
see why SVN revision IDs wouldn't be as good as git hashsums for that.

In fact, in principle, it could even be done with CVS, but instead of 
tagging a single revision ID, the build system would have to tag the 
revision ID it checked out for each file. Having atomic commits just allows 
dragging around just one revision ID instead of a set of IDs.

        Kevin Kofler

[Jesse Keating]

On Fri, 2009-11-20 at 00:50 +0100, Kevin Kofler wrote:
>  
>  And why can't all this be done with s/git/SVN/? All we really need apart 
>  from what CVS already provides is atomic commit IDs, to make the 
>  "maintainers would not tag themselves" part easily implementable. I don't 
>  see why SVN revision IDs wouldn't be as good as git hashsums for that.
>  
>  In fact, in principle, it could even be done with CVS, but instead of 
>  tagging a single revision ID, the build system would have to tag the 
>  revision ID it checked out for each file. Having atomic commits just allows 
>  dragging around just one revision ID instead of a set of IDs.  
With sufficient hackery it could be done with either svn or cvs, however
many of our upstreams are moving or have moved to git, and there is a
strong desire for our scm to follow suit.  This really will wind up
being decided by the person putting in the work to get it done, which at
the moment is me.

The added benefit of offline operation makes git even more appealing,
and while I know you can hack svn into doing something like that, I'd
rather go with something that is designed for it.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Toshio Kuratomi]

On Thu, Nov 19, 2009 at 08:50:06PM -0800, Jesse Keating wrote:
>  On Fri, 2009-11-20 at 00:50 +0100, Kevin Kofler wrote:
>  > 
>  > And why can't all this be done with s/git/SVN/? All we really need apart 
>  > from what CVS already provides is atomic commit IDs, to make the 
>  > "maintainers would not tag themselves" part easily implementable. I
> don't 
>  > see why SVN revision IDs wouldn't be as good as git hashsums for that.
>  > 
>  > In fact, in principle, it could even be done with CVS, but instead of 
>  > tagging a single revision ID, the build system would have to tag the 
>  > revision ID it checked out for each file. Having atomic commits just allows 
>  > dragging around just one revision ID instead of a set of IDs. 
>  
>  With sufficient hackery it could be done with either svn or cvs, 
Kevin'spoint is that svn would require less new hackery than git.  I believe
he's right about that as svn provides whoe-tree changesets without adding
all of the vastly different semantics that git does.

OTOH, nobody who hasshown up to do work has shown interest in a centrally
managed scm, only dvcs and just as you point out, really it's who's
interested in doing the work that matters.  Although I will say that the
reason that we didn't switch to a different scm years ago was not that no
one wanted to do the work but that no one wanted to step on enough people's
toes while doing the work.

-Toshio