Releases of jedmodes

[G. Milde]

Dear Jörg,

On  7.06.06, Jörg Sommer wrote:
> G. Milde schrieb am Wed 07. Jun, 17:44 (+0200):
> > On  6.06.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?
> Where is it doubled? It's only one time in rules.

and a second time in the update script for the working copy and tarball.
 
> > 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.
> 
> Is somewhere documented how you build the archive?

Yes, section "Generating CVS Snapshots" of
http://jedmodes.sourceforge.net/doc/jedmodes-cvs.html

If you are interested, I can mail you a copy of the update script. (It is
accessible to all Jedmodes developers via the shell account.)

 
> > > > 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.
> 
> Wrong. You've forced the whole jed-extra release team in the cycle you
> described below.

The above is a proposal! I do not force anyone to follow my proposals.

I developed a modus operandi that might not fit to your needs, but mainly
because there was no other activity on jed-extra for months.


> > > 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.
> 
> Wrong! These should be two indenpendent cycles, because you hold two
> different rules:
> 
> release Jedmodes -> getting bug/wishlist reports -> fix them -> next
> release
> 
> release Jedmodes -> prepare jed-extra -> release -> get bugreports -> fix
> and forward them -> wait for next Jedmodes release or release a new
> jed-extra

We are still in a phase of "rapid prototyping" where the "next release"
step is sensibly replaced with a "next pre-release" for Jedmodes and "next
test build" for jed-extra. Otherwise I would not be able to do several of
this cycles on one day.

Once the jed-extra packagers agree on a freeze (either by consensus, by
voting or by decree from Rafael) the upstream version for the next
jed-extra release becomes fixed and your above mentioned scheme could be
used.

 
> > > 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.
> 
> Than move to Berlios.

I thought about this, but a move is time consuming, would change the
Jedmodes URL and was not agreed upon amongst the Jedmodes developers.

> > > >  * 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.
> 
> Why they must provide a reason and you claim this for Debian. Is this
> equality?

Being the "canonical upstream download URL" for jed-extra is the only
reason for a Jedmodes release I can currently see (besides convincing
Sourceforge of activity going on).

While setting a tag or date for download from CVS would work in principle
as well, the CVS server is less stable, just recently changed the URL and
will cease to be available after the move to SVN. Sourceforge FRS
releases, on the contrary, are mirrored around the world and intended for
"eternity".

The jedmodes-users list never got any feedback about jedmodes releases so
far. A request from any other distribution would be welcome and I would
try to meet it (if time permits).


> > > > > 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?
> 
> Because not all modes may be broken. I would only downgrade the broken
> modes.

Downgrading will only in some cases help. It might just replace a new bug
with an old one fixed in the new version or lead to missing features.

However, if get-orig-source uses cvs ... HEAD it points at a moving
target. Calling this rule at different times will result in different
"orig" tarballs. (with failing dpatches and unpredictable behaviour).


Günter