Releases of jedmodes

[G. Milde]

On  6.06.06, Jörg Sommer wrote:
> G. Milde schrieb am Tue 06. Jun, 14:07 (+0200):
> > On  4.06.06, Jörg Sommer wrote:
> > > 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.

...

> >  * 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.

Why double effort?

Also, the working copy (from which I do the pre-release tarball) might
contain additional files or newer files that are not uploaded to CVS by
the mode authors. This is why refuse to call the CVS a "canonical"
download site of Jedmodes.
 
> >  * 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.

It is. The CVS is not a "canonical download site". It is going to
vanish and therefore I do not like it being promoted in a Debian
package as a "canonical download site" by giving it in the
get-orig-source rule.

> > 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 do not need to do Jedmodes releases. However, as I am a member in
both Jedmodes and pkg-jed, I have to do both and I want to use
"Synergieeffekte".

> You're mixing up two different building sites. 

I am not mixing them up, however I contribute to both and I try to
arrange the work in a way that the overall effort is minimised.

Until the creation of jed-extra, a Jedmodes release had only one
reason: keep Sourceforge happy and prevent Jedmodes from being erased
due to inactivity. Now, a Jedmodes release on the FRS can also serve as
"canonical download site" for a Debian package.

> Consider a Suse or a Gentoo package. Do you really want to mix up all
> these packages to create your release?

I am no maintainer of any other packages than Debian jed. 
I am ready to do a release of Jedmodes if any other packagers reports
bugs that I can fix upstream and asks for a new 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. 

But otherwise I have a never ending

releasing Jedmodes -> hunt bug in jed-extra -> fix in jed-extra -> fix in
original source -> next Jedmodes release -> revert fix in jed-extra ->
next hunting.

To shorten up this cycle is a main reason for me being a pkg-jed member.


> 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.

Did you ever do a release at the Sourceforge FRS? It is a pain and
takes a lot of time. I will not do this for pre-releases.

During the preparation of a release I do the pre-releases simply to
minimalize my work and to make the result available to others for
testing.

> >    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.

To say it in other words: As long as I do my private testing, I prepare a
new pre-release, change the jed-extra changelog in my local SVN working
copy. During this phase, bugs will be fixed and the fixed files will be
uploaded to the CVS. A new tarball is created overwriting the still
"private" pre-release. A new jed-extra package is created and tested ...

Once I am ready (or out of time or wit), I will commit the changelog to
the alioth SVN repository. This is the time where the public (i.e. the
jed-packagers) will get to know the new "canonical" download URL and from
this time on I promise not to change the content of the tarball.


> >  * 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?

If they request it and provide a reason, yes.
 
> > > 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.

Changing the CVS URL. See their documentation if you are interested in
reasons.

> > > 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

So, why not use the DATE in the first download as well? This opens up the
possibility of different packagers having different "orig" tarballs as
the HEAD is a moving target.



Günter