Releases of jedmodes

Jörg Sommer joerg at alea.gnuu.de
Wed Jun 7 16:50:38 UTC 2006


Hallo G.,

G. Milde schrieb am Wed 07. Jun, 17:44 (+0200):
> 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?

Where is it doubled? It's only one time in rules.

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

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

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

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

But this does not help the package.

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

No.

> It is a pain and takes a lot of time. I will not do this for
> pre-releases.

Than move to Berlios.

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

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

Jörg.
-- 
Die NASA brauchte 12 Jahre um einen Kugelschreiber zu entwickeln, der
kopfüber, in der Schwerelosigkeit und unter Wasser schreiben kann.
Die Russen benutzten einfach einen Bleistift...
-------------- 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/20060607/737da01d/attachment.pgp


More information about the Pkg-jed-devel mailing list