[Goodies-dev] Accounts for the new release manager

[Jannis Pohlmann]

On Wed, 22 Jul 2009 11:58:18 +0200
Nick Schermer <nickschermer at gmail.com> wrote:

> Looked though it, some (possible) points for improvement:
> 
> * Maybe you can always enable "Announce on announce at xfce.org" so we
> have 1 reliable point for release notes. Packages can benefit from
> this.

Yeah, I guess that's a good idea. We haven't used announce at xfce.org for
all projects in the past, so I didn't enable that by default.

> * I assume the links are appended to the message? Small piece of text
> to remind us about this would be nice.

http://release.xfce.org/feeds/project/thunar - that's how release
announcement mails look like. I'm planning to split up the release
form into two steps: 1. upload tarball, 2. write announcement and
confirm it on a second page. 

> * In the project view, it would be nice if the version numbers are
> links to the tarballs same for the branch maybe. So you can easily
> navigate to the file while checking/updating releases.

Yeah. It's easy to implement. I just didn't do that yet because the
archive is not publically visible yet.

> * Update/view checksum is gone. I used it a couple of times, not
> really important tho.

That's because we shouldn't compute checksums on the server. Instead,
you compute them locally to ensure the uploaded tarball is not
corrupted. If the archive checksums break at some point then that's
simply a bug in the release manager.

> * You cannot delete a branch, would be nice to do this if there are no
> versions/tarballs in it (for the "whoops I made a typo" case).

Branches are just folders (e.g. exo/0.3/ is the 0.3 branch). If their
last tarball is deleted, they should disappear. If a branch exists but
displays no releases that means there *are* tarballs in the folder but
moka doesn't recognize them.

I'd prefer if we'd stick to a tight naming scheme for all components,
something like <project>-<[0-9].[0-9].[0-9]>.tar.bz2. That makes it
very easy to detect available releases and it means that for each
release there is only one possible tarball filename. This implies that
there will be no tarballs called <project>-0.8.0rc1.tar.bz2 or
something, so I'm not sure about this. Maybe I'll remove this detection
logic and just show everything inside the branch folder, except for the
checksum files.

> * Like I said, would be nice to share the permissions with git. I
> think it makes sense if you commit in a branch, you can also make a
> release of it (at least for goodies that is). Maybe for example Brian
> would complain if I can make new releases of xfdesktop, duno, I don't
> really see a problem in that. There are only core devs in that group
> and you can assume we can take the responsibility right?

The git permissions are not per-branch, they are per-project. If we
decide to use the same user/project configurations, we lose
some flexibility (right now, all our applications (git, moka, bugzilla)
are completely independent). Of course it's a little more work this
way, but I can live with it.

If we decide to unite accounts for the different applications, then we
should do it right - and that requires some more thoughts. So for now:
independent accounts.

> * Maybe some link to bugzilla are useful, so you don't forget to
> update versions and milestones. You can use
> http://bugzilla.xfce.org/editmilestones.cgi?product=?????? and
> http://bugzilla.xfce.org/editversions.cgi?product=???? for that. Also
> an unofficial check if the release and bugzilla names match ^_^.

Yeah, would be cool if that appeared on the last page of the
(to-be-rewritten) release upload process.

> * Maybe for the future we can work with some default templates for the
> messages. IMHO that makes the whole thing a lot more professional. I'm
> thinking of a combo box with a paste button that puts some text in the
> message field (if empty) and separate messages for unstable releases
> (A new <product> release <version> is now available. This is a
> development release leading up to a stable <even version> release),
> stable releases, goodies, etc. Some structure in the whole thing so we
> can get rid of the "Hi folks, today i got some time to release a new
> version of the Xfce4-panel, quite neat hû?"

We have templates:

  http://release.xfce.org/feeds/project/thunar
  http://release.xfce.org/feeds/collection/xfce

The message you enter is appended at the very bottom.

> Are the tarballs also hosted under http://releases.xfce.org/? or do
> you still use xfce.org/archive/ for that?

archive/ with a new layout. Right now they are stored in a non-browsable
archive/ inside release.xfce.org. I'll work on importing *all* tarballs
from our old archive into that and then replace the old one today or
tomorrow, I think.

> I can't think of anything else right now. O I forgot to mention it
> looks really good!

Hehe, thanks ;)

  - Jannis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://mail.xfce.org/pipermail/goodies-dev/attachments/20090722/5f0a697b/attachment.pgp>