Releases of jedmodes
Jörg Sommer
joerg at alea.gnuu.de
Tue Jun 6 16:15:37 UTC 2006
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
More information about the Pkg-jed-devel
mailing list