Re: [E-devel] Problems with building engage from cvs

[Carsten H. (T. R. <ra...@ra...>]

On Wed, 2 Mar 2005 14:49:41 -0500 Michael Jennings <e-...@ka...> babbled:

> On Wednesday, 02 March 2005, at 11:43:09 (+0900),
> Carsten Haitzler wrote:
> 
> > because of this:
> > 
> > asapagus.sh:
> > <<<snip>>>
> 
> I'm sure that's great for you, but you're not the only one dealing
> with these packages.
> 
> If you're already updating configure.in, you should update the spec
> files at the same time.  And all the other packaging files.  It's no
> more difficult than what you've already done.

i just moved eet to auto-generate everything. rpm's build. debs should and oe/bb
packages should build too. it uses the master version info in configure.in

> > i did - i said it helps making snapshots without having to fiddle
> > the main version and play with libtool versioning info
> > etc. etc. etc. etc.
> 
> For you, and only you.

no - for many others too. it means now that a packages version is consistent
with a source snapshot.

> > it makes automated releases that have a CONSISTENT VERSIONING SCHEME simple.
> 
> See above.

see above.

> > yes it is. see above. it IS an integer.
> 
> "001" is an integer.  ".001" is not.

if we are arguing over the that. then every version is not a number as it has
multiple "dots" why not just call the version "shksda_sew.eew" ? the fact is
before there was an inconsistent extension to the version scheme (x.y.z) and now
i made it consistent (x.y.z.v) and moved that consistency across a large chunk
of EFL. now versions can be consistently compared between source snaps AND
packages ALL you need to do is EXACTLY what u did before - go and edit the
version field in the .spec - it has not changed WHAT you have to do. not 1 iota
in principle. if i go changing versions of nay package u need to update the
.spec. i have done this many times in the past and not once was there any
complaint like this - not once "ooh you changed the version number. we need to
have a meeting about changing version numbers". it never happened in the past.
why this time? what is so offensive about an extra version number (that rpm
handles just fine btw). in order to make it easier to provide snapshots and
reduce the overhead of answering support mails about "my autofoo version X
doesnt work with Y Z etc." ?

> > see above - again. it means the SAME rule can be applied to ALL
> > packages - no exceptions. for those close to a 1.0.0 we can keep
> > them at 0.9.9 or 0.16.999 for example - we can up the real version
> > as we please with automated releases incrementing the release. for
> > somone who does rpm packaging you seem to have instantly forgotten
> > the release number in packages (-1, -2, -3 etc.) the moment u look
> > at src. the .001 is the exact equivalent to it - but on the source
> > side.
> 
> You are not making changes to all packages at once.  Thus you have
> created a situation where there may be a "release" of a particular
> package in which nothing whatsoever has changed from the previous
> "release."  I don't see this as a good thing, and it's no better than
> CVS snapshots.

if u read the script. u will notice my ~/s/asparagus can release an increment
just 1 package alone. m y master script that just goes over everything does
everything in the list i give it.

and its much better than cvs snaps. cvs snaps are just cvs checked out and
tarred. people still need to have autofoo to build them. release tarballs do not
need this.

> While saving yourself some work, you've created a metric fuck-ton of
> work for those of us doing packaging.  What you *should* do, IMHO, is
> put someone in charge of Release Management.  If one or more packages
> are at a stable point for a release of some type, let the release
> manager worry about version number changes and such.

dude - i've asked before to have a release manager. no one has stepped forward
and stayed there. there's people making packages for disparate systems and
packaging schemes, but no release manager. i have given up asking as all i do is
wait for someone to step up and do it and end up getting impatient and doing it
anyway.

> These are separate packages.  Not everything should be released all at
> once, particularly when nothing has changed from the last release.
> Trying to treat them all as one big unit defeats the purpose of having
> things split out into libraries.

agreed - amazingly thats why i have a script that can make a release of just 1
of them at a time. i also have one that can just do all of it.

> Furthermore, adding .NNN to the end doesn't create a versioning scheme
> that's any more or less consistent than before (except for the 3
> packages erroneously using _preXX).  The only thing it accomplishes is
> tagging everything with the same suffix, and by using the same suffix
> for disparate packages, you've rendered it completely useless.  No
> useful information is gained from .001 or .002 other than that .002 is
> a bigger number.  Anything or nothing may have changed for any
> particular package, and the unsuspecting user is forced to download
> them ALL again even though there may be no difference whatsoever.

> MAJOR.MINOR.PATCHLEVEL is a perfectly reasonable scheme, and when done

the problem is we already are overloading the patchlevel and we just need
another minor level below that. i plan on removing the .NNN once things go gold.
but for things like E17 that is 0.16.999, ecore 0.9.9 and evas 0.9.9 is getting
a bit silly - so i'm putting a "disposable" extra version at the end.

> properly it provides useful information regarding which packages have
> changed and which have not.  I can certainly understand what a pain it
> can be to manage 18 different packages on your own, but the solution
> is not to make it easier for you while making it harder for everyone
> else.  The solution is to stop making it a one-man show when it's
> not.  Put a release manager (shadoi?  dj2?  digitalfallout?) in charge
> of the packages you "own," and let the maintainers of other packages
> (RbdPngn for EWL, HandyAndE for engage, xcomp/atmos for entrance,
> etc.) do their own releases.

as i said. i had ASKED ages ago. dig thru the archives.

> And brainstorm things before you take unilateral action, at least when
> it comes to packaging and such.  There's a chance somebody might have
> a different/better/cleaner idea.

i'm not sure whats hard or unclean about the .NNN - beyond offending your
sensibilities. it lets users see that the version is indeed a snapshot release
number, not a version update. it is numeric. it works in packging systems. no
one has complained before about version updates.

you know how it works. you ask someone to do something, someone might say "yes
me" they do it for 3 months, then vanish. the developers already have enough to
do without becoming release maintainers. in the end any release manager will end
up doing something like this to make their lives easier - automating it. if
anything i've gone and made their lives easier if someone wants to be in charge
of such things.

now back to something productive... i've gone and made eet fully
auto-releasable. .spec, debian package versions etc. etc. etc. i have built rpm
and debian packages (as per the README) right now and they build find with the
correct versions. see the README. packagers need to do nothing more than execute
those commands after getting a source tarball snap.

now if THAT is now a fuck-tonne more work than u currently have... you have a
strange idea of more work :) its as close to zero work as possible as i can see
(beyond adding make rules to run the rpm and deb packaging commands for you - ie
make rpm, make deb etc.)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...
裸好多                              ra...@de...
Tokyo, Japan (東京 日本)