Releases of jedmodes

[Jörg Sommer]

Hallo G.,

G. Milde schrieb am Tue 06. Jun, 14:07 (+0200):
> On  4.06.06, Jörg Sommer wrote:
> > Hallo G.,
> > 
> > G. Milde schrieb am Tue 30. May, 11:43 (+0200):
> > > On 29.05.06, Jörg Sommer wrote:
> > > > Or are everytime the modes in a sane state?
> > > 
> > > No, there is no time we can guarantee that every mode is in a sane state.
> > > 
> > > > Then we don't need these releases we can take the CVS.
> > > 
> > > Principially, Yes. 
> > > 
> > > However, the Policy says, that get-orig-source should download the
> > > upstream from a URL
>  
> > I don't see any problem, why this could not be CVS. But if someone
> > is in doubt, I would ask on debian-devel.
> 
>  * the update script for this working copy does some fixes that are hard
>    to doe in the CVS itself:

Right. We must do this in the rules file.

>  * there are plans to move the CVS repository to SVN (so the URL/download
>    command will change)

This is not an argument. If you would switch to ftp it would be the same.

> This is why I propose the following:
> 
>  * During the early development cycle of a new jed-extra package,
>    bugfixes are done upstream whenever possible and "pre-releases"
>    created at jedmodes.sf.net/cvs/ with a 3-parts version number.

I'm against doing jedmodes release *and* jed-extra release. You're mixing
up two different building sites. Consider a Suse or a Gentoo package. Do
you really want to mix up all these packages to create your release?

You should release your files independently from the jed-extra releases.
Otherwise I see a never ending story of pre-releasing jedmodes -> hunt
bug in jed-extra -> next pre-release -> next hunting. You must prepare a
clean upstream source which we can use as base for our jed-extra package.
Not hiding them in special directory. Use the file release system of
sourceforge.

>    Currently this is jedmodes-2.1.3.tgz. The next pre-release will be
>    jedmodes-2.1.4.tgz. The past practice of "silent upgrading" a
>    pre-release without changing its name will not be repeated any more:
>    the content of a pre-release will not change after it appears as
>    download target in the jed-extra changelog in the SVN. 

No. You revert the directions. Debian be subject to upstream not vice
versa.

>  * For the jed-extra release, the tested upstream pre-release is
>    published at the FRS.

Would you do the same for Gentoo, Suse, Redhat and Ubuntoo?

> > I would say, we should use
> >   cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/jedmodes export -r HEAD mode
> > as the new source of upstream files. 
> 
> This will fail as Sourcforge changed the CVS URL. Maybe you have luck with

Prefix the host with „jedmodes.“. I don't what sourceforge is doing.

> >   cvs -z3 -d:pserver:anonymous at jedmodes.cvs.sourceforge.net:/cvsroot/jedmodes export -r HEAD mode
> 
> > This way we could checkout older version if some contains errors.
> 
> I did not catch that. IMO, HEAD means the most current version -- what
> did I miss?

A later cvs ... export -r DATE mode/MODE

Bye, Jörg.
-- 
NetBSD ist für Frauen: es läuft auf Waschmaschinen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-jed-devel/attachments/20060606/7cc3a26a/attachment.pgp