Re: [gentoo-dev] RFC Package name additions

2007-03-19 Thread Kevin F. Quinn
On Sat, 17 Mar 2007 10:46:22 +0100
Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote:

 One thing we could do would be to separate hierarchy from version
 naming.

This is where upstream version numbers fail to have a decent order
(like your example where later versions have lower version numbers).
It could be done for example by extending metadata to include
definitions of unnatural ordering, but I don't think it's worth the
effort.  So far we deal with that on a case-by-case basis, and live
with the pain when it occurs.

 This would prevent cases like currently with rosegarden (~)1.2.4
 (~)1.4.0 4.1.0-r1 4.1.0-r2, where it really should be 4.1.0-r1
 4.1.0-r2 (~)1.2.4 (~)1.4.0.

For example, a simple solution is to just re-number the (presumably
older) 4.* as 0.4.* and be done.  That would also solve the potential
future problem when the latest release reaches 4.* again. The sequence
I would do is:

  1) copy 4.1.0* to 0.4.1.0*, commit to the tree (here you could either
 rig the SRC_URI to keep the old tarball names, or copy the old
 tarballs again with the new revision number)

  2) Alter any packages that depend on the 4.1 versions explicitly, to
 depend on the 0.4.1 versions (after you're sure the new 0.4.*
 versions are in the tree).

  3) Remove the 4.1* versions - after a delay (a few days, a
 week, whatever, depending on how often your users are likely to
 update); in the changelog note that users should expect a
 downgrade and it is ok to do so.  As a minimum, delay until
 you're sure (1) and (2) have reached the rsync mirrors.

  4) Get 1.2*, 1.4* stablilised some time later in the normal way.

Actually a quick scan of the tree shows there's nothing affected by (2)
so that step can be skipped. I'd recommend still having a delay between
the copy (1) and the removals (3) - at least long enough for the copies
to propogate to the rsync mirrors before the removals happen (I'd
probably do the copy one day, check that got through ok the next day
and do the removals then). Noting the expected downgrade in the
changelog when the higher-numbers are removed is important (this is
what users will see if they do emerge -l).

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Harald van Dijk
On Fri, Mar 16, 2007 at 09:24:33PM -0400, Mike Frysinger wrote:
 On Friday 16 March 2007, Miroslav Šulc (fordfrog) wrote:
  Just a note to this. I'm co-maintainer of netbeans ebuild. Netbeans does
  milestone releases. These are pretty stable and usable since milestone 7
  of netbeans 6.0 with many new features that make sense to use the
  milestone releases. I have to name the ebuilds netbeans-6.0_alpha7 etc.
  though I was assured by mkt guy from Sun it is not yet alpha quality. It
  would be fair to the upstream and to users to not use _alpha because it
  is not alpha but there's no appropriate choice available.
 
 i would use _p# over _alpha#

6.0_p7 is considered a higher version than 6.0, right? That will probably
cause problems in the future. _pre# may be a good choice, though.


pgpAEes51I0pb.pgp
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Ilya A. Volynets-Evenbakh
Rather then analyze the proposed solution, I'd like to
question the problem itself. Do we really want to provide
all the different intermediate development sort of releases
in our tree?

William L. Thomson Jr. wrote:
 After reviewing 

 http://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules


 I still seem to be having to finagle version names for some packages. At
 the moment it would be nice if we also had the following suffixes
 available

 _dev
 Apache upstream, specifically Tomcat/mod_jk tends to do developer
 snapshots that they then host out of developer space. People do fetch
 bins and source from there for testing. It's kinda pre-release, so I
 have been using _pre where I would use _dev, but _pre does not make much
 sense.

 _build
 Other packages seem to do constant builds (weekly) of the same version.
 For example Glassfish (Sun's FOSS J2EE stuff). It's sources are v2-b39.
 So would be nice to be able to do like glassfish-servlet-api-2_build39

 _snapshot
 This one is kinda universal in it's name/implication. Would be for any
 sort of upstream snapshot release, that might not be versioned as such.
 Short of the name snapshot being some where.

 The above would then follow the rest of the normal schema, where in they
 could still be suffixed by a number, or not.

 Hierarchy would be the following

 snapshot - dev - build - alpha - beta 

 Or at least that's my thoughts on it. Time for others thoughts, much
 less those that will make it so. Not expecting it to get done or be
 available any time soon. Would be suffice if they were just accepted and
 planned for inclusion at some point.

   

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread William L. Thomson Jr.
On Sat, 2007-03-17 at 01:08 -0700, Ilya A. Volynets-Evenbakh wrote:
 Rather then analyze the proposed solution, I'd like to
 question the problem itself. Do we really want to provide
 all the different intermediate development sort of releases
 in our tree?

That came up in the link I provided in another post.
http://marc.info/?l=tomcat-devm=117251925901310w=2

IMHO I think it should be up to the package maintainer how close they
want to follow upstream. With regard to development, progress, testing,
qa, feedback. I think it's a very good thing, since it allows things to
be caught before actual releases, during development.

I know when I am developing stuff, it's way easier to address during the
process rather than after the fact.

But if there are any policies or etc. I surely do not want to be
breaking them. Also this is not broken or really experimental stuff. If
it was I would either p.mask, or put in an overlay.

Although I feel things tend to get the greatest exposure and chance of
user testing and feedback, if it's in tree.

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Miroslav Šulc (fordfrog)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to
http://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules
it seems to me the versioning is focused on package stability life
cycle. In netbeans case it is _prealpha and definitely not stable
patched release. So _alpha is the closest one to current netbeans 6.0
life cycle phase, though not accurate.

- --
Miroslav Šulc (fordfrog)
Gentoo/Java Team


Mike Frysinger napsal(a):
 On Friday 16 March 2007, Miroslav Šulc (fordfrog) wrote:
 Just a note to this. I'm co-maintainer of netbeans ebuild. Netbeans does
 milestone releases. These are pretty stable and usable since milestone 7
 of netbeans 6.0 with many new features that make sense to use the
 milestone releases. I have to name the ebuilds netbeans-6.0_alpha7 etc.
 though I was assured by mkt guy from Sun it is not yet alpha quality. It
 would be fair to the upstream and to users to not use _alpha because it
 is not alpha but there's no appropriate choice available.
 
 i would use _p# over _alpha#
 -mike
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF+6oPRSzWCmqu+0YRAhPAAJ99Et9Uwk/JrpRPkukABgrc3CdLfQCghrm+
noRpxMDQvlxrlLhFUdqb088=
=gC2k
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Ilya A. Volynets-Evenbakh
William L. Thomson Jr. wrote:
 IMHO I think it should be up to the package maintainer how close they
 want to follow upstream. With regard to development, progress, testing,
 qa, feedback. I think it's a very good thing, since it allows things to
 be caught before actual releases, during development.

 I know when I am developing stuff, it's way easier to address during the
 process rather than after the fact.

 But if there are any policies or etc. I surely do not want to be
 breaking them. Also this is not broken or really experimental stuff. If
 it was I would either p.mask, or put in an overlay.

 Although I feel things tend to get the greatest exposure and chance of
 user testing and feedback, if it's in tree
There is a bit of contradiction in what you said there.
Either the package is well tested, and should go into the tree, first
with ~arch keywords, and then eventually with arch keywords, or
it is experimental, and as such has to be outside of our main tree.

Thus you can either want to test stuff by giving it more exposure,
which implies the stuff is experimental, or you have stable stuff,
but then you shouldn't be talking about the development cycle of the
said software.



-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Jakub Moc
Miroslav Šulc (fordfrog) napsal(a):
 According to
 http://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules
 it seems to me the versioning is focused on package stability life
 cycle. In netbeans case it is _prealpha and definitely not stable
 patched release. So _alpha is the closest one to current netbeans 6.0
 life cycle phase, though not accurate.

Actually stuff like cat/pkg-1.2_alpha3_pre4 is valid now and honored by
portage; dunno how does that fit the netbeans upstream scheme, though.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Marijn Schouten (hkBst)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marius Mauch wrote:
 On Fri, 16 Mar 2007 18:25:17 -0400
 William L. Thomson Jr. [EMAIL PROTECTED] wrote:
 
 Hierarchy would be the following

 snapshot - dev - build - alpha - beta 
 
 And that's where the problems start. As you said yourself _snapshot is
 something universal so it doesn't really fit anywhere in the chain.
 Similar for _build, it usually runs parallel to normal versioning (a
 release also has a build number). Don't know about _dev, never seen a
 package where that would be useful myself.
 And as has been said, there are compability issues. At best older
 portage versions would ignore ebuilds using these new suffixes
 resulting in confused users, worst case stuff starts breaking.
 If you want to pursue this you should get some numbers of how many
 packages could actually make use of these new features, it simply isn't
 worth thinking about it for just a handful of packages.
 
 Marius

One thing we could do would be to separate hierarchy from version naming. That 
way we can allow
arbitrary version names and also smoothly traverse version scheme changes such 
that break hierarchy.
This would prevent cases like currently with rosegarden (~)1.2.4 (~)1.4.0 
4.1.0-r1 4.1.0-r2, where
it really should be 4.1.0-r1 4.1.0-r2 (~)1.2.4 (~)1.4.0.

We could also add an internal version which would be compared first and only if 
it is equal for
packages would the version in the ebuild name be used for ordering.

Just throwing some ideas out there,

Marijn
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF+7jup/VmCx0OL2wRAhszAJwNo29AEj6rOSlimu+sbi8OwUPeKgCePo2g
2g1sI/Tk+ZYnRQ0j8b7d+44=
=SdRi
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Miroslav Šulc (fordfrog)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jakub Moc napsal(a):
 Miroslav Šulc (fordfrog) napsal(a):
 According to
 http://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules
 it seems to me the versioning is focused on package stability life
 cycle. In netbeans case it is _prealpha and definitely not stable
 patched release. So _alpha is the closest one to current netbeans 6.0
 life cycle phase, though not accurate.
 
 Actually stuff like cat/pkg-1.2_alpha3_pre4 is valid now and honored by
 portage; dunno how does that fit the netbeans upstream scheme, though.


Where does this come from? There is nothing about it in devmanual. And
is '_alpha  _alpha_pre' true of false? Anyway I'd rather preffer
_prealpha than _alpha_pre :-)


- --
Miroslav Šulc (fordfrog)
Gentoo/Java Team
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF+9m2RSzWCmqu+0YRAt+3AJ9RcqsIgCzlJCygKyRrqEGZY6lmogCffLWl
ZdCUglDhgQAiBaop7G1dXM4=
=14Rp
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Ciaran McCreesh
On Sat, 17 Mar 2007 10:46:22 +0100 Marijn Schouten (hkBst)
[EMAIL PROTECTED] wrote:
 One thing we could do would be to separate hierarchy from version
 naming.

That was one of Zynot's goals. You might want to investigate how they
ended up solving it.

-- 
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis, the secure package manager : http://paludis.pioto.org/



signature.asc
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Carsten Lohrke
On Samstag, 17. März 2007, Jakub Moc wrote:
 Actually stuff like cat/pkg-1.2_alpha3_pre4 is valid now and honored by
 portage; dunno how does that fit the netbeans upstream scheme, though.

The additional postfix is reserved exclusively for user local ebuilds, not for 
the ones provided by us.


Carsten


pgpGn5BppX9RK.pgp
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Petteri Räty
Carsten Lohrke kirjoitti:
 On Samstag, 17. März 2007, Jakub Moc wrote:
 Actually stuff like cat/pkg-1.2_alpha3_pre4 is valid now and honored by
 portage; dunno how does that fit the netbeans upstream scheme, though.
 
 The additional postfix is reserved exclusively for user local ebuilds, not 
 for 
 the ones provided by us.
 
 
 Carsten

It's already used by alsa-driver.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Carsten Lohrke
This is a valid argument for a single postfix with a lower order than alpha, 
but not a reason to add everything what's out there. I don't see the need to 
match upstream's versioning bit by bit. Honestly said I've never understood 
why our order is alpha, beta, pre and not pre, alpha, beta, which would fix 
the issue and match more closely what happens in the tree. Changing this 
might break the one or the other dependency, though. Last but not least to 
add that I consider adding snapshots of regular releasing upstream projects 
as a waste of ressources.


Carsten


pgp1NJc2BVkzW.pgp
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Carsten Lohrke
On Samstag, 17. März 2007, William L. Thomson Jr. wrote:
 IMHO I think it should be up to the package maintainer how close they
 want to follow upstream. With regard to development, progress, testing,
 qa, feedback. I think it's a very good thing, since it allows things to
 be caught before actual releases, during development.

Doing this locally or in some development overlay is fine, but polluting the 
tree with every single development build is a bad idea, imho.


Carsten


pgp1uJsUyuQ6N.pgp
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Carsten Lohrke
 Well that's the problem. When I use say _pre instead of _dev it gives
 off the wrong impression to users judging package by it's name. Since
 it's not a pre-release. A user may go upstream looking for some sort of
 pre-release. Which they won't find.

We have stable, testing and masked ebuilds. Nothing else the user should care 
about. If he does, he can more closely looking what's up himself.


Carsten


pgpxB7QSMPAm9.pgp
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Jakub Moc
Carsten Lohrke napsal(a):
 The additional postfix is reserved exclusively for user local ebuilds, not 
 for 
 the ones provided by us.

Such as media-sound/alsa-driver-1.0.14_rc2_p3234 ? :)

Anyway, if you have better ideas, move them to Bug 166522; multiple
suffixes are definitely needed, just should be restricted to sane combos.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Ciaran McCreesh
On Sat, 17 Mar 2007 15:06:07 +0200 Petteri Räty [EMAIL PROTECTED]
wrote:
 Carsten Lohrke kirjoitti:
  On Samstag, 17. März 2007, Jakub Moc wrote:
  Actually stuff like cat/pkg-1.2_alpha3_pre4 is valid now and
  honored by portage; dunno how does that fit the netbeans upstream
  scheme, though.
  
  The additional postfix is reserved exclusively for user local
  ebuilds, not for the ones provided by us.
  
  
  Carsten
 
 It's already used by alsa-driver.

And there's bug 166522 open about it. Some people consider Portage's
acceptance of alsa-driver-like versions to be a bug.

-- 
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis, the secure package manager : http://paludis.pioto.org/



signature.asc
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Carsten Lohrke
On Samstag, 17. März 2007, Petteri Räty wrote:
 It's already used by alsa-driver.

Then either me or the one doing so missed something on the discussion, why it 
was requested in the first place. Something to clarify in our ebuild policy.


Carsten


pgpUkMku2iZHo.pgp
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread William L. Thomson Jr.
On Sat, 2007-03-17 at 02:20 -0700, Ilya A. Volynets-Evenbakh wrote:

 There is a bit of contradiction in what you said there.
 Either the package is well tested, and should go into the tree, first
 with ~arch keywords, and then eventually with arch keywords, or
 it is experimental, and as such has to be outside of our main tree.

Well take Tomcat 6.0.x for example. I followed it's development and did
many bumps over 3-4 months or so, from 6.0.2 to 6.0.10. Several in
between went alpha, a few betas. They wanted to do several releases, but
kept finding bugs or etc. That delayed a the release and caused them to
do another bump on package version. Which after all that will likely be
some time before they release  6.0.10 :)

Now sure if any Gentoo users contributed in that process. But at the
same time, I would like to give those using this stuff as much notice
as possible. So they can test in their own envs. Keep in mind most of
this is server stuff. Most will want to test for some time before it
gets deployed to a production env.

From watching user comments on the developers list. Many are still
running Tomcat 5.0.28 since there were issues in 5.5.x that were not
resolved for years till 5.5.23 was released a few weeks ago.

WRT Gentoo, part of the idea behind following upstream that closely.
Allows us to hopefully identify any issues ahead of time. So when
upstream does an official release. We can bump package, wait 30 days and
stabilize. Without that being dragged out due to bug discoveries, and
waiting for upstream to react after the fact.

Tomcat did go unmaintained for about a year or so. Also trying to make
up for that. Letting people know it will be active maintained. Which
hopefully will encourage them to use Gentoo for their Java Server
platform or etc.

 Thus you can either want to test stuff by giving it more exposure,
 which implies the stuff is experimental, or you have stable stuff,
 but then you shouldn't be talking about the development cycle of the
 said software.

Any version of say Tomcat or mod_jk, I have put into tree before
official release has been stable for me. Idea is to find out if it's
stable for others as well. So while it's official status cause it to
fall into experimental category. Most have no issues, and bugs do not
tend to be very obvious or commonly run into.

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread William L. Thomson Jr.
On Sat, 2007-03-17 at 14:13 +0100, Carsten Lohrke wrote:
 On Samstag, 17. März 2007, William L. Thomson Jr. wrote:
  IMHO I think it should be up to the package maintainer how close they
  want to follow upstream. With regard to development, progress, testing,
  qa, feedback. I think it's a very good thing, since it allows things to
  be caught before actual releases, during development.
 
 Doing this locally or in some development overlay is fine, but polluting the 
 tree with every single development build is a bad idea, imho.

Well at best I might have 2 development versions in tree. But most
times it's just one, and I will remove older versions during any bump.
So hardly any polluting going on. Definitely no worse than what occurred
when the package was going unmaintained :)

Also in server envs, it seems most prefer not to use overlays. From my
own experiences, I can't blame them much. Even for testing servers. They
will usually divert and wait to test till it hits tree :(

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Marius Mauch
On Sat, 17 Mar 2007 14:01:45 +0100
Carsten Lohrke [EMAIL PROTECTED] wrote:

 On Samstag, 17. März 2007, Jakub Moc wrote:
  Actually stuff like cat/pkg-1.2_alpha3_pre4 is valid now and honored by
  portage; dunno how does that fit the netbeans upstream scheme, though.
 
 The additional postfix is reserved exclusively for user local ebuilds, not 
 for 
 the ones provided by us.

No, you're confusing it with a different idea that deals with extending
the revision part (that isn't implemented yet).

Marius
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] RFC Package name additions

2007-03-16 Thread William L. Thomson Jr.
After reviewing 

http://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules


I still seem to be having to finagle version names for some packages. At
the moment it would be nice if we also had the following suffixes
available

_dev
Apache upstream, specifically Tomcat/mod_jk tends to do developer
snapshots that they then host out of developer space. People do fetch
bins and source from there for testing. It's kinda pre-release, so I
have been using _pre where I would use _dev, but _pre does not make much
sense.

_build
Other packages seem to do constant builds (weekly) of the same version.
For example Glassfish (Sun's FOSS J2EE stuff). It's sources are v2-b39.
So would be nice to be able to do like glassfish-servlet-api-2_build39

_snapshot
This one is kinda universal in it's name/implication. Would be for any
sort of upstream snapshot release, that might not be versioned as such.
Short of the name snapshot being some where.

The above would then follow the rest of the normal schema, where in they
could still be suffixed by a number, or not.

Hierarchy would be the following

snapshot - dev - build - alpha - beta 

Or at least that's my thoughts on it. Time for others thoughts, much
less those that will make it so. Not expecting it to get done or be
available any time soon. Would be suffice if they were just accepted and
planned for inclusion at some point.

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] RFC Package name additions

2007-03-16 Thread Carsten Lohrke
There's absolutely no reason to absorb every single version naming scheme on 
earth. Gentoo's does work nicely and more than we have would only be 
irritating to the user. Simply use _predatecode  or whatever fits, but 
extending our naming scheme is unneeded and pointless.


Carsten


pgpcLcObgCmuK.pgp
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-16 Thread William L. Thomson Jr.
On Sat, 2007-03-17 at 00:11 +0100, Carsten Lohrke wrote:
 There's absolutely no reason to absorb every single version naming scheme on 
 earth. Gentoo's does work nicely and more than we have would only be 
 irritating to the user. Simply use _predatecode  or whatever fits, but 
 extending our naming scheme is unneeded and pointless.

Well that's the problem. When I use say _pre instead of _dev it gives
off the wrong impression to users judging package by it's name. Since
it's not a pre-release. A user may go upstream looking for some sort of
pre-release. Which they won't find.

The whole point is to make it clearer to the user the relation of the
sources to upstream. Instead of making them fit into our naming schema,
which do not apply to all.

Now granted at least on the Java front we have discussed coming up with
documents. We have a start of one, How to be a good upstream
http://overlays.gentoo.org/proj/java/wiki/How_to_be_a_good_upstream

Which we do need to make a section regarding package naming, tagging
sources and etc. With examples and so on.

Also keep in mind the _dev one I believe stems from Apache's own release
policies. Which they have a considerable amount of packages, so it's not
something that would only fit a small subset. IE Tomcat, mod_jk, etc.

The whole idea is better clarification to the end user via package name.
Instead of package being tagged as _pre or etc, and sources being tagged
with -dev and/or coming from a developers space. Not main project
release page or etc.

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] RFC Package name additions

2007-03-16 Thread Stephen Bennett
On Sat, 17 Mar 2007 00:11:43 +0100
Carsten Lohrke [EMAIL PROTECTED] wrote:

 There's absolutely no reason to absorb every single version naming
 scheme on earth. Gentoo's does work nicely and more than we have
 would only be irritating to the user. Simply use _predatecode  or
 whatever fits, but extending our naming scheme is unneeded and
 pointless.

And of course there is the issue of how older Portage releases will
react to ebuild names that they don't understand.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC Package name additions

2007-03-16 Thread Miroslav Šulc (fordfrog)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Just a note to this. I'm co-maintainer of netbeans ebuild. Netbeans does
milestone releases. These are pretty stable and usable since milestone 7
of netbeans 6.0 with many new features that make sense to use the
milestone releases. I have to name the ebuilds netbeans-6.0_alpha7 etc.
though I was assured by mkt guy from Sun it is not yet alpha quality. It
would be fair to the upstream and to users to not use _alpha because it
is not alpha but there's no appropriate choice available.

- --
Miroslav Šulc (fordfrog)
Gentoo/Java Team


William L. Thomson Jr. napsal(a):
 After reviewing 
 
 http://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules
 
 
 I still seem to be having to finagle version names for some packages. At
 the moment it would be nice if we also had the following suffixes
 available
 
 _dev
 Apache upstream, specifically Tomcat/mod_jk tends to do developer
 snapshots that they then host out of developer space. People do fetch
 bins and source from there for testing. It's kinda pre-release, so I
 have been using _pre where I would use _dev, but _pre does not make much
 sense.
 
 _build
 Other packages seem to do constant builds (weekly) of the same version.
 For example Glassfish (Sun's FOSS J2EE stuff). It's sources are v2-b39.
 So would be nice to be able to do like glassfish-servlet-api-2_build39
 
 _snapshot
 This one is kinda universal in it's name/implication. Would be for any
 sort of upstream snapshot release, that might not be versioned as such.
 Short of the name snapshot being some where.
 
 The above would then follow the rest of the normal schema, where in they
 could still be suffixed by a number, or not.
 
 Hierarchy would be the following
 
 snapshot - dev - build - alpha - beta 
 
 Or at least that's my thoughts on it. Time for others thoughts, much
 less those that will make it so. Not expecting it to get done or be
 available any time soon. Would be suffice if they were just accepted and
 planned for inclusion at some point.
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF+yssRSzWCmqu+0YRAoQAAJ9XHz0wZL3pdkSzSyxnVRnLsrw4FwCfVMDO
vuDOHvpko+t1nhu1cvx0RfY=
=ZYFd
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC Package name additions

2007-03-16 Thread William L. Thomson Jr.
On Fri, 2007-03-16 at 23:46 +, Stephen Bennett wrote:
 On Sat, 17 Mar 2007 00:11:43 +0100
 Carsten Lohrke [EMAIL PROTECTED] wrote:
 
  There's absolutely no reason to absorb every single version naming
  scheme on earth. Gentoo's does work nicely and more than we have
  would only be irritating to the user. Simply use _predatecode  or
  whatever fits, but extending our naming scheme is unneeded and
  pointless.
 
 And of course there is the issue of how older Portage releases will
 react to ebuild names that they don't understand.

Understandable for sure. Thus not really putting any sort of time frame
on implementation. Maybe EAPI=1 or beyond. Up to others that would
implement it. Just was tossing it out there, providing some feedback.

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] RFC Package name additions

2007-03-16 Thread Stephen Bennett
On Fri, 16 Mar 2007 20:00:51 -0400
William L. Thomson Jr. [EMAIL PROTECTED] wrote:

 Understandable for sure. Thus not really putting any sort of time
 frame on implementation. Maybe EAPI=1 or beyond. Up to others that
 would implement it. Just was tossing it out there, providing some
 feedback.

EAPI doesn't help, at least not in its current form.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC Package name additions

2007-03-16 Thread Neal McConachie
William L. Thomson Jr. said the following:

 Well that's the problem. When I use say _pre instead of _dev it gives
 off the wrong impression to users judging package by it's name. Since
 it's not a pre-release. A user may go upstream looking for some sort of
 pre-release. Which they won't find.

 The whole point is to make it clearer to the user the relation of the
 sources to upstream. Instead of making them fit into our naming schema,
 which do not apply to all.
snip
 The whole idea is better clarification to the end user via package name.
 Instead of package being tagged as _pre or etc, and sources being tagged
 with -dev and/or coming from a developers space. Not main project
 release page or etc.

Hi guys,

As one of the aforementioned users, I think the goal of helping us get a
better idea of the reliability a given package is excellent.  I was
looking at the GLEP list the other day, and one of them that I liked in
particular was GLEP 46.  (Allow upstream tags in metadata).   I think it
could have some bearing on this goal.  Although the GLEP doesn't list
upstream-version as one of its proposed metadata tags, I think it
could fit in nicely.  I have no clue what the status of that GLEP is,
but maybe the authors would?  Personally, I think it sounds like a good
flexible way of adding information to an ebuild without needing to redo
the naming scheme, or the upgrade path.  Here, you could use one of the
existing ways of naming the package, but in the metadata give the
information a user would want to evaluate the package's reliability
(plus more!) :)

-nkm
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC Package name additions

2007-03-16 Thread Mike Frysinger
On Friday 16 March 2007, William L. Thomson Jr. wrote:
 Well that's the problem. When I use say _pre instead of _dev it gives
 off the wrong impression to users judging package by it's name. Since
 it's not a pre-release. A user may go upstream looking for some sort of
 pre-release. Which they won't find.

isnt it though ?  how is a development release different from a pre 
release ?
-mike


pgpeE8TY4c1A7.pgp
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-16 Thread Mike Frysinger
On Friday 16 March 2007, Miroslav Šulc (fordfrog) wrote:
 Just a note to this. I'm co-maintainer of netbeans ebuild. Netbeans does
 milestone releases. These are pretty stable and usable since milestone 7
 of netbeans 6.0 with many new features that make sense to use the
 milestone releases. I have to name the ebuilds netbeans-6.0_alpha7 etc.
 though I was assured by mkt guy from Sun it is not yet alpha quality. It
 would be fair to the upstream and to users to not use _alpha because it
 is not alpha but there's no appropriate choice available.

i would use _p# over _alpha#
-mike


pgpCf7QYn7X2T.pgp
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-16 Thread Marius Mauch
On Fri, 16 Mar 2007 18:25:17 -0400
William L. Thomson Jr. [EMAIL PROTECTED] wrote:

 Hierarchy would be the following
 
 snapshot - dev - build - alpha - beta 

And that's where the problems start. As you said yourself _snapshot is
something universal so it doesn't really fit anywhere in the chain.
Similar for _build, it usually runs parallel to normal versioning (a
release also has a build number). Don't know about _dev, never seen a
package where that would be useful myself.
And as has been said, there are compability issues. At best older
portage versions would ignore ebuilds using these new suffixes
resulting in confused users, worst case stuff starts breaking.
If you want to pursue this you should get some numbers of how many
packages could actually make use of these new features, it simply isn't
worth thinking about it for just a handful of packages.

Marius
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC Package name additions

2007-03-16 Thread William L. Thomson Jr.
On Fri, 2007-03-16 at 21:23 -0400, Mike Frysinger wrote:
 On Friday 16 March 2007, William L. Thomson Jr. wrote:
  Well that's the problem. When I use say _pre instead of _dev it gives
  off the wrong impression to users judging package by it's name. Since
  it's not a pre-release. A user may go upstream looking for some sort of
  pre-release. Which they won't find.
 
 isnt it though ?  how is a development release different from a pre 
 release ?

I take it as a pre-release is more of an official release. Where in it
would be easily found on a projects download page or else where. What I
would consider a _dev release is something coming out of a developers
space on the project. Not really announced say beyond the developers
mailing list. In that same regard alpha's and beta's usually can be
found on project download pages. Same I would assume for any
pre-releases.

Given conceptually a development release is pre release. But not
really advertised as such by upstream. Either way it would not really
fit into our hierarchy. Most times the dev release will precede an alpha
or beta, sometimes does skip and is before an official release.

This might help a bit
http://marc.info/?l=tomcat-devm=117251925901310w=2

In that example a _dev is more of a snapshot, which could also be
considered as pre-release :) Good old interpretation of words.

P.S. OTT
With regard to above link and following development that closely.
Between revisions of mod_jk, not only was there a security
vulnerability. But in compatible changes effect certain file
extensions .jsf, that a user reported. Which they only mentioned during
stabilization of a given version (literally in stabilization bug). So in
a sense a version with a problem got stabilized. But was an upstream
bug, effecting a small subset. So did not really merit keeping the
package from going stable for others. But bug was not filed with
upstream either till 30+ days after release due to our stabilization
policies and etc.

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] RFC Package name additions

2007-03-16 Thread William L. Thomson Jr.
On Sat, 2007-03-17 at 03:11 +0100, Marius Mauch wrote:
 On Fri, 16 Mar 2007 18:25:17 -0400
 William L. Thomson Jr. [EMAIL PROTECTED] wrote:
 
  Hierarchy would be the following
  
  snapshot - dev - build - alpha - beta 
 
 And that's where the problems start. As you said yourself _snapshot is
 something universal so it doesn't really fit anywhere in the chain.

Yes, order wise snapshots might be quite confusing. Not sure if a well
defined definition would clear that up.

 Similar for _build, it usually runs parallel to normal versioning (a
 release also has a build number).

That's more something specific to say glassfish where builds are weekly
https://glassfish.dev.java.net/public/downloadsindex.html#Promoted_binary_builds

With major ones being milestones, similar to Netbeans.
https://glassfish.dev.java.net/public/downloadsindex.html#Milestone_binary_builds

Glassfish alone is likely to comprise of a guestimated ~20 or so
packages. It's Sun's formerly closed source J2EE stack for the most
part. Very possible could be more, formerly know as WSDP 
http://java.sun.com/webservices/jwsdp/index.jsp

 At best older
 portage versions would ignore ebuilds using these new suffixes
 resulting in confused users, worst case stuff starts breaking.
 If you want to pursue this you should get some numbers of how many
 packages could actually make use of these new features, it simply isn't
 worth thinking about it for just a handful of packages.

After others comments, this is definitely something for the future. If
and a time comes that it's feasible to introduce such changes safely. I
do agree before acceptable or implementation the amount of packages that
can benefit from it would surely help justify it or not.

Now I doubt it's feasible for me alone to figure out if it can benefit
all 4k+ packages :) So hopefully others can chime in briefly on if they
can benefit or not. Maybe email me directly to I can start a tally. Only
if you have packages that can benefit, no need otherwise.

With that said, what percentage or ruff # of packages do you all think
would need to benefit to justify it? That way if it's hard to find say
50 and min is like 500+, then no reason to look into it any further.

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] RFC Package name additions

2007-03-16 Thread Alec Warner
William L. Thomson Jr. wrote:
 On Sat, 2007-03-17 at 03:11 +0100, Marius Mauch wrote:
 On Fri, 16 Mar 2007 18:25:17 -0400
 William L. Thomson Jr. [EMAIL PROTECTED] wrote:

 Hierarchy would be the following

 snapshot - dev - build - alpha - beta 
 And that's where the problems start. As you said yourself _snapshot is
 something universal so it doesn't really fit anywhere in the chain.
 
 Yes, order wise snapshots might be quite confusing. Not sure if a well
 defined definition would clear that up.
 
 Similar for _build, it usually runs parallel to normal versioning (a
 release also has a build number).
 
 That's more something specific to say glassfish where builds are weekly
 https://glassfish.dev.java.net/public/downloadsindex.html#Promoted_binary_builds
 
 With major ones being milestones, similar to Netbeans.
 https://glassfish.dev.java.net/public/downloadsindex.html#Milestone_binary_builds
 
 Glassfish alone is likely to comprise of a guestimated ~20 or so
 packages. It's Sun's formerly closed source J2EE stack for the most
 part. Very possible could be more, formerly know as WSDP 
 http://java.sun.com/webservices/jwsdp/index.jsp
 
 At best older
 portage versions would ignore ebuilds using these new suffixes
 resulting in confused users, worst case stuff starts breaking.
 If you want to pursue this you should get some numbers of how many
 packages could actually make use of these new features, it simply isn't
 worth thinking about it for just a handful of packages.

Bleh; you have to break it at one point anyhow; you added the cvs
suffix, no? :)
-- 
gentoo-dev@gentoo.org mailing list